Recently, our team was engaged with a federal customer who wished to deploy an Azure solution which would support IPSec site-to-site VPN connections to two separate on-premise endpoints. While providing connectivity options for our federal customers in this manner is commonplace, a unique technical requirement for one of these connections was presented to our team:
The solution must support an IPSec VPN connection from the customer subscription in Azure to the FBI Criminal Justice Information Services (CJIS) Division: Criminal Justice Information Services (CJIS) Security Policy — FBI. As part of this connection, all Azure source traffic, encapsulated and routed over the IPSec tunnel, must appear to originate from a range of public IP addresses which the connecting federal customer manages: https://www.arin.net/index.html.
So FBJ/CJIS needed to connect to a specific application on the customer’s network using public IP addressing – thus meeting the end-to-end public IP addressing requirement.
To address this requirement, our team obtained a publicly owned CIDR block from the customer and verified ownership via an ARIN lookup: https://www.arin.net/index.html.
Once validating that the CIDR block was indeed owned by the requesting federal customer, our team instructed the customer to remove or otherwise verify that the provided block was NOT advertised via the customer or providing ISP’s BGP routes. This was critical to ensuring the CIDR block would not be routable via both public internet and private CJIS<>Azure IPSec tunnel routes.
The next step was to assign the public CIDR block to the customer’s existing Azure vNet. This was accomplished by simply adding the block’s range to the vNet’s address space. It will show a warning, as shown here with a sample public IP block, but still allow the range to be added:
After adding the public CIDR block to the vNet, a subnet was created using this block. The application to which FBI/CJIS needed connectivity was placed in this subnet. The remainder of the subnets used private IP addresses.
Other Azure resources were then configured, including Azure Firewall and Azure Application Gateway as dictated by customer requirements. Using the new public range with these resources was simple: you simply created a firewall ruleset or gateway health probe using the public range as needed – just as you would with a private range.
Next, a site-to-site VPN Gateway was created with two connections: one to the customer’s on-premise network and the other to FBI/CJIS.
With the Azure Firewall in place, User Defined Routes (UDR) were applied to all subnets except the firewall subnet to ensure all traffic, regardless of source, was routed through the firewall.
The customer had a single vNet with multiple subnets. Though one of vNet IP ranges was public, Azure treated it no differently than the private ranges. Routing was seamlessly handled between subnets by Azure and between Azure and on-premise via BGP.
A packet going from FBI/CJIS to the customer’s application would: (1) leave the FBI network; (2) enter the customer VPN Gateway; (3) be routed from the VPN Gateway subnet to the Azure Firewall using a UDR placed on this subnet; (4) enter the Azure Firewall where a rule would permit it to proceed to the customer application; and (5) be routed to the customer application subnet and application. A public IP address would be used during this entire path. Return packets would follow the same path in reverse.
The diagram below illustrates the configuration and the public and private traffic flows.
While use of private IPs within Azure is recommended, this configuration illustrates how public IPs can be used when needed to address specific customer requirements.
Posted at https://sl.advdat.com/3CkL4V5https://sl.advdat.com/3CkL4V5
