[Firehol-support] Help Needed - Debugging Implicitly Dropped Forwarded Packets

Costa Tsaousis costa at tsaousis.gr
Wed Dec 30 16:05:19 GMT 2009

Hi Federico,

Federico Sevilla III wrote:
> Hi,
> I hope someone can help me debug a situation regarding some implicitly
> dropped forwarded packets. Here is one sample log message:
>         Dec 29 12:44:52 firewall 'PASS-unknown:' IN=eth0 OUT=eth2 MAC=00:15:17:bf:70:64:00:11:d8:b1:c2:ba:08:00  SRC= DST= LEN=52 TOS=10 PREC=0x00 TTL=63 ID=16479 DF PROTO=TCP SPT=48985 DPT=80 SEQ=2105617222 ACK=3098975575 WINDOW=46 ACK URGP=0 
> On the outset, this looks really simple. For what should be a very
> "open" setup, just add:
>         router foo inface eth0 outface eth2
>                 server all accept
> But the above message about this implicitly dropped forwarded packet
> appeared with exactly that in the Firehol configuration file (properly
> restarted after the modification). Also to note that when Firehol is
> stopped, things work just fine. Unfortunately that is not how we want
> the firewall to operate. ;)
This packet is dropped by the iptables connection tracker, not firehol 

The iptables connection tracker believes this packet is not part of an 
existing connection; it is not a new connection (new TCP connections 
have the SYN bit set), so it drops it. The connection tracker has 
several sysctl parameters that can affect its operation (mainly 
timeouts), however the defaults are pretty good for general use.

Does this dropped packet appear every time you access the web server?
Does this dropped packet affect the client experience accessing the web 

> Now to describe the network, which may be a bit weird. These are two
> separate /24 networks with the firewall in the middle. is
> the workstation and is the server. The firewall has IP
> addresses and physical interfaces on each subnet. The firewall's
> address is the default gateway of
> is a virtual server, using OpenVZ. Its default gateway is the
> OpenVZ internal address, using the default venet. The hardware node,
> with multiple network cards, sits on both the and
> networks because of some other servers it hosts which
> shouldn't go through the firewall anymore to remove a bottleneck.
> Because of the routing tables on the OpenVZ hardware node, traceroutes
> from to no longer pass through the firewall. The
> traceroutes work when Firehol on the firewall is stopped, but no longer
> work when Firehol on the firewall is started.
> A trace from to would be:
> 1. (firewall)
> 2. (hardware node)
> 3.
> Meanwhile, a trace from to would be:
> 1. (hardware node)
> 2.
> When Firehol is stopped, both ping and HTTP works fine. With Firehol
> running:
> 1. is able to ping
> 2. is NOT able to ping
> 3. is able to connect to port 80 (eg: via
> telnet) but no responses are received to any data sent.
> Would appreciate advise on what Firehol rules should be able to solve
> this particular scenario.
FireHOL is stateful, meaning it allows packets to pass if they are:

1. allowed NEW connections, or
2. part of ESTABLISHED connections

This means that if a connection has parts of it passing through the 
firewall and parts of it not passing through the firewall, the iptables 
connection tracker cannot have the whole picture and packets may be dropped.
Even in this scenario though, you should have logs of the packets 
dropped. Do you?



More information about the Firehol-support mailing list