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.
...
“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 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.
...
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.
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).
PSK (Pre-Shared Key). (From ‘Credentials') Used to authenticate the IPsec VPN tunnel from your device to the Infoblox Cloud.
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.
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.
...
In principle, you will need to ensure that the following traffic flows are allowed on your network.
Source IP | Destination IP | Port/Protocol/Application |
|---|---|---|
WAN IP/Peer IP | WAN IP/Peer IP |
|
All internal IP addresses or subnets that should be able to query DNS. | Service IP | DNS (upd-53/tcp-53) |
All internal IP addresses or subnets that should be able to access DHCP. | Service IP | DHCP (udp/67 and udp/68 and tcp/67 and tcp/68) |
All internal IP addresses or subnets that should be able to ping the service IP for troubleshooting. | Service IP | Ping (ICMP) |
| Internal DNS servers that NIOS-XaaS may forward to or transfer zones from. | DNS (upd-53/tcp-53 |
...
) |
...
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.
...
Algorithm Type | Supported Algorithms |
Encryption | AES128-GCM, AES256-GCM, AES-128, AES-256, ECP-256 |
Integrity/Authentication | SHA2-256, SHA2-384, SHA2-512 ("non-auth/none" if you are using a GCM Encryption) |
Diffie-Hellman Groups | 14 (2048-bit MODP) |
Lifetime | 48 hours |
Rekey time | 4 hours |
...
Algorithm Type | Supported Algorithms |
Encryption | AES128-GCM, AES256-GCM, AES-128, AES-256, ECP-256 |
Integrity/Authentication | SHA2-256, SHA2-384, SHA2-512 (if you are using a GCM Encryption, this can optionally be set to "non-auth/non") |
Diffie-Hellman Groups | 14 (2048-bit MODP) |
Lifetime | 23 hours |
Rekey time | 4 hours |
Routing
As of September 2024, NIOS-XaaS does not currently support dynamic routing. You will need to configure a static route(s) on your firewall/router to point direct traffic destined for the Service IP and Primary Neighbor IP and Secondary Neighbor 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 fromservice 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 . 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. (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.
...
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.
...