Internal Load Balancer allowing internet traffic

Apurva Pathak 310

Hi folks, I have an Azure Standard Internal Load balancer, and there is one VM behind it. As far I understand, if any VM is added (as NIC) behind an internal load balancer, the default outbound connection doesn't work, unless we specifically design that (as specified here: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-faqs#what-are-best-practices-with-respect-to-outbound-connectivity-). But, there is one VM for which it is working. Not sure why. Backend pool (VM is added as NIC): User's image

SKU: User's image

KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T07:40:32.24+00:00
@Apurva Pathak

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you have a VM placed behind a Standard Internal Load Balancer and still able to make default OutBound access via this VM.

Can you confirm if the VM does not have a Public IP Address?

Can you confirm there is no NAT Gateway attached to the subnet of this VM?

Does the public IP used by your VM remains constant or changes from time to time.

Does this VM have multiple NICs?

And if a Public IP is assigned to one of the NIC ?

Cheers, Kapil
Apurva Pathak 310 Reputation points

2024-01-18T07:54:07.17+00:00

@KapilAnanth-MSFT Thanks for looking into this. I can confirm that none of the above is the case. That is why I am so confused Only one NIC is assigned to the VM:

No Public IPs are assigned:

No NAT GWs are in the subnet (not even in Vnet) VM is connecting to public IP:
KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T13:23:30.8266667+00:00
@Apurva Pathak

I tried to repo your issue, however, I am not able to.

The VM is behaving as expected (no Internet Access).

Next Steps:

Please try to access https://ifconfig.me/ from this VM and share the Public IP you are seeing.

Can you confirm there is no UDR/Route Table attached to the VM?

I see you are trying to reach to the IP : 136.228.225.150

Can you please run tracert 136.228.225.150 and share the results?

Cheers,

Kapil
KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T14:28:52.0866667+00:00
@Apurva Pathak

I see your answer was deleted.

Can you please share the above details once again?

Please try to access https://ifconfig.me/ from this VM and share the Public IP you are seeing.

Can you try telnet to 8.8.8.8 on Port 443

Can you confirm there is no UDR/Route Table attached to the VM?

I see you are trying to reach to the IP : 136.228.225.150

Can you please run tracert 136.228.225.150 and share the results?

Cheers,

Kapil
Apurva Pathak 310 Reputation points

2024-01-18T14:35:22.01+00:00

We do have route table attached to the VM. And, the public IP which I am trying to access is a public IP of our proxy service which is hosted on in the internet, My doubt is proxy service itself is on the internet, how VM behind LB is able to reach out to that.
KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T14:41:34.6+00:00
@Apurva Pathak

What is the route attached on the VM's subnet?

If it is 0.0.0.0/0 ----> NVA or 136.228.225.150 -----> NVA, it means the traffic is going to the NVA first.

From NVA, the traffic is going to Internet.

From the VM, the traffic is not directly going to Internet.

Can you please share the route attached to the subnet?

Cheers,

Kapil
Apurva Pathak 310 Reputation points

2024-01-18T14:44:16.6266667+00:00

@KapilAnanth-MSFT You are right but, this way is it possible to route the traffic and overcome this limitation.
KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T14:53:04.27+00:00

@Apurva Pathak

This is an expected behavior and is a valid work around.

Please refer to my answer on how Default Outbound access works.

Cheers, Kapil

Accepted answer

KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-01-18T14:51:39.6966667+00:00
@Apurva Pathak

Welcome to the Microsoft Q&A Platform. Thank you for reaching out & I hope you are doing well.

I understand that you have a VM placed behind a Standard Internal Load Balancer and still able to make default OutBound access via this VM. This is an expected behavior with Route Table attached.

See : When is default outbound access provided?

If the next Hop is a NVA, the Outbound connectivity is dictated by the configuration of the NVA and not the VM.

And yes, this is a valid work around for VMs that are in the backend Pool of a Standard ILB that need Internet Connectivity.

Kindly let us know if this helps or you need further assistance on this issue.

Thanks,

Kapil

Please don’t forget to close the thread by clicking "Accept the answer" wherever the information provided helps you, as this can be beneficial to other community members.
Please sign in to rate this answer.

1 person found this answer helpful.
Apurva Pathak 310 Reputation points

2024-03-04T19:25:54.3266667+00:00

Hi @KapilAnanth-MSFT , sorry have got another weird situation.

VM is behind an Standard Internal LB with No Public IPs either to the VM or to the LB. VM is added as a NIC to the LB, no NAT GW in the subnets, still I can successfully tnc to a storage account endpoint. Though, connection to Google, internet in browser etc. doesn't work, still I am very keen to know why this storage account is being dealt differently.

I am messing something vey silly here, but I am unable to locate.

Could you please suggest:

LB and VM details:

TNC results:

Connection to Storage account:

Connection to google.com:

KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-03-06T13:29:20.9733333+00:00

@Apurva Pathak,

Greetings.

Can you please check if Storage Service EndPoint is enabled in the subnet of this VM?

Cheers,

Kapil

Apurva Pathak 310 Reputation points

2024-03-06T13:33:12.16+00:00

Hi @KapilAnanth-MSFT , No, even though I enable it, it shouldn't work because it is under LB and the next hop will be 'ServiceEndpoint' which is not NVA/FW.

Apurva Pathak 310 Reputation points

2024-03-06T17:44:48.9366667+00:00

Hi @KapilAnanth-MSFT , pasting few snips below for reference. I am really cofused now :(

KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-03-07T15:54:31.1233333+00:00

@Apurva Pathak,

It appears this is an expected behavior.

See : How do connections to Azure Storage in the same region work? | FAQ.

I did a lab and I can confirm the above:

Storage Accounts in same region is reachable

Storage Accounts in a different region is not reachable

If this is not desired,

From VM perspective - you can use NSGs to limit the destinations it is allowed to reach.

From Storage Account perspective - to limit unauthorized access, use Service EndPoints so only the expected VMs (from Subnets whitelisted) will be able to access/reach the Storage Account.

Hope this clarifies.

Cheers,

Kapil

Apurva Pathak 310 Reputation points

2024-03-07T16:04:21.5933333+00:00

Thanks for this clarification @KapilAnanth-MSFT this is getting more complicated...

Does this behavior gets changed when we associate the route table?

Thanks

Apurva Pathak 310 Reputation points

2024-03-07T16:07:09.46+00:00

Sorry, yes it does..I just figured it out. Thanks a lot!

KapilAnanth-MSFT 35,251 Reputation points Microsoft Employee

2024-03-09T15:26:27.2633333+00:00

@Apurva Pathak,

You are most welcome.

Happy to assist.
Sign in to comment

1 additional answer

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more