...
“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. I believe you can configure up to 6 WAN IP addresses (realistically you will probably only configure one or two).
“Service Location” settings. This is size (which determines how many sites can connect 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 CGSP Asia East). Service IP which is the private IP address of your choice that will host the Capabilities (DNS/DHCP/DNS Security)
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.
...
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. 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 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.
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.
...
Configure security policy as applicable applicable.
Create VPN tunnel tunnel.
Update routing and configure monitoring.
...
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. (e.g. 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)
Routing
As 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.
NIOSNIOS-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.
...
Remember that VPN will not work if there are no capabilities enabled on a service connection. Need a full list of possible status of the VPN tunnel and a full explanation of each one. Last list I saw was
Not Ready: The tunnel is not in a state of readiness…readiness. Full list of possible reasons that a tunnel may not be in a state of readiness (i.e. list of things user can go check/action).
Ready: The tunnel is in a state of readiness. (what is the difference between ready and connected)?
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 AZ1 but was previously connected to AZ2 and is now disconnected (or vice versa), then tunnel will be considered in a degraded state.
...