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.
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.
Identity can be KeyID or FQDN or Email. This is because some vendors (e.g. Cisco ASA firewall) don't support KeyID.
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
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
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:
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.
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.