Before starting work on building an IPsec VPN tunnel between your on-prem firewall/router and the Infoblox’s NIOS-XaaS, you will need to setup some pre-requisites in the Infoblox Portal. 

•  A “PSK Credential” (Configure > Administration > Credentials. Add a “Pre Shared Key” credential. This is the IPsec VPN PSK. 

•  A “Location” (Configure > Administration > Location). The “Location” object represents the site that you are creating the VPN from. For example, if you have 20 offices that you want to connect to NIOS-XaaS, you will need to configure 20 locations. 

•  A “As-A-Service” instance (Configure > Service Deployment > As-A-Service) that links to the Location and PSK Credential.  

 Within an “As-A-Service” service instance, you configure “Service Deployment” where you configure “Access Locations” and “Service Location” 

• “Access Locations”. Where you specify the type (Site for now. AWS VPC is in development as of Sep 2024), Location, Credential (PSK) and WAN IP Address(es) (you can specific multiple public IP addresses for a single site/office if that office has multiple internet links. You can configure up to four WAN IP addresses per site but each one will count towards the tunnel count of the "As-A-Service" instance.

• “Service Location” settings. Size determines how many tunnels can be established to the instance and how many UDDI Server tokens will be consumed. The location which specifics which Infoblox POP will host this service (e.g. AWS Europe or GCP Asia East). Service IP is the private IP address of your choice that will host the Capabilities (DNS/DHCP/DNS Security).

• Primary Neighbor IP: The IP that sends the responses for queries initiated from the Service IP.

• Secondary Neighbor IP: The IP that sends the responses for queries initiated from the Service IP. This is the backup of the Primary Neighbor IP. 

Remember, as of September 2024, you MUST have one or more Capabilities (DNS, DHCP, Security) enabled for in the service for the VPN tunnel in the Infoblox Portal for the tunnel to be created properly for any of the “Access Locations” for that service instance of NIOS-XaaS. When creating a service and adding capabilities, you MUST click the tiny blue checkbox next to the capability for it to be saved. 

From the configuration previously described you will need to gather the following information: 

1. WAN Address. (From ‘Access Location’) This is YOUR public IP address at your site that you will use to establish the IPsec VPN tunnel to the Infoblox Cloud. This will be the public IP address that the Infoblox Cloud sees connections coming from and is the IP address you have configured in the “Access Location” for this site.  

2. Peer IP.  (From ‘Service Deployment’) This is the “Cloud Service IP” of the Infoblox Cloud that you are establishing the IPsec VPN tunnel to and is found on the summary tile of the Service Deployment. This is only visible after you create the Service Deployment. You will actually see two IP addresses per service location to allow for dual IPsec tunnels for resiliency. Traffic sent down one tunnel will get the answer back on that same tunnel so routing failover is up to the user to configure on their firewall (e.g. ECMP, tunnel monitoring with ICMP, etc). 

3. PSK (Pre-Shared Key). (From ‘Credentials) Used to authenticate the IPsec VPN tunnel from your device to the Infoblox Cloud. 

4. Local ID. (From ‘Service Deployment) This is used as part of the authentication process to establish the IPsec VPN tunnel from your device to the Infoblox Cloud. This is called the "Identity" in the Infoblox Portal and is found in the summary tile of the relevant "Service Deployment" object next to the Cloud Service IP.  

5. Service IP. (From ‘Service Deployment’) This is the private IP address inside the Infoblox Cloud that will host the DNS/DHCP capability. You will route to this IP over the IPsec VPN tunnel that you establish to the Infoblox Cloud. It is found in the summary tile of the relevant "Service Deployment" object next to the Cloud Service IP. 

To configure your on-prem firewall to connect to NIOS-XaaS you will need to work through the following steps: 

1. Configure security policy as applicable. 

2. Create VPN tunnel. 

3. Update routing and configure monitoring. 

 Security Policy 

 You will need to ensure that traffic can flow through the VPN tunnel and that the VPN tunnel can be established. The exact steps will vary depending on the device you are configuring (router/firewall/etc). 

 In principle, you will need to ensure that the following traffic flows are allowed on your network. 

 Source and Destination IP (this rule should be bi-directional): 

• You firewall IP. This is likely going to be the same as your “WAN Address” as defined earlier but it is possible you are setting up a device that is located inside the network and so this might be the private IP of your device and so your edge firewall must permit this traffic. 

• “Peer IP” as defined earlier. 

Application/Port: IKE (udp/500) and IPsec (udp/4500 and IPSec protocol)

You will also need to permit DNS and DHCP through the tunnel and you may want to allow ICMP as the “Service IP” is pingable through the VPN. 

Source IP: All internal IP addresses or subnets that should be able to access the capability (DNS/DHCP) 

• DNS (udp/53 and tcp/53) 

• DHCP (udp/67 and udp/68 and tcp/67 and tcp/68) 

• Ping (icmp) 

VPN Tunnel 

You will need to configure the IPsec VPN tunnel as per the vendor instructions for the firewall device you are using. The following information is relevant.  

Phase 1 Crypto Settings (IKE) 

Phase 1 Configuration (IKE) 

• Only IKEv2 is supported. IKEv1 is not supported. 

• It is important that NAT Traversal (NAT-T) is enabled even if your firewall is at the edge with public IP and doesn’t need NAT. Without it, the VPN will be established but data will not work over the VPN. This is because the NIOS-XaaS cloud side uses NAT.  

• The “Peer ID” in Phase 1 IKE is going to be a FQDN with value WAN.infoblox.com where WAN is replaced with your public IP address that you (the customer) initiate the VPN from to the Infoblox cloud.  (for example, 1.2.3.4.infoblox.com). Some firewall/router vendors (e.g. OPNSense) may not require Peer ID to be configured. Other vendors (e.g. Palo Alto Networks, Cisco, etc) do require Peer ID to be configured correctly. 

• The “Local ID” in Phase 1 IKE is found in the Infoblox Portal labeled as “Identity”. It is a string of random characters (e.g. zx4fstsqyni5yxub) 

Phase 2 Crypto Settings (IPsec) 

Routing 

As of September 2024, NIOS-XaaS does not support dynamic routing. You will need to configure a static route on your firewall to point traffic destined for the Service IP through the VPN tunnel. 

NIOS-XaaS supports two public IP addresses per POP. This allows you to configure two VPN tunnels from your WAN for the purpose of resiliency. The NIOS-XaaS cloud will respond to traffic from either tunnel. Traffic will be returns to the tunnel the original query came in from. If a DNS query is sent to the cloud via one tunnel, the response will routed back down that tunnel. This means it is up to the user to configure tunnel failure detection at their end to allow the alternative tunnel to be used. For example, the firewall/router may allow ping to the Service IP to be used as a monitor and, if it fails, allow updating of the route table to use the other VPN tunnel. Alternatively you can configure ECMP across both tunnels and use tunnel detection and/or ping to remove the routes to any tunnel that has failed. 

Troubleshooting 

Remember that VPN will not work if there are no capabilities enabled on a service connection. 

• Not Ready: The tunnel is not in a state of readiness.

• Ready: The tunnel is in a state of readiness.

• Connected: The tunnel is connected. 

• Not Connected: The tunnel is not connected.  

• Degraded: The tunnel is degraded. For example, when a tunnel is connected to Cloud Availability Zone 1 but was previously connected to Cloud Availability Zone 2 and is now disconnected (or vice versa), then tunnel will be considered in a degraded state.

The following links provide information about configuring IPSec Tunnel on various routers:

• Palo Alto Networks

• Cisco