There are several ways to connect servers to Azure and enable them with Azure Arc, including using the Azure Arc Gateway. Today we will look at the options and when to use each of these.

Private Endpoints – Not an option?

I’m not considering private endpoints in my article and don’t recommend them now (Q4/2024). I understand the arguments for them, but I focus on simplicity and rely on Zero Trust, Entra ID for security. I accept that public endpoints are secure enough.

There is a full list of pro and cons shared by Microsoft in this article “https://learn.microsoft.com/en-us/azure/azure-arc/servers/private-link-security“, but I will highlight my main arguments against Private Endoints.

• Network traffic to Microsoft Entra ID and Azure Resource Manager does not traverse the Azure Arc Private Link Scope and will continue to use your default network route to the internet. (So basically you add complexity, but the identity and basic information with the highest security requirement, will still use public endpoints).
• Other Azure services that you will use, for example Azure Monitor, requires their own private endpoints in your virtual network.
• Remote access to the server using Windows Admin Center or SSH is not supported over private link at this time.

I am mostly working on projects to replace Windows Terminal Server based Jump Servers with Client VPN with a Modern Server Management solution based on Windows Admin Center in Azure and Entra ID functionality, which makes Public Endpoints mandatory for me.

There is a good architectural diagram from https://azurearcjumpstart.com/ that is visualizing the need to private and public endpoints in this context including extensions.

Public Endpoint option to Azure Arc enable Server

Option 1 – Use Proxy connection / no Azure Arc Gateway

The first option to review is a very classic ones for servers with no direct internet connect, but the requirement to use a proxy. This option can be implemented as Azure Arc enabled Servers can be configured using a proxy.

This connection does require all the URLs required for Azure Arc enabling a server on the squid proxy and on the Firewall. The basic list, check here, is already quite long and if you wat to use extensions, than this can be > 100 URLs for >10 Endpoints.

There is a sweet spot for this scenario, which is a proxy that has no URL filter and connected to a Next Gen Firewall with a category based URL filtering and allowing all Microsoft domains. While I try to avoid Proxies these day, this is a valid scenario for network segmented servers, that should communicate with Azure through the Next Gen Firewall, but Internet Access in their network segment is restricted and requires the proxy.

Important: The azure connected machine agent does not support user authentication, so you need to implement other access control features. Check my Blog on this topcic here.

Option 2 – Use Proxy connection with Azure Arc Gateway

The second option to review is also for the classic scenario, where servers with no direct internet connect, but the requirement to use a proxy. This option can be implemented as Azure Arc enabled Servers can be configured using a proxy.

This scenario does help with the similiar use case like option 1, but if you are not having a Next Gen Firewall with an URL based category filter. In this scenario you can use the Azure Arc Gateway to limit the number of URLs / IP Ranges to connect even further.

If you enable the Azure Arc Gateway with a Squid proxy you can limit the number of IPs communicating with the Firewall to 1 and the number of URLs to the very short list below. This makes using it significantly simpler with non next generation firewalls, that do require IP address white listening and normally cannot handle URLs.

Learn more about the Azure Arc Gateway Preview Option from Microsoft and check my full story around using and configuring it on this blog.

Option 3 – Use Azure Arc Gateway with no proxy

Option 3 is basically Option 2, but your organization is not using a proxy. This adds complexity on the Firewall as, as all servers need to be whitelisted to allow the communication port 443 using TCP to the below URLs. If you are in such an environement it is likely, that you have whitelistening for servers and can cover these changes relatively easy.

The list of URLs required is limited to the Azure Arc Gateway URLs mentioned before and listed here.

Option 4 – Use direct connection

The direct connection option is the one I have seen most customers transition to. Systems and servers are moved from IP based Firewalls to Next Gen Firewalls and eliminating proxy configurations. This simplifies both the server configuration, but also the network communication. All devices are using the routing tables and most of the time the default route to the “internet”. So you can use tools like WinMTR – check my guide here – instead of tools to trace down network traffic generated using proxy configurations on the OS level and in the browser. If you have been in that business, you know how much fun tracing down the used configuration on a browser or OS based level.

This configuration would be pretty complex if implemented in a new environment, but if you allow Internet Traffic from servers to URL categories from Microsoft and you have implemented a network segmentation or groups for your Windows / Linux servers, it can actually work “instantly” without any further configuration in most modern network designs.

What option is the best one for me?

As you can see from the details shared above, the anwer to this is, it depends. To help with your decision i created this basic decision diagram to help you visualize your architectural decision options.

This decision is one of most important ones. I highly recommend to involve all Stakeholders in this discusion. My recommendation is to start with IT-Sec, Firewall Team, Network Team, Proxy Team, Cloud Team and your server team. Document the decision well and use the above Options as a starting point. Things can get more complex in your environment, but you will most of the time come back to the above options.

Conclusion

I prefer simple designs with a high level of automation. While it may sound like Option 4 without the proxy and the Azure Arc Gateway does require the most URLs, it comes with the toolset to simplify and automate that requirements with the URL filter support in the 2nd gen firewalls.

Especially when you have to maintain a discussion and update procedure with many stakeholders, i.e. proxy / firewall / network / server / cloud team in Option 1, than it becomes very complex. Even if this scenario has the least number of URLs and IP address configurations.

This is a very good scenario and example for the “It depends” statement.

Documentation

Download the above drawings in my favorite format draw.io from my Github Repository

Check the Azure Arc Jump Start Website and register here for it’s monthly newsletter to learn about azure arcenabled servers and how to connect machines to Azure Arc.