...
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.
...
“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 You can configure up to 6 four WAN IP addresses (realistically you will probably only configure one or two). addresses per site but each one will count towards the tunnel count of the "As-A-Service" instance.
“Service Location” settings. This is size (which Sizedetermines how many sites can connect 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 CGSP GCP 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” 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 descripted described you will need to gather the following information information:
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.
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.
Create VPN tunnel.
Update routing and configure monitoring.
...
...
Dead Peer Detection (DPD) in IPSec requires five retransmissions and may take up to three minutes to determine if the peer is responding.
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).
...
Algorithm Type | Supported Algorithms |
Encryption | "AES128-GCM, AES256-GCM, AES-128, AES-256, ECP-256" |
Integrity Integrity/Authentication | SHA2-256, SHA2-384, SHA2-512 |
Diffie-Hellman Groups | 14 (2048-bit MODP) |
Lifetime | 48 hours |
Rekey time | 4 hours |
Phase 2 Crypto Settings (IPsec)
...
Algorithm Type
...
Supported Algorithms
...
Encryption
...
"AES128-GCM, AES256-GCM, AES-128, AES-256, ECP-256"
...
Integrity
...
SHA2-256 SHA2-384 SHA2-512
...
Diffie-Hellman Groups
...
14 (2048-bit MODP)
...
Lifetime
...
23 hours
...
Rekey time
...
4 hours
| Note |
|---|
Dead Peer Detection (DPD) in IPSec requires five retransmissions and may take up to three minutes to determine if the peer is responding. |
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. (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)
Phase 2 Crypto Settings (IPsec)
Algorithm Type | Supported Algorithms |
Encryption | AES128-GCM, AES256-GCM, AES-128, AES-256, ECP-256 |
Integrity/Authentication | SHA2-256, SHA2-384, SHA2-512 |
Diffie-Hellman Groups | 14 (2048-bit MODP) |
Lifetime | 23 hours |
Rekey time | 4 hours |
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.
...
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. 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 Cloud Availability Zone 1 but was previously connected to AZ2 Cloud Availability Zone 2 and is now disconnected (or vice versa), then tunnel will be considered in a degraded state.
...