A typical organisations deployment usually will have existing infrastructure deployed such as Azure Firewalls, Load Balancers and Virtual Network Gateways (VPN termination) to front access into IaaS VM’s, App Services and other systems.

Larger organisations will have policies (or should!) around governance of configuration within their cloud deployments. Smaller ones should at least consider it. Common practice is to safeguard admins from creating things such as new Azure AD deployments in each subscription, deploying oversize or very costly VM’s, adding new vNets or even NSG’s. These can all be controlled with appropriate Azure Policy and AAD Roles.

A common policy is to stop admins from creating new Public IP addresses. Why do you need them when you have existing Express Route conections from your corprate sites, or other methods of connectivity. You can effectivly bypass layers of security controls and services by simply provisioning a new device. Hence its a sensible control.

This poses an issue however. Most 3rd party appliances from the store require a public IP address to be created. For instance the Cisco ASAv, Palo Alto NG Firewalls, F5 BIG-IP (although they have recently recoginsed the issue and make some templates availible without) and other services.

Consider the diagram below showing the relationship of key Azure constructs and components with a deployment.

azure components

It shows how a VM has components associated with it such as disks and Network Interfaces. The Network Interfaces are connected to a subnet, which is part of a Virtual Network (vNET). The Network Interface is also associated with a Public IP Address.

However, there is an important concept in Azure to grasp. That is that any service deployed in Azure with a public facing IP does not have knowledge of its public IP address. Even though a Network Interface may be associated with a Public IP address the host has no knowledge of it. Not its external IP address, routing, nothing. If it has a default route set, it will be via whatever subnet it is connected to. Unless it has a User Defined Route which allows an override of Azure routing.

The vendors do not make it easy to deploy devices without a Public IP address. In fact they may even state its not supported, although this would be difficult to prove. It is very possible to build devices this way. Luckilly, Azure and its fantasic ARM templates comes to the rescue.

Ill describe this in follow up posts (coming soon)