DROP_HOSTILE blocking legit traffic

[hjkl (H&M)]

I am currently running into an issue where legitimate traffic is being flagged and logged under DROP_HOSTILE. Specifically, routine CDN connections and API requests are triggering these kernel drops because entire hosting or CDN ranges appear to be blanket-blocked as hostile.

For example, I’ve observed traffic getting dropped for:

• i.postimg.cc (resolved to 162.251.63.43, ASN AS63023 - GTHost) which is a legitimate image hosting service.

• Huawei Cloud CDN nodes (under ranges like 38.54.123.0/24, ASN AS138915 - Kaopu Cloud HK Limited) tied to valid certificates belonging to Huawei Software Technologies Co., Ltd., which my devices rely on for normal operations.

Since these blocks impact legitimate usage, I am searching for a reason why these are blocked by DROP_HOSTILE?

External sources:
Huawei Certificate being logged for 38.54.123.57 IP logged by IPfire in Drop_HOSTILE logs: VirusTotal
OTX shows zero threats associated with that Huawei CDN IP: LevelBlue - Open Threat Exchange

How many of these:

 grep DROP_HOSTILE /var/log/messages | grep -v " DPT=443" | grep "38.54.123.5" | wc
     45    1080   11560

i.postimg.cc

 dig i.postimg.cc; location lookup 162.251.63.43

; <<>> DiG 9.20.18 <<>> i.postimg.cc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29613
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;i.postimg.cc.                  IN      A

;; ANSWER SECTION:
i.postimg.cc.           643     IN      A       162.251.63.43

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Sep 30 21:06:17 EEST 2026
;; MSG SIZE  rcvd: 57

162.251.63.43:
  Network                 : 162.251.62.0/23
  Country                 : United States of America
  Autonomous System       : AS63023 - GTHost
  Hostile Network safe to drop: yes
grep DROP_HOSTILE /var/log/messages | grep " DPT=443" | wc
    342    8208   88265

38.54.123.57:
  Network                 : 38.54.123.0/24
  Country                 : United States of America
  Autonomous System       : AS138915 - Kaopu Cloud HK Limited
  Hostile Network safe to drop: yes

Late edit: DPT=123 withy source IP = red0 also hit DROP_HOSTILE: I was using europe.pool.ntp for Time service and IPFire tried to reached some valid NTP servers under blanked ASN block. That was fixed by setting IPFire to use Germany based NTP servers instead entire Europe pool. But, the surprise to see NTP servers registered under Europe pool being blocked was quite big. I thought that as long as Time service is powered on the FW will ensure that daemon can reach any NTP server on the planet.

zgrep DROP_HOSTILE /var/log/messages* | grep "IN= OUT=ppp0"  | grep "DPT=123"| wc
   1160   23208  232213

 zgrep DROP_HOSTILE /var/log/messages* | grep "IN= OUT=ppp0" | grep -v "DPT=123"| wc
      0       0       0

So all DROP_HOSTILE coming from IPFire itself was for NTP sync.

[rachelwilson]

thats normal for drop hostile, it flags by announced network not by individual ip. whole hosting ranges get marked off abuse reports against the provider, so legit stuff sitting on those ranges gets caught too, ntp pool servers included. only real fix is whitelisting the specific ips or ranges in a firewall group and allowing them above the hostile rule.

[rachelwilson]

quick followup to my own reply above: i dug into the actual mechanism and wrote it up properly here: https://vectle.com/skills/skl_P10Gn6WH8a1isIx35CrqHA. the short version: the hostile chains are evaluated before your own firewall rules, so a web ui allow rule cant override the drop. the reliable fix is inserting accept rules at the top of the HOSTILE_DROP_IN/OUT chains via /etc/sysconfig/firewall.local, then watch the logs to confirm the drop_hostile lines for that ip stop. your location lookup output is exactly how you confirm which announced network is flagged.

[hjkl (H&M)]

I was aware of the firewall chain design and the lack of support in UI to build a rule that bypass so (SO!) many chains controlled by standard config.

This is the reason I have build these tools, one being a custom IPFire add-on:

Firewall diagram to expose the order of the chain for each table:

Firewall Diagram

Version 1.5.1 is released - nat and mangle tables fully expanded. Newly visible chains include SQUID (transparent proxy in nat/PREROUTING), IPS/Suricata chains (in mangle INPUT/FORWARD/OUTPUT), and CAPTIVE_PORTAL (nat/PREROUTING). [ipfire_pcb_firewall_core200_v1.5.1_TB]

A custom Firewall Local add-on with the ability to add to it any of the chains I see in the diagram and use them.

Firewall-local add-on

New add-on: Firewall-Local — modular firewall orchestration for IPFire Firewall-Local is an IPFire add-on that manages iptables/ipset rules through a small set of master-list files and a web UI, shipped as a standard .ipfire package. It adds five rule modules on top of IPFire’s native firewall, each with its own CGI page. The integration is achieved via /etc/sysconfig/firewall.local. Location Allow — INBOUND country allowlist. Default posture is drop everything; only the countries you add ca…

Plus, to overcome the limitations of my add-on (iptables does have some limits in a command structure) that add-on can consume custom scripts with dedicated syntax for special cases: allow any UDP 43 traffic (whois protocol) way above any chain that might block it: HOSTILE, LOCATION, any chain.

My question was rather a design one: knowing that UI does not allow us to create custom rules to bypass some of the chains, and some traffic is really critical for the box to function (NTP, DNS, arguably other - like whois used for investigating who is the attack that pounds my OpenVPN service once every 2 seconds), all that considered, I wonder if the design took these cases in consideration.

IPFire is the designated NTP server for my network - so if that fails to stay in sync, my clients using it will generate quite a few abnormal behaviors.