Merge pull request MicrosoftDocs#1461 from MattKazmar/patch-1

Update expressroute-nat.md to clarify SNAT

articles/expressroute/expressroute-nat.md

@@ -44,7 +44,7 @@ There are no restrictions on the length of the NAT IP prefix advertised through
 > 
 
 ## NAT requirements for Microsoft peering
-The Microsoft peering path lets you connect to Microsoft cloud services that are not supported through the Azure public peering path. The list of services includes Office 365 services, such as Exchange Online, SharePoint Online, Skype for Business, and CRM Online. Microsoft expects to support bi-directional connectivity on the Microsoft peering. Traffic destined to Microsoft cloud services must be SNATed to valid public IPv4 addresses before they enter the Microsoft network. Traffic destined to your network from Microsoft cloud services must be SNATed before they enter your network. The figure below provides a high-level picture of how the NAT should be setup for Microsoft peering.
+The Microsoft peering path lets you connect to Microsoft cloud services that are not supported through the Azure public peering path. The list of services includes Office 365 services, such as Exchange Online, SharePoint Online, Skype for Business, and CRM Online. Microsoft expects to support bi-directional connectivity on the Microsoft peering. Traffic destined to Microsoft cloud services must be SNATed to valid public IPv4 addresses before they enter the Microsoft network. Traffic destined to your network from Microsoft cloud services must be SNATed at your Internet edge to prevent [asymmetric routing](expressroute-asymmetric-routing.md). The figure below provides a high-level picture of how the NAT should be setup for Microsoft peering.
 
 ![](./media/expressroute-nat/expressroute-nat-microsoft.png) 
 
@@ -59,7 +59,9 @@ The Microsoft peering path lets you connect to Microsoft cloud services that are
 
 ### Traffic originating from Microsoft destined to your network
 * Certain scenarios require Microsoft to initiate connectivity to service endpoints hosted within your network. A typical example of the scenario would be connectivity to ADFS servers hosted in your network from Office 365. In such cases, you must leak appropriate prefixes from your network into the Microsoft peering. 
-* You must SNAT traffic destined to IP addresses within your network from Microsoft. 
+* You must SNAT Microsoft traffic at the Internet edge for service endpoints within your network to prevent [asymmetric routing](expressroute-asymmetric-routing.md). Requests **and replies** with a destination IP that match a route received via ExpressRoute will always be sent via ExpressRoute. Asymmetric routing exists if the request is received via the Internet with the reply sent via ExpressRoute. SNATing the incoming Microsoft traffic at the Internet edge forces reply traffic back to the Internet edge, resolving the problem.
+
+![Asymmetric routing with ExpressRoute](./media/expressroute-asymmetric-routing/AsymmetricRouting2.png)
 
 ## Next steps
 * Refer to the requirements for [Routing](expressroute-routing.md) and [QoS](expressroute-qos.md).