Differences

This shows you the differences between two versions of the page.

--- infoblox:firewall_rules [2025/08/08 15:24] – bstafford
+++ infoblox:firewall_rules [2026/03/12 11:36] (current) – [To DHCP Partner] bstafford
@@ Line 27: / Line 27: @@
+===== Rules for Data Connector =====
+When you have the Infoblox Cloud Data Connector (in cloud) "as a service" sending directly cloud-to-cloud to Sentinel/Splunk/etc using HTTPS, then the traffic will come from the following IP that [[https://docs.infoblox.com/space/BloxOneCloud/774931918/Data+Connector+HTTP+Destination+for+MS+Sentinel+and+Splunk+(Data+Connector+to+On-prem+or+Cloud)|you may need to put in an allowlist in Sentinel/Splunk]].
+  * 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 ====
 Documented [[https://docs.infoblox.com/space/BloxOneThreatDefense/35374317/Downloading+Endpoint|here]] and [[https://docs.infoblox.com/space/BloxOneThreatDefense/331874469/Best+Practices+for+Endpoint|here (best practice)]].
@@ Line 69: / Line 76: @@
 | 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  3.11.119.74 | 13.42.84.27 | ld1.threatdefense.infoblox.com | ld2.threatdefense.infoblox.com |
-| 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 | |
-| Hyderabad (India) | 65.2.108.69 | 65.1.29.110 | mb1.threatdefense.infoblox.com | |
-| Hong Kong | 18.166.181.249 | | ec2-18-166-181-249.ap-east-1.compute.amazonaws.com |  |
-Hyderabad also has:
-  * 65.0.152.93
-  * 3.7.67.223
-  * 13.203.91.21
-  * 98.130.91.165
-  * 18.60.104.39
-You can get this list above by retrieving all records for ''threatdefense.bloxone.infoblox.com''.
 ==== Threat Defense Notes ====
@@ Line 144: / Line 127: @@
   * ntp3.wirehive.net
   * 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 ====
-Active member of a Advanced Active/Passive HA pair talks to the passive member on tcp-847. Application is grpc and it uses HTTP/2.
+Active member of a Advanced Active/Passive HA pair talks to the passive member on tcp-847. Two traffic flows (GRPC and HTTP) run to this port.
+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 ====
 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.