Every “Access Location” is considered a “Connection”. Each “Access Location” can have two WAN IP addresses. Each WAN IP address can establish two VPN tunnels to the “Service Location”. So you can have four VPN tunnels that are considered one “Connection”.

From Infoblox side, response goes back to tunnel that packet came down from (so customer can use any tunnel balancing method they like)

VPN at client side must have NAT-T enabled on Phase 1.

• Is a global forwarder required? If so, where? Does it require a known source Public IP dedicated to the customer (e.g. UK PDNS)
• Understand that Kea (DHCP used in NIOS-X and NIOS-XaaS) does not support Failover Associations. NIOS-X works with Kea “Active/Passive” and NIOS-XaaS uses something else.. “lift-n-shift” active leases to another POP is work in progress.
• Ensure customer understands that resiliency (as of Oc 2025) is only WITHIN a region between two separate AZ. Not “multi-region”. That is being worked on.
• Establish how many sites need to connect and what the VPN count will be.

Local On-Prem Resolution is supported for XaaS running Threat Defense. Both the security logs and the DNS logs will be visible in the Infoblox Portal. NIOS-X with “Local On-Prem Resolution” will only show Security Logs in Infoblox Portal.

If you deploy a Service Location of size “S” and need to add more than 10 connections, you just change the size in the UI to “M” or “L” or “XL” and you will be able to add more connections. The Service Location will change size with no service interruption.

Infoblox can spin up XaaS instance in any AWS/GCP POP other than China.

Availability Zones - within the region you have selected, NIOS-X will be deployed in TWO (no more, no less) Availability Zones in that region. Infoblox does not publish which AZ. If the region has more than two AZ then two AZ will be picked automatically for the customer. Infoblox does not publish which AZ the compute is deployed in. However, if you download a PCAP file for the POP via the Infoblox Portal, then you will notice that the file names are something like ddiaas_tcpdump_eu-west-2a_<serial> and ddiaas_tcpdump_eu-west-2b_<serial> which indicates where the AZ are located.

• eBGP only.
• At Access Location, “Neighbor IP” will be local router ID. Remote router ID will be Primary Neighbor IP or Secondary Neighbor IP depending on VPN tunnel.

Identity can be KeyID or FQDN or Email. This is because some vendors (e.g. Cisco ASA firewall) don't support KeyID.

• Policy based VPN not supported. Route based VPN only.

The first exchange for the Phase two will work as the PFS is only exchanged during the 'Create Child_SA' exchange this usually occurs during re-key hence we see the first time the phase two comes up with the PFS mismatch, as one of the traffic selector is used during the IKE_SA_Init, and IKE_AUTH exchange

RFC-5996 for reference.

No limit on number of WAN IP addresses. Infoblox test up to three WAN connections.

When you configure XaaS to forward domains to internal, on-prem servers (e.g. internal Auth DNS zones hosted on-prem), don't forget edit the DNS Profile associated with the XaaS DNS instance and either disable DNSSEC validation or add the internal domain to the “Validation Exceptions” list. If you don't do either of these, it is likely that resolution will fail because XaaS won't be able to validate the domain using DNSSEC.

When getting XaaS to transfer a zone from On-Prem to XaaS, remember that any connection may come from the secondary neighbor IP which will come down the secondary VPN tunnel. Be sure to make sure your routing to the secondary neighbor IP is down the secondary VPN tunnel and not the primary.

XaaS should actually send AXFR requests down both tunnels from XaaS to on-prod when transferring zones (i.e. primary neighbor IP does an transfer and secondary neighbor IP does a transfer as well)

When configuring BPG between XaaS and Palo Alto Networks firewall, you may need to edit tbe multihop setting in peer configuration in the BGP configuration on the Palo Alto Networks firewall and change the default from 0 to 2 as per this guide.

Network > Virtual routers > BGP > Peer Group > Peer > Multi Hop

• NIOS-XaaS currently accepts up to 100 routes over BGP.
• NIOS-XaaS recognized BGP Path Prepending and will prefer shorter paths over longer paths when it gets the same route from multiple peers.
• NIOS-XaaS will not use ECMP when it gets the same route from multiple peers. It will maintain one path at any given time. It will choose based on Path length (shortest is preferred), MED Metric (lowest is preferred) and router ID (lowest is preferred).
• 2 byte AS numbers have a max vlue of
  • RFC 4893 defines 2 byte AS numbers (0 - 65,535)
  • RFC 6996 defines private range of 2 byte AS numbers (64,512 - 65,534 inclusive)
• 4 byte AS numbers have a max value of 4,294,967,295
  • RFC 4893 defines 4 byte AS numbers (0 - 4,294,967,295)
  • RFC 6996 defines private range of 4 byte AS numbers (4,200,000,000 - 4,294,967,294 inclusive)
  • ASN reserved by ARIN for private use

BGP 4 Byte information here.

Auto location selection of Service works based on the nearest active POP to the geometric center of all Access Locations.

NIOS-XaaS can run in ANY AWS/GCP POP other than China. You just have to ask your Infoblox account team if it isn't already live. The account team will directly engage with the Product Management team to get the new POP spun up.

List of Active Locations here.

Excellent article on IKEv2 AES-256-GCM and SHA-384 by Markku Leiniö.

When setting up a site-to-site IPsec VPN and selecting AES-256-GCM for encryption, there is no need to configure a separate authentication (integrity) algorithm because AES-GCM is an authenticated encryption algorithm that integrates both encryption and integrity protection in a single operation.

AES-GCM (Advanced Encryption Standard in Galois/Counter Mode) operates as a combined mode algorithm that simultaneously provides:

• Confidentiality through AES encryption, and
• Integrity and authenticity through a built-in GMAC (Galois Message Authentication Code) function.

Traditional AES modes like CBC (Cipher Block Chaining) require a separate hash function such as SHA-256 or SHA-384 to ensure packet integrity. In contrast, GCM integrates this function internally, generating an authentication tag for every data packet. This tag verifies that the message has not been altered in transit — eliminating the need for an additional integrity algorithm like HMAC-SHA. However, AES-GCM needs a hashing function for PRF (Pseudo-Random Function). That’s why you need to select something like SHA-256 or SHA-384 with AES-GCM. However, Palo Alto Networks automatically sets PRF so in the PAN-OS GUI you set Authentication to “non-auth”. Fortinet requires that you specify PRF.

• IKE = Internet Key Exchange, the way to securely negotiate IPsec (Internet Protocol Security) encryption between two VPN (Virtual Private Network) tunnel peers
• AES = Advanced Encryption Standard
• GCM = Galois/Counter Mode
• CBC = Cipher Block Chaining
• SHA = Secure Hash Algorithm

Be aware that PFSense is acting as a DHCP relay, it won't work for NIOS-XaaS due to how the interface binding works with VPN tunnel (PFSense issue, not Infoblox). If you use PFSense and another switch is being DHCP relay, that will work. OPNsense can act as a DHCP relay.