On Dec 22 19:54:28, Forman, Jeffrey wrote:
> On Wed, Dec 22, 2010 at 5:41 PM, Jan Stary <[email protected]> wrote:
>
> > Speculation: this looks to me like an end of a valid http session:
> > an internal clients reads a web page, and probably a few images,
> > everything goes through, but the last FIN does not. The first SYN
> > creates state that lets the subsequent packets through. Doesn't the
> > last FIN belong to the same state? Also, this is an outgoing packet,
> > which I explicitly allow.
> >
> > What can possibly be blocking these FIN packets?
> >
> >
> Jan,
>
> I have run into a similiar situation where I had packets getting blocked
> through my OpenBSD fw and could not figure out why.
>
> The couple pieces of code I tend to use to debug such a thing:
>
> 1. The 'log' and 'log (all)' statements in pf.conf. Take your pick of the
> two and throw them on all your block statements.
Yes, that's how I see the blocked packets.
> 2. Following that, I run 'tcpdump -n -ttt -e -i pflog0'. This shows me not
> only the packets being logged, but also the pf rules blocking them. Example:
> Dec 22 19:24:13.564109 rule 8/(match) block in on vr0: 115.178.83.69.6000 >
> 96.21.64.23.2967: S 449708032:449708032(0) win 16384 [tos 0x20]
Thanks. It's some time I have read tcpdump(8).
09:07:02.849975 rule 15/(match) block in on vr1: mac.stare.cz.54254 >
www.ihned.cz.www: F 2622397051:2622397051(0) ack 1936803033 win 65535
<nop,nop,timestamp 743577732 1811533502> (DF)
> I see this is rule 8. I then run 'pfctl -s rules -vv'
> [...]
> I find that by combining these two debugging tools, I am able to pin
> point the rule that might be blocking a specific set of connections.
The rule that's blocking my FIN packets is the "block drop log all".
Which is the only block rule I have, the rest of pf.conf just
explicitly allows the intended traffic (see the original mail).
So my question remains: if these are FINs of the few http conections
that take place when an internal client looks at www.ihned.cz (which it
seems), why are they not let through by the state that was created form
these connections?
This is blocked 'in' on the internal interface (vr1),
where the 'in' rules are (see orig mail for full pf.conf):
pass in on $int proto icmp from any to ($int)
pass in on $int proto { tcp udp } from any to ($int) port bootps
pass in on $int proto { tcp udp } from any to ($int) port domain
pass in on $int proto tcp from any to ($int) port ssh
pass in on $int from any to !($int) tag INT
Maybe I am missing something here: the first four rules are supposed
to allow traffic from the internal hosts to the gateway itself (dhcp
etc), and the fifth rule is supposed to pass traffic to the outside
(which gets natted later on the external interface). A packet such as
mac.stare.cz.54254 > www.ihned.cz.www: F 2622397051:2622397051(0)
seems to me to be that case (right?).
The only communication that the internal client (mac.stare.cz) has with
the outside host (www.ihned.cz) is that a browser (firefox) is used
to look at a webpage. If the internal clients does the same with lynx,
there are no blocked FIN packets on the internal interface.
What am I missing here?
Thank you for your time
Jan
