Home

Routing in Azure with internal and external IPs

%3CLINGO-SUB%20id%3D%22lingo-sub-127411%22%20slang%3D%22en-US%22%3ERouting%20in%20Azure%20with%20internal%20and%20external%20IPs%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-127411%22%20slang%3D%22en-US%22%3E%3CP%3E(repost%20from%20%3CA%20href%3D%22https%3A%2F%2Fserverfault.com%2Fquestions%2F872627%2Frouting-in-azure-with-internal-and-external-ips%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fserverfault.com%2Fquestions%2F872627%2Frouting-in-azure-with-internal-and-external-ips%3C%2FA%3E%20as%20that%20has%20gotten%20stale)%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20a%20VNet%20with%20some%20VMs%20in%20Azure.%20The%20VNet%20has%20a%20site-to-site%20VPN%20connection%20back%20to%20my%20premises.%20From%20on-prem%20clients%2C%20I%20can%20successfully%20connect%20to%20the%20private%20IP%20addresses%20of%20the%20VMs.%20However%2C%20on-prem%20clients%20cannot%20connect%20to%20the%20public%20IP%20address%20of%20a%20VM.%20On%20the%20other%20hand%2C%20if%20I%20try%20to%20connect%20to%20a%20VM%20from%20different%20internet%20connection%20(3g%20on%20phone%2C%20or%20from%20home)%2C%20then%20I%20can%20connect%20to%20the%20public%20address%20without%20problems.%20There%20are%20no%20network%20ACLs%20on%20network%20equipment%20on-prem%20that%20could%20be%20blocking%20this%20traffic%20(in%20fact%20a%20traceroute%20to%20the%20public%20IP%20address%20cuts%20out%20at%20a%20ntwk.msn.net%20address).%20Any%20thoughts%20on%20what%20the%20issue%20might%20be%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20installed%20Wireshark%20on%20one%20of%20the%20VMs%2C%20and%20when%20I%20try%20to%20connect%20to%20the%20external%20IP%20from%20on-prem%2C%20no%20packets%20reach%20the%20VM.%20So%20I'm%20guessing%20the%20routing%20on%20the%20VNet%2C%20the%20Public%20IP%20SNAT%2C%20or%20the%20VM's%20routing%20is%20at%20fault%20here.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAs%20a%20test%2C%20I%20have%20spun%20up%20a%20new%20vnet%20on%20a%20seperate%20IP%20range%2C%20and%20a%20new%20VM%20with%20a%20public%20IP.%20Connecting%20to%20the%20public%20IP%20of%20this%20VM%20works%20fine.%20Something%20in%20the%20VPN%2Frouting%20of%20the%20original%20VNET%20seems%20to%20be%20part%20of%20the%20problem%2C%20as%20without%20a%20VPN%20everything%20is%20fine.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20leads%20on%20working%20this%20out%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-127411%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3ENetworking%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EVirtual%20Network%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-891213%22%20slang%3D%22en-US%22%3ERe%3A%20Routing%20in%20Azure%20with%20internal%20and%20external%20IPs%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-891213%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F94700%22%20target%3D%22_blank%22%3E%40Victor%20Rajewski%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHi%20Victor%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20know%20this%20is%20an%20old%20post%2C%20but%20in%20case%20anyone%20else%20runs%20into%20this%20issue.%20I%20experienced%20this%20about%20the%20same%20time%20you%20posted%2C%20so%20things%20might%20have%20changed.%20After%20a%20long%20support%20call%20with%20Microsoft%2C%20it%20came%20out%20that%20Azure%20drops%20traffic%20coming%20from%20the%20internet%20(to%20your%20public%20IP)%20if%20the%20source%20address%20is%20included%20in%20the%20local%20site%20definition%20on%20your%20S2S%20VPN.%20This%20is%20a%20security%20measure--you%20have%20told%20Azure%20that%20traffic%20from%20the%20source%20address%20should%20arrive%20over%20the%20VPN%2C%20not%20from%20the%20internet.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMatthew%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-129548%22%20slang%3D%22en-US%22%3ERe%3A%20Routing%20in%20Azure%20with%20internal%20and%20external%20IPs%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-129548%22%20slang%3D%22en-US%22%3E%3CP%3Ei%20could%20imagine%20this%20is%20due%20to%26nbsp%3BNetwork%20security%20Groups%2C%20remeber%20you%20could%20have%20a%20Network%20NSG%20and%20a%20VM%20NSG.%20try%20adding%20a%20any%2Fany%20rule%20to%20both%20and%20see%20if%20you%20can%20get%20through.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Victor Rajewski
Occasional Visitor

(repost from https://serverfault.com/questions/872627/routing-in-azure-with-internal-and-external-ips as that has gotten stale)

 

I have a VNet with some VMs in Azure. The VNet has a site-to-site VPN connection back to my premises. From on-prem clients, I can successfully connect to the private IP addresses of the VMs. However, on-prem clients cannot connect to the public IP address of a VM. On the other hand, if I try to connect to a VM from different internet connection (3g on phone, or from home), then I can connect to the public address without problems. There are no network ACLs on network equipment on-prem that could be blocking this traffic (in fact a traceroute to the public IP address cuts out at a ntwk.msn.net address). Any thoughts on what the issue might be?

 

I installed Wireshark on one of the VMs, and when I try to connect to the external IP from on-prem, no packets reach the VM. So I'm guessing the routing on the VNet, the Public IP SNAT, or the VM's routing is at fault here.

 

As a test, I have spun up a new vnet on a seperate IP range, and a new VM with a public IP. Connecting to the public IP of this VM works fine. Something in the VPN/routing of the original VNET seems to be part of the problem, as without a VPN everything is fine.

 

Any leads on working this out?

2 Replies

i could imagine this is due to Network security Groups, remeber you could have a Network NSG and a VM NSG. try adding a any/any rule to both and see if you can get through.

 

@Victor Rajewski 

 

Hi Victor,

 

I know this is an old post, but in case anyone else runs into this issue. I experienced this about the same time you posted, so things might have changed. After a long support call with Microsoft, it came out that Azure drops traffic coming from the internet (to your public IP) if the source address is included in the local site definition on your S2S VPN. This is a security measure--you have told Azure that traffic from the source address should arrive over the VPN, not from the internet.

 

Matthew

Related Conversations
Tabs and Dark Mode
cjc2112 in Discussions on
35 Replies
Extentions Synchronization
ChirmyRam in Discussions on
3 Replies
flashing a white screen while open new tab
Deleted in Discussions on
14 Replies
Stable version of Edge insider browser
HotCakeX in Discussions on
35 Replies