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. When configuring the as-a-Service, these are referred to as "Access Locations" because it is where the as-a-Service services are accessed from.

• A “As-A-Service” instance (Configure > Service Deployment > As-A-Service) that links to the Location(s) 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, Location, Credential (PSK) and WAN IP Address(es).  You can specific up to two public IP addresses for a single site.

• “Service Location” settings. Size determines how many locations can use the Service Location and how many Universal DDI Server tokens the Service Location will require. The Location setting specifies where POP will be geographically located (e.g. AWS Europe or GCP US West).

• 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 that will be used as the source IP when the Service Location initiates traffic to on-prem (for example, forwards a DNS request from the POP to a DNS server that is on-prem).

• Secondary Neighbor IP: The IP that that will be used as the source IP when the Service Location initiates traffic to on-prem.  (e.g. forwards a DNS request from the POP to a DNS server that is on-prem). This is the backup of the Primary Neighbor IP as it exists in a separate availability zone in the POP.

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. Each IP is associated with a seperate public cloud availability zone. 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. The format can be changed in the configuration as KeyID (default), FQDN or Email.  

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. 

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 labelled as “Identity”. If it is of type "KeyID" it is a string of random characters (e.g. zx4fstsqyni5yxub).

Phase 2 Crypto Settings (IPsec) 

Routing 

NIOS-XaaS does not currently support dynamic routing. You will need to configure a static route(s) on your firewall/router to direct traffic destined for the NIOS-XaaS service IP through the VPN tunnel(s). If a DNS query is sent to the cloud via one tunnel, the response will routed back down that same tunnel (same for DHCP traffic). The service IP is pingable which can be used for route monitoring by your firewall/router. You can also configure ECMP for the Service IP Route.

 Routes should also be created for the primary neighbor IP and secondary neighbor IP address. The primary neighbor IP address can only be accessed through the primary VPN tunnel. The secondary neighbor IP address can only be accessed through the secondary VPN tunnel. For this reason, route monitoring and ECMP should not be used for the routes for primary and secondary neighbor IP addresses.

Troubleshooting 

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

Tunnel status information is sent to Health Monitor Service (HMS), where IPsec Tunnel status is aggregated from all IPsecEP pods. It will go to degraded, if any one of the tunnel status is not-connectedTunnel status is further interpreted based on the aggregation policy and marked as degraded. The composite status is displayed to user.

The following tunnel service statuses are reported:

• Not Ready (status color ORANGE ): Indicates that the service is in the process of being provisioned at the Infoblox POP (service location). This is a one-time state; it will not revert back to this state once it changes.

• Ready (status color ORANGE): Indicates the backend for the tunnel(s) is provisioned, but the link is not physically connected at the customer site. This is a one-time state; it will not revert to this state once it changes. 

• Connected (status color GREEN): All tunnels are active and operational on both ends: both the Infoblox PoP and the customer site (router). 

• Not Connected (status color RED): Indicates that all tunnels are down.

• Degraded (status color ORANGE): Indicates that there are multiple tunnels to one Availability Zone and one or more (not all) of the tunnels go down, or if any existing tunnel fails, it results in a degraded state. Degradation is based on tunnel metrics such as latency and packet loss.

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

• Palo Alto Networks

• Cisco