Azure "Default Outbound Access" Retirement for VMs - How to "simulate" this now, to prepare?

Question

Azure "Default Outbound Access" Retirement for VMs - How to "simulate" this now, to prepare?

Dave Lindquist 5

Microsoft sent around an email, explaining that they will be retiring "default outbound access" for Azure VMs next year.

Unfortunately, I cannot seem to find any way to turn this off now, so that I can prepare for the impact this will have when Microsoft does it.

There is an article at:

https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access

that has an entire section dedicated to "How can I transition to an explicit method of public connectivity (and disable default outbound access)?".

Unfortunately, it seems to be completely wrong:

It references a feature called "Private Subnets"; unfortunately, a) this seems to be still "experimental", and b) it does not exist anywhere in the Azure Portal.
It talks about setting "--default-outbound = false" on a subnet (via the az CLI). Unfortunately, using the az cli to query an existing subnet shows that there is no such parameter.

(I've also checked terraform - nope, no such thing as 'default outbound access' in the az subnet resources.)

I assume I'm missing something - how can I turn off default outbound access now (in my controlled test environment) so that I can confirm the impact (and my solutions) before this goes live?

(And there are some weird suggestions like 'assign a public ip' or 'attach a NAT gateway'; I'm not trying to FIX the problem now, I'm trying to prove where it BREAKS.)

Thanks in advance!

3 answers

Your answer

Answer 1

Martin Therkelsen 1,410 MVP

Hi David, I don't know of any way to test this directly, but you can test all the solutions working after outbound access is disabled. So, you can create a NAT gateway and attach that to the subnet where your VM is placed. You can also create an Azure Firewall and route all traffic to this NVA. This is done with a 0.0.0.0/0 route pointing to the NVA internal IP. You can do a "fake" test using an NSG on the subnet. In the NSG, you can block internet traffic for the VM and then test that it can connect to the internet using one of the supported methods.

Dave Lindquist 5 Reputation points

2024-02-09T14:54:20.1266667+00:00

These answers are all definitely ways to prevent default outbound access - but none of it actually addresses the real problem; Microsoft is going to be turning off a feature, and there is literally no possible way to test what this is going to do beforehand. The suggestions are good ways to 'approximate' things, but don't provide any way to know 'for sure' that things will work after the magic date. It is extremely disappointing that Microsoft has chosen to do the 'throw a grenade' approach, and provide zero ability for their customers to ensure that things will work correctly.
Martin Therkelsen 1,410 Reputation points MVP

2024-02-09T14:58:42.5533333+00:00

I agree, but remember that the change won't affect current environments, only new machines created.

Answer 2

Silvia Wibowo 6,041 Microsoft Employee Volunteer Moderator

Hi @Dave Lindquist , I understand that you want to make sure that your current Azure VMs do not use default outbound feature.

Please have a look at the following flowchart: When is default outbound access provided

The way you can make sure that your current Azure VMs do not use default outbound feature is by making sure that one of these applies:

You have a Firewall or VNA (Virtual Network Appliance) and your subnet is assigned a routing table that says 0.0.0.0/0 goes to the Firewall/VNA, or
You have a NAT gateway attached to the subnet where your VMs are, or
Your VMs are assigned a public IP address for each of them, or
You have a standard public Load Balancer with outbound rule defined, or
You have a standard public Load Balancer having a rule with DisableOutboundSnat = false

If none of those applies, and your VMs currently can connect to internet, then your VMs are using default outbound access.

Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.

Dave Lindquist 5 Reputation points

2024-01-24T01:00:24.55+00:00
Yes, I have seen the flowchart, and understand that there are ways of not using default outbound access - but that's not exactly the question.

Basically, the question is this:

PREDICATE: On September 30, 2025, Microsoft will "flip a switch" and VMs will no longer have default outbound access; this "flip a switch" will not do any of the things on that flowchart, it will simply stop default outbound access. (Let's ignore the "grandfathering existing VMs", etc for the moment)

REQUEST: How do I do the equivalent of "flipping that switch" now, in my existing setup, without doing any of the flowchart steps to change things, so that I can see how my infrastructure will be impacted.

This seems like such a simple request - Microsoft is going to flip switch "X", let me flip that manually earlier so I can test. But perhaps this isn't possible? If not, will it become possible at some time in the future? Or is it simply "roll the dice, see what happens on September 30, 2025"? (That would be very frustrating...)

Thanks!

Answer 3

Hi Dave Lindquist

I understand your question now. Unfortunately, there is no way to manually "flip the switch" to disable default outbound access for your VMs before September 30, 2025.

The only way to disable default outbound access for your VMs is to use one of the explicit methods of public connectivity mentioned in the flowchart. These methods include associating a NAT gateway, a standard load balancer, or a public IP address to your VM's network interface.
I understand that you want to test the impact of disabling default outbound access without making any changes to your existing setup. However, since there is no way to disable default outbound access without using one of the explicit methods of public connectivity, you will need to make changes to your setup to test the impact. I recommend creating a test environment and deploying your application with one of the explicit methods of public connectivity mentioned in the flowchart. You can then test the application to see if it works as expected. This will give you an idea of the impact of disabling default outbound access on your application.

I hope this helps. Let me know if you have any further questions.

Dave Lindquist 5 Reputation points

2024-02-08T14:48:22.7433333+00:00

This seems like a major problem for all Azure customers - at some cutoff date in the future, behaviour will change with absolutely ZERO possibility of testing or predicting beforehand whether things will continue to work. Can Microsoft please address this and provide a way of manually flipping this functionality switch in advance? Even if it is at a 'subscription' or 'resource group' level (so that a 'test' subscription or resource group can experiment with it).

Share via

Azure "Default Outbound Access" Retirement for VMs - How to "simulate" this now, to prepare?

3 answers

Your answer