How to whitelist legit traffic blocked by IPFire DROP_HOSTILE

How to whitelist legit traffic blocked by IPFire DROP_HOSTILE

TL;DR

A normal firewall rule in the web UI can not override DROPHOSTILE, because the hostile chains are evaluated before your own rules. Instead, insert ACCEPT rules at the top of the HOSTILEDROPIN and HOSTILEDROPOUT chains from /etc/sysconfig/firewall.local. Verify with the firewall log: the DROPHOSTILE lines for that IP stop appearing.

Quick check: is it really the hostile list?

location lookup 162.251.63.43

Expected output when the network is flagged:

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

Confirm the drops in the log:

grep DROP_HOSTILE /var/log/messages | grep "162.251.63.43" | head

If the log prefix matches and the lookup says hostile, this skill applies.

Why a web UI rule does not work

On the firewall's iptables page the chain order shows HOSTILE first, ahead of blocklists, IPS, the location block, and your own rules. The drop-hostile toggle was deliberately built as a dedicated chain so it never interferes with other rules, which also means other rules can never override it. ACCEPT rules have to go inside the hostile chains themselves, above the DROP.

Steps

1. List the exact IPs you need to exempt. Prefer single /32 addresses over whole ranges; whitelisting a full /24 punches a bigger hole than you need.
2. Edit /etc/sysconfig/firewall.local and add a start/stop block. Replace the example IPs with yours:

#!/bin/sh
# Exempt legit IPs from DROP_HOSTILE by inserting ACCEPT rules at the
# top of the hostile chains. Runs at every firewall start.
WHITELIST="162.251.63.43 38.54.123.57"
eval $(/usr/local/bin/readhash /var/ipfire/optionsfw/settings)
case "$1" in
  start)
    if [ "$DROPHOSTILE" = "on" ]; then
      for ip in $WHITELIST; do
        for chain in HOSTILE_DROP_OUT HOSTILE_DROP_IN; do
          iptables --check $chain -s $ip -j ACCEPT >/dev/null 2>&1 || \
            iptables --insert $chain -s $ip -j ACCEPT
          iptables --check $chain -d $ip -j ACCEPT >/dev/null 2>&1 || \
            iptables --insert $chain -d $ip -j ACCEPT
        done
      done
    fi
    ;;
  stop)
    for ip in $WHITELIST; do
      for chain in HOSTILE_DROP_OUT HOSTILE_DROP_IN; do
        iptables --check $chain -s $ip -j ACCEPT >/dev/null 2>&1 && \
          iptables --delete $chain -s $ip -j ACCEPT
        iptables --check $chain -d $ip -j ACCEPT >/dev/null 2>&1 && \
          iptables --delete $chain -d $ip -j ACCEPT
      done
    done
    ;;
esac

3. Make it executable and apply it:

chmod +x /etc/sysconfig/firewall.local
/etc/sysconfig/firewall.local start

Expected: no output on success. Check the rules landed at the top of the chains:

iptables -L HOSTILE_DROP_OUT --line-numbers | head

Expected: your ACCEPT lines listed as numbers 1 and 2, above the LOG and DROP lines.

4. Verify the drops stop:

grep DROP_HOSTILE /var/log/messages | grep "162.251.63.43" | tail

Expected: no new lines after the rules were inserted. Your service (CDN fetch, API call) starts working.

When this applies

• /var/log/messages shows DROP_HOSTILE for IPs you trust.
• location lookup on the IP reports "Hostile Network safe to drop: yes".
• The IP belongs to a CDN, image host, cloud provider, or NTP pool server sitting on a flagged announced network.
• Recent Core Updates where the chains are named HOSTILEDROPIN and HOSTILEDROPOUT.

When this does not apply

• The drop prefix is something else (DROP_CTINVALID, location block, IPS): different mechanism, different fix.
• You want the whole hostile feature off: uncheck "Drop packets from and to hostile networks" under Firewall Options instead, and accept the lost protection.
• The IP is hostile for a real reason (abuse reports you agree with): do not whitelist it.

Variant phrasings

• "Can I whitelist one IP so it does not get DROP_HOSTILE" - same fix, the community thread that documented the firewall.local approach.
• "HOSTILEDROPIN / HOSTILEDROPOUT" - the chain names on current Core Updates; older ones use a single HOSTILE_DROP chain.
• NTP pool servers blocked: same fix works, or switch the time service to a country-specific pool with fewer flagged servers.

Why it happens

IPFire builds the hostile list from Spamhaus DROP and similar feeds, which flag whole announced networks based on abuse reports against the provider. Legitimate services hosted on those networks (CDN nodes, image hosts, NTP pool members) get dropped as collateral. The list refreshes from the feeds, so a network can flip to hostile after your service was already using it.

Edge cases

• Older Core Updates name the chain HOSTILE_DROP (singular). Adjust the chain names in the script.
• firewall.local runs at every firewall start, so the exemptions survive reboots. If you edit the whitelist later, re-run the start action.
• The script only inserts when drop-hostile is enabled, and the --check guards keep it idempotent across repeated runs.
• If the provider moves the service to a different network, the old whitelist entry goes stale: re-run location lookup on the new IP.
• Whitelisting weakens the hostile protection for those IPs. Only exempt addresses you actually need.

Provenance

Resolved from the public thread: https://community.ipfire.org/t/drop-hostile-blocking-legit-traffic/16176

Provenance

Resolved from the public thread: https://community.ipfire.org/t/drop-hostile-blocking-legit-traffic/16176

In IPFire Community: "DROP_HOSTILE blocking legit traffic" (https://community.ipfire.org/t/drop-hostile-blocking-legit-traffic/16176): poster's CDN and NTP traffic dropped because whole announced networks are flagged hostile; location lookup confirms "Hostile Network safe to drop: yes" per network. Source: https://community.ipfire.org/t/drop-hostile-blocking-legit-traffic/16176