What are the ways that you're planning to control traffic after Microsoft turns off Outbound traffic

Stuart_Smiles
Comes here often

What are the ways that you're planning to control traffic after Microsoft turns off Outbound traffic

Hi All, 

 

What are the ways that you're planning to control traffic after Microsoft turns off Outbound traffic at the end of September 2025. 

 

https://azure.microsoft.com/en-us/updates?id=upgrade-to-standard-sku-public-ip-addresses-in-azure-by... 

 

We have groups of VM's , and are looking at the different options about setup of firewall rule policy management across devices that people are coming up with so can review what can and does go where.  

 

Rules

We also have to contend with Microsoft's IP address ranges, and dedication to only providing *.xxx.microsoft.com rather than ranges that can be put into an IPv4 firewall rule base, and without making their spreadsheet of addresses too arduous to manage. 

 

The Microsoft answer of Azure firewall is in the mix, [ which seems to filter their stuff by domain name ] , NSG's however are based on IPv4 or ipV6 addresses. 

 https://learn.microsoft.com/en-us/defender-cloud-apps/network-requirements?source=recommendations 

 

e.g. Defender https://learn.microsoft.com/en-us/defender-cloud-apps/network-requirements?source=recommendations 

cdn.cloudappsecurity.com cdn-discovery.cloudappsecurity.com adaproddiscovery.azureedge.net *.s-microsoft.com *.msecnd.net dev.virtualearth.net flow.microsoft.com static2.sharepointonline.com *.blob.core.windows.net discoveryresources-cdn-prod.cloudappsecurity.com

 

13.107.219.0/24, 13.107.227.0/24, 13.107.228.0/24, 13.107.229.0/24, 150.171.97.0/24, 13.80.125.22, 40.74.1.235, 40.74.6.204, 40.119.154.72, 51.143.58.207, 52.137.89.147, 52.157.238.58, 52.174.56.180, 52.183.75.62, 20.71.203.39, 137.116.224.49*.eu.portal.cloudappsecurity.com


Office https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worl... 

 

Are you using the service tags download as an allow list ? 
https://www.microsoft.com/en-my/download/details.aspx?id=56519&msockid=09ba471708d9606b3b91515f09616... 

 

For multiple vms, different subscriptions, and access rules specific to devices these get more complicated, have you just gone down the proxy route ?  

 

How are you managing the firewall rules / NSG's and the complexity of allowing what is needed

What are the ways you're doing changes ? 

How are you segregating ?  

How are you intending to restrict access outbound ? [ or are you not ] 

Proxy ?

other firewall options ? Azure Firewall / live with Network Security Groups / virtual ASA /  other ] ?

Meraki Firewall Options / alternatives? 

Routing traffic through specific control points & load sharing / resilience ? 

 

Is Umbrella required for domain based filtering , is it better to focus on ipv4 rules and keep adding addresses each time they get new ones added in ? 

 

Any suggestions or reading material gratefully received. 

 

Many thanks

Stuart

3 Replies 3
Mloraditch
Kind of a big deal
Kind of a big deal

This is more of a Microsoft question than anything else and you may want to look/ask around on some of the sysadmin or azure reddits or other communities as you will likely find a more vibrant discussion, although I'm sure others will share a few thoughts.

You can use a vMX if it's in nat mode and in the same vNET as all of your VMs.

Solutions are going to depend on individual needs, some customers are going to be ok just assigning a public ip to each vm or setting up the NAT gateway option. Some are going to have extensive firewall setups whether it's Azure solutions or some other Firewall VM.

Everything you mention is a possible way to handle, but we don't know what you/your clients need.

If  right now you are just relying on outbound access by default and that's sufficient I would just add the NAT gateway for now.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
Stuart_Smiles
Comes here often

Thank you for the comment received.  

 

My understanding is that new Microsoft Azure VM's are no longer going to be configurable with direct internet access outbound from 30th September 2025.

As a result, a control point will need to be in use, between the devices in a Private network and the internet. 

There will need to be a route out to the internet provided by something, which can control outbound traffic and potential inbound flow.   

 

For outbound access, to sites that Microsoft needs you to access, they provide large IP address blocks, and wildcard DNS addresses for their services to be accessed. 

To use the Meraki in this way, we will need to be able to firewall based on IP Address blocks, *.FQDN rules, and ideally the "Azure service tag" groupings that Microsoft provide.


How will the Meraki firewalling platform work for this use case please

As an example, for the Defender service, Microsoft provides the following details of what needs to be accessible:  

https://learn.microsoft.com/en-us/defender-cloud-apps/network-requirements?source=recommendations 

cdn.cloudappsecurity.com
cdn-discovery.cloudappsecurity.com
adaproddiscovery.azureedge.net
*.s-microsoft.com
*.msecnd.net
dev.virtualearth.net
flow.microsoft.com
static2.sharepointonline.com
*.blob.core.windows.net
discoveryresources-cdn-prod.cloudappsecurity.com

also for the defender datacentre(s) you're using:  e.g. US1

13.107.219.0/24, 13.107.227.0/24, 13.107.228.0/24, 13.107.229.0/24, 150.171.97.0/24, 13.64.26.88, 13.64.29.32, 13.80.125.22, 13.91.91.243, 40.74.1.235, 40.74.6.204, 51.143.58.207, 52.137.89.147, 52.183.75.62, 23.101.201.123, 20.228.186.154 *.us.portal.cloudappsecurity.com 

For Office 365, Sharepoint / other services, similar blocks of addresses and URLs need to also be configured. 

 

How can Meraki be setup to view, log, and track what is blocked / flowing currently, so you can see what activity is going on? will Geo-Blocking be available?   

 

What sustained throughput would be realistic for design engineering for the platform doing this level of traffic inspection in the Azure environment please - 10 devices, 30, 50 100, 200 with gig e connections ? I note that the VMX-L says it is able to do 1GBPS of throughput, so how should we engineer for maximum throughput. 

Is there any traffic throughput penalties for applying any IDS / IDP functionality or rules to be aware of ? 

 

Many thanks

Stuart

 

 

Many thanks

Stuart

Mloraditch
Kind of a big deal
Kind of a big deal

You don't need to add anything to maintain internet access on your VMs besides a NAT gateway on their VNET or assign a public ip to the VM. That's  it. If you want a control point and further firewalling that's a different story, but you don't need any of that. If you don't have anything now, you add one of the above items and you are all set for now.

You are otherwise asking a bunch of detailed design questions, to the point where I suggest you involve your Meraki or Partner Rep. 

 

https://documentation.meraki.com/MX/MX_Sizing_Information/MX_Sizing_Principles is somewhere to start on your capacity questions.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Firewall_Logging
https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Meraki_Event_Log

 for your logging questions

Geo Blocking is available via Layer 7 rules https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_a_Layer_7_Fi...


Regardless, I strongly recommend getting a rep involved who can engage an engineer. 10 VMs is quite different from 200 and IMO 200 servers in azure is where you should be looking at other solutions for outbound firewalling. Might still want vMX for branch connectivity, but A server environment that big is going to ahve needs that an MX is not great for in my experience.

If you found this post helpful, please give it Kudos. If my answer solves your problem please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.