Site to Site VPN: allow local network range to include Azure VNET range
I’ve created a virtual network (10.25.0.0/17) that our instances will live in, and created a local network representing CORPNET (10.0.0.0/8). In effect, we’re trying to have the virtual network be a subnet within our larger internal IP block to emulate an internal datacenter. When trying to create the site to site VPN using the local network, I get an error about an address conflict, which seems to be due to the virtual network and local network be overlapping.
Per MSFT: The local network range cannot include the Azure VNET range. The local network definition(s) are used to establish routes between the Azure VNET and the on-prem “local” networks. If the same address is contained in both, we wouldn’t be able to establish a route between them (same IP address in network). To workaround, I need to define the local network space excluding the 10.25.0.0/17 segment.
AWS does permit this configuration. AWS simply handles the virtual route with a higher “priority” than any overlapping local network… akin to a “connected” subnet route on a router having priority over a larger network route defined statically… everything but the smaller network goes one way, smaller network goes the other.
Addressing this in Azure would be more straightforward from a customer configuration standpoint and put that specific configuration element in line with what AWS is doing, which also makes it easier to AWS customers to migrate.
We’ve removed this constraint. Please let us know if you are still experiencing any issues.
Rasmus Andersen commented
totally agree this should be re-thinked by MSFT - I have a similar situation now, where a customer has aquired another company, that has a subnet onpremise (/24) that is part of a VNET in Azure, although the /24 subnet is not created in Azure and thereby "free" to use - however my Virtual network gateway refuses to pass traffic to this /24 subnet, as it (I guess) sees this as local subnet
Patrick Powers commented
I am having a similar issue, but the other way around. My Azure Vnet is 10.0.0.0/8 and we have an OnPrem network of 10.22.0.0/16. We recently setup ExpressRoute and are having similar issues. Is there a way in Azure to have an exclusion for the 10.22.0.0/16?
I agree. It would be very helpful for this to work, and have Azure's routing table prefer more specific routes.
We should be able to have networks like 10.254.0.0/16 in Azure and have the local on-prem network still be specified as 10.0.0.0/8. This will help prevent having to add in multiple smaller subnets, and remembering to add new subnets to the tunnel as the organization grows. The only other option is to use different IP space like 172.16.0.0/12 or 192.168.0/16.