[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: surfing from behind the firewall, pf rules



On Tue, Nov 26, 2002 at 03:30:10PM -0800, Stephen Gutknecht (OBSD-PF) wrote:
> As for the blocks when surfing web sites.  They are always port 80 traffic
> going to my clients from servers they are surfing.  I see hits on my rule
> #11 (block in log on $ExtIF all).  These are signs that my rule #17 (pass
> out on $ExtIF all keep state) is not always keeping state?  Servers with
> problems?
You'd have to check the state table (pfctl -vss). My guess is that
states are created for all these outgoing connections, but they time out
before the connection is fully established.
Can you tcpdump -nvvvSpi <ext_if> host <server> for one of the servers
that host one of those images, and compare times with pfctl -vss? If
your initial TCP SYN creates state, the state will be removed if there
is no reply from the server within 30 seconds. You can adjust that value
using "set timout tcp.opening x" in pf.conf (with 3.2, for < 3.2 it's
pfctl -t tcp.opening=x).
> Nov 26 07:03:08.300311 rule 11/0(match): block in on tun0: 66.79.10.212.80 >
> 166.154.128.190.56084: . 0:1460(1460) ack 1 win 17520 (DF)
> Nov 26 07:04:11.700187 rule 11/0(match): block in on tun0: 66.79.10.212.80 >
> 166.154.128.190.56084: . 0:1460(1460) ack 1 win 17520 (DF)
These are ACKs being retransmitted by the server, until
> Nov 26 07:12:43.517003 rule 11/0(match): block in on tun0: 66.79.10.212.80 >
> 166.154.128.190.56084: R 4891:4891(0) ack 1 win 17520 (DF)
the server gives up and sends a final RST.
The fact that these packets were blocked by a filter rule means they
didn't match a state entry. Either no state entry has been created, or
it has already timed out and been removed.
Daniel