infoblox:firewall_rules
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| infoblox:firewall_rules [2025/01/06 17:24] – bstafford | infoblox:firewall_rules [2026/03/12 11:36] (current) – [To DHCP Partner] bstafford | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Infoblox Firewall Rules ====== | ====== Infoblox Firewall Rules ====== | ||
| + | ===== NIOS Firewall Rules ===== | ||
| + | [[https:// | ||
| ===== Documentation Page ===== | ===== Documentation Page ===== | ||
| To access the [[https:// | To access the [[https:// | ||
| Line 7: | Line 8: | ||
| * static-us.dg.refined.site | * static-us.dg.refined.site | ||
| + | ===== BloxConnect ===== | ||
| + | * DST FQDN - grpc.csp.infoblox.com | ||
| + | * DST Port - 443 | ||
| + | * SRC Port - 26749 | ||
| + | * Protocol - TCP | ||
| + | * Only runs if BloxConnect is enabled. | ||
| + | * Once an appliance is elected to send data, it will not try to elect other members until and unless data sending is failed with previous elected node | ||
| + | * If the appliance that was sending data to BloxConnect fails to send data (can't connect) then all members of a Grid will test connectivity once every 24 hours | ||
| + | * When BloxConnect is disabled, data is synced to all members every 8 hours. | ||
| + | |||
| + | Election Logic | ||
| + | - CSP Connected GM (active node) (i.e. with Join token) | ||
| + | - CSP Connected GMC (i.e. with Join token) | ||
| + | - CSP Connected Member (i.e. with Join token) | ||
| + | - GM with connectivity to CSP | ||
| + | - GMC with connectivity to CSP | ||
| + | - Member with connectivity to CSP | ||
| + | |||
| + | |||
| + | ===== Rules for Data Connector ===== | ||
| + | When you have the Infoblox Cloud Data Connector (in cloud) "as a service" | ||
| + | * 3.221.42.234 (prd1.threatdefense.infoblox.com) | ||
| + | |||
| + | ===== Asset Insights ===== | ||
| + | When configuring public cloud to allow access from Infoblox Portal to your public Cloud API for discovery, you may need to add the following IP to an allow list. | ||
| + | * 3.221.42.234 (prd1.threatdefense.infoblox.com) | ||
| ===== Rules for Endpoint ==== | ===== Rules for Endpoint ==== | ||
| Documented [[https:// | Documented [[https:// | ||
| Line 12: | Line 39: | ||
| ===== Infoblox Threat Defense ===== | ===== Infoblox Threat Defense ===== | ||
| + | In some cases, firewalls will block any attempt to resolving DNS other than through DFP running on Infoblox. This can create a chicken-egg situation where NIOS needs to connect to Infoblox to get resolution but can't because it can't resolve *.infoblox.com. This is why the DFP has its own setting for DNS resolver to use and why NIOS/NIOS-X should be permitted access to the Infoblox Anycast IP addresses (see below) on udp-53 and tcp-53. | ||
| Line 23: | Line 50: | ||
| * '' | * '' | ||
| * +any of the Geo specific ones above (see below). | * +any of the Geo specific ones above (see below). | ||
| + | * '' | ||
| + | * '' | ||
| IPv6 DNS Anycast addresses: | IPv6 DNS Anycast addresses: | ||
| * '' | * '' | ||
| Line 45: | Line 73: | ||
| | Johannesburg (South Africa) | 52.119.41.62 | 103.80.6.62 | af-south-1-geo.threatdefense.infoblox.com | | | Johannesburg (South Africa) | 52.119.41.62 | 103.80.6.62 | af-south-1-geo.threatdefense.infoblox.com | | ||
| | Ohio (USA) | 52.119.41.63 | 103.80.6.63 | us-east-2-geo.threatdefense.infoblox.com | | | Ohio (USA) | 52.119.41.63 | 103.80.6.63 | us-east-2-geo.threatdefense.infoblox.com | | ||
| + | | Hyderabad (India) | 52.119.41.64 | 103.80.6.64 | ap-south-2-geo.threatdefense.infoblox.com | | ||
| + | | Hong Kong | 52.119.41.65 | 103.80.6.65 | ap-east-1-geo.threatdefense.infoblox.com | | ||
| - | ^ Region ^ Exit IPv4 Address ^ Exit IPv4 Address ^ Hostname 1 ^ Hostname 2 ^ | ||
| - | | California (USA) | 50.18.3.254 | 52.52.152.211 | ca1.threatdefense.infoblox.com | ca2.threatdefense.infoblox.com | | ||
| - | | Virginia (USA) | 3.221.42.234 | 3.210.133.138 | prd1.threatdefense.infoblox.com | prd2.threatdefense.infoblox.com | ||
| - | | London (England) | 3.9.234.55 | ||
| - | | Frankfurt (Germany) | 18.158.253.104 | 18.156.59.212 | fk1.threatdefense.infoblox.com | fk2.threatdefense.infoblox.com | | ||
| - | | Mumbai (India) | 65.0.152.93 | 3.7.67.223 | mb1.threatdefense.infoblox.com | | | ||
| - | | Tokyo (Japan) | 13.230.205.59 | n/a | jp1.threatdefense.infoblox.com | | | ||
| - | | Singapore | 54.179.114.1 | n/a | sg1.threatdefense.infoblox.com | | | ||
| - | | Toronto (Canada) | 3.96.72.179 | n/a | to1.threatdefense.infoblox.com | | | ||
| - | | Sydney (Australia) | 3.104.250.224 |n/a | sy1.threatdefense.infoblox.com | | | ||
| - | | San Paulo (Brazil) | 54.94.69.164 | n/a | sp1.threatdefense.infoblox.com | | | ||
| - | | Bahrain (UAE) | 15.184.140.118 | n/a | br1.threatdefense.infoblox.com | | | ||
| - | | Johannesburg (South Africa) | 13.245.50.242 | n/a | ec2-13-245-50-242.af-south-1.compute.amazonaws.com | | | ||
| - | | Ohio (USA) | 3.143.123.31 | n/a | ec2-3-143-123-31.us-east-2.compute.amazonaws.com | | | ||
| - | |||
| - | You can get this list above by retrieving all records for '' | ||
| ==== Threat Defense Notes ==== | ==== Threat Defense Notes ==== | ||
| Line 85: | Line 99: | ||
| * '' | * '' | ||
| + | ===== Asset Insights ===== | ||
| + | API calls to public cloud come from '' | ||
| ===== NIOS-X Firewall Rules ===== | ===== NIOS-X Firewall Rules ===== | ||
| ==== IP Allow List ==== | ==== IP Allow List ==== | ||
| Line 112: | Line 127: | ||
| * ntp3.wirehive.net | * ntp3.wirehive.net | ||
| * motd.ubuntu.com | * motd.ubuntu.com | ||
| + | |||
| + | FYI: | ||
| + | * Platform Management - Handles communication between NIOS-X and Infoblox Portal. Runs underlying OS and Kubernetes - that is all. Not aware of applications. | ||
| + | * Application Management - Handles various services running on NIOS-X itself. This is the system that reaches out to Infoblox Portal to download updated application images. | ||
| ==== To DHCP Partner ==== | ==== To DHCP Partner ==== | ||
| - | Active member of a Advanced Active/ | + | Active member of a Advanced Active/ |
| + | |||
| + | Both members of an DHCP HA pair talk to each other on udp-647 (heartbeat). | ||
| - | Both members of an DHCP HA pair talk to each other on udp-647. | ||
| + | tcp-647 for Kea HA (also used in hub-spoke Kea HA) | ||
| ==== Changing NIOX-X Server IP ==== | ==== Changing NIOX-X Server IP ==== | ||
| When the IP address of a NIOS-X virtual server is changed, for a while after the change the internal docker image will try to access certain ports of the device using the old IP. Therefore you may see, in your network traffic logs, traffic from the new IP to the old IP on the following ports. | When the IP address of a NIOS-X virtual server is changed, for a while after the change the internal docker image will try to access certain ports of the device using the old IP. Therefore you may see, in your network traffic logs, traffic from the new IP to the old IP on the following ports. | ||
| Line 198: | Line 219: | ||
| * US West Notification Server 44.224.71.15 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed) | * US West Notification Server 44.224.71.15 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed) | ||
| * US East Notification Server 3.221.42.234 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed) | * US East Notification Server 3.221.42.234 (Allow access from this IP to UDP-53 on NIOS. Use DNAT if needed) | ||
| - | + | | |
| - | | + | |
| + | * EU Notification server 52.58.79.200 (traffic from this IP to your DNS RPZ server) | ||
infoblox/firewall_rules.1736184277.txt.gz · Last modified: by bstafford