On Sat, Dec 13, 2003 at 01:47:28AM +0200, Toni Riekkinen wrote:
> $IPT -A FLAGS -m state --state INVALID -m limit --limit 5/minute -j
> LOG --log-level debug --log-prefix "INVALID: "
As far as I understand iptables, this will block packets invalid in
context of state lookups, defined as
"A packet which could not be identified for some reason: this includes
running out of memory and ICMP errors which don't correspond to any
known connection. Generally these packets should be dropped."
http://www.seifried.org/lasg/firewall/iptables.html
> INVALID: IN=eth0 OUT= MAC=<protected> SRC=<client ip> DST=<my server ip>
> LEN=56 TOS=0x00 PREC=0x00 TTL=57 ID=60965 PROTO=ICMP TYPE=3 CODE=1 [SRC=<my
> server ip> DST=<client gw> LEN=40 TOS=0x00 PREC=0x00 TTL=57 ID=41195 DF
> PROTO=TCP INCOMPLETE [8 bytes] ]
This is an incoming ICMP host unreachable error, referring to a TCP
packet.
> INVALID: IN=eth0 OUT= MAC=<protected> SRC=<client ip> DST=<my server ip>
> LEN=56 TOS=0x00 PREC=0x00 TTL=248 ID=7106 PROTO=ICMP TYPE=11 CODE=0 [SRC=<my
> server ip> DST=<client gw> LEN=40 TOS=0x00 PREC=0x00 TTL=1 ID=30431 DF
> PROTO=TCP INCOMPLETE [8 bytes] ]
An incoming ICMP time exceeded error, referring to a TCP packet.
To find out whether those ICMP errors are really invalid, I suggest you
run tcpdump on both interfaces of the OpenBSD box, looking for ICMP
packets which end up getting logged like those above, to answer the
following questions:
a) Who generated the ICMP errors? If you see them in the tcpdump
of the client-side interface, the client sent them (the source
ethernet address would also match the client). If not, do you
see them in the tcpdump of the server-side interface? If so,
pf (or the OpenBSD stack) must have generated them (odd, since
you don't block return-icmp at all). If you see them in neither
tcpdump, they don't pass through the OpenBSD box at all, find
out where they come from (other gateways?).
b) Look at the inner TCP header of the ICMP errors, it contains
the referred-to TCP connection's source/destination address/
port. Is there such a TCP connection?
c) Find out what other criteria make an (ICMP) packet invalid
for iptables (matching --state INVALID). Invalid checksums?
Check the tcpdump of the server-side interface, are there
invalid checksums?
Your pf ruleset looks fine. One possible explanation for the effects
you describe would be that, somehow, client and server can talk
directly, bypassing the firewall, for instance when there's some path
between them that doesn't go through the bridge (like two hubs, one on
either side of the bridge, and a cable connecting the hubs in parallel
to the bridge). The 'modulate state' would cause pf to modify TCP
sequence numbers, while the other path would deliver copies with
unmodified sequence numbers, causing such confusion.
To test this theory, you could replace 'modulate state' with 'keep
state' for the TCP rule, and check whether the messages go away. If so,
that would strongly suggest such a parallel link exists. Also, tcpdump
on the client and server would show duplicate packets.
Apart from that (somewhat obscure) case, I can't think of an
explanation, I'd tcpdump a single TCP connection until a related ICMP
error gets logged.
You are sure that just disabling pf (pfctl -d) stops the messages logged
by iptables?
Daniel
