diff --git a/website/content/docs/connect/cluster-peering/index.mdx b/website/content/docs/connect/cluster-peering/index.mdx
index 0b6ee7af0..f4c5e23bf 100644
--- a/website/content/docs/connect/cluster-peering/index.mdx
+++ b/website/content/docs/connect/cluster-peering/index.mdx
@@ -40,13 +40,14 @@ Regardless of whether you connect your clusters through WAN federation or cluste
 
 The cluster peering beta adds the following features and functions:
 
+- Mesh Gateways for _service to service traffic_ between clusters are available. For more information on configuring mesh gateways across peers, refer to [Service-to-service Traffic Across Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers).
 - You can generate peering tokens, establish, list, read, and delete peerings, and manage intentions for peering connections with both the API and the UI.
 - You can configure [transparent proxies](/docs/connect/transparent-proxy) for peered services.
 - You can use the [`peering` rule for ACL enforcement](/docs/security/acl/acl-rules#peering) of peering APIs.
 
 Not all features and functionality are available in the beta release. In particular, consider the following technical constraints:
 
-- Mesh gateways for _server to server traffic_ are not available. However, mesh gateways for _service to service traffic_ between clusters are available.
+- Mesh gateways for _server to server traffic_ are not available.
 - Dynamic routing features such as splits, custom routes, and redirects cannot target services in a peered cluster.
 - Configuring service failover across peers is not supported for service mesh.
 - Consul datacenters that are already federated stay federated. You do not need to migrate WAN federated clusters to cluster peering.