There exists an asymmetric routing scenario that is similar to that at AWS. To expose this issue you need
This issues is realized when :
- a VNet that is peered to the sharedservices VNet with gateway transit enabled
...
- thru ExpressRoute
- Additionally
...
- a VM with an external IP that is being requested from the Cornell campus network.
you are trying to reach from campus. With all of these pieces in place, packets sent from campus to the external IP will return to campus via the ExpressRoute and be dropped by the initiating host.
To get around or avoid this issue:
- we
...
- create two subnets in the customer VNet - one "private", one "public".
...
- a user defined route (UDR) will need to be created and then associated with the public subnet.
- The UDR will list all campus IP ranges with a next hop of "Internet".
Caveat : an additional caveat exists with this "solution":
- With the UDR in place the opposite asymmetric route will be true.
- A campus network system with a public IP, trying to reach the "10 space" address of an Azure VM on the subscriptions public subnet, will fail.
IPv4 Global Address Blocks Owned and Managed by Cornell
...