You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-wan/how-to-routing-policies.md
+3-2Lines changed: 3 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ Routing Intent and Routing policies allow you to specify how the Virtual WAN hub
31
31
While Private Traffic includes both branch and Virtual Network address prefixes, Routing Policies considers them as one entity within the Routing Intent Concepts.
32
32
33
33
>[!NOTE]
34
-
> Inter-region traffic **cannot** be inspected by Azure Firewall or NVA.
34
+
> Inter-region traffic **cannot** be inspected by Azure Firewall or NVA. Additionally, configuring both private and internet routing policies is currently **not** supported in most Azure regions. Doing so will put Gateways (ExpressRoute, Site-to-site VPN and Point-to-sive VPN) in a failed state and break connectivity from on-premises branches to Azure. Please ensure you only have one type of routing policy on each Virtual WAN hub. For more information, please contact [email protected].
35
35
36
36
37
37
***Internet Traffic Routing Policy**: When an Internet Traffic Routing Policy is configured on a Virtual WAN hub, all branch (User VPN (Point-to-site VPN), Site-to-site VPN, and ExpressRoute) and Virtual Network connections to that Virtual WAN Hub will forward Internet-bound traffic to the Azure Firewall resource, Third-Party Security provider or **Network Virtual Appliance** specified as part of the Routing Policy.
@@ -198,7 +198,8 @@ The following section describes common issues encountered when you configure Rou
198
198
* Currently, Private Traffic Routing Policies are not supported in Hubs with Encrypted ExpressRoute connections (Site-to-site VPN Tunnel running over ExpressRoute Private connectivity).
199
199
* You can verify that the Routing Policies have been applied properly by checking the Effective Routes of the DefaultRouteTable. If Private Routing Policies are configured, you should see routes in the DefaultRouteTable for private traffic prefixes with next hop Azure Firewall. If Internet Traffic Routing Policies are configured, you should see a default (0.0.0.0/0) route in the DefaultRouteTable with next hop Azure Firewall.
200
200
* If there are any Site-to-site VPN gateways or Point-to-site VPN gateways created **after** the feature has been confirmed to be enabled on your deployment, you will have to reach out again to [email protected] to get the feature enabled.
201
-
* If you are using Private Routing Policies with ExpressRoute, please note that your ExpressRoute circuit cannot advertise exact address ranges for the RFC1918 address ranges (you cannot advertise 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Please ensure you are advertising more specific subnets (within RFC1918 ranges) as opposed to aggregate supernets. Additionally, if your ExpressRoute circuit is advertising a non-RFC1918 prefix to Azure, please make sure the address ranges that you put in the Private Traffic Prefixes text box are less specific than ExpressRoute advertised routes. For example, if the ExpressRoute Circuit is advertising 40.0.0.0/24 from on-premises, put a a /23 CIDR range or larger in the Private Traffic Prefix text box (example: 40.0.0.0/23).
201
+
* If you are using Private Routing Policies with ExpressRoute, please note that your ExpressRoute circuit cannot advertise exact address ranges for the RFC1918 address ranges (you cannot advertise 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Please ensure you are advertising more specific subnets (within RFC1918 ranges) as opposed to aggregate supernets. Additionally, if your ExpressRoute circuit is advertising a non-RFC1918 prefix to Azure, please make sure the address ranges that you put in the Private Traffic Prefixes text box are less specific than ExpressRoute advertised routes. For example, if the ExpressRoute Circuit is advertising 40.0.0.0/24 from on-premises, put a a /23 CIDR range or larger in the Private Traffic Prefix text box (example: 40.0.0.0/23).
202
+
* Make sure you do not have both private and internet routing policies configured on a single Virtual WAN hub. Configuring both private and internet routing policies on the same hub is currently unsupported and will cause Point-to-site VPN, ExpressRoute and Site-to-site VPN gateways to go into a failed state and interrupt datapath connectivity to Azure.
0 commit comments