On Tue, Jan 17, 2006 at 08:21:52PM +0000, Johan Linner wrote:
> Hi!
>
> We are running a pretty nice commercial firewall which obviously is
> based on a stripped version of OpenBSD and pf ;) (yes I know... we are
> planning on switching to our own OpenBSD installation as soon as
> possibly, still in the learning process though).
>
> Anyway we get alot of warnings about connections to a valid www server
> on the dmz like this:
> Jan 17 19:41:01 Denied incoming WAN 83.248.186.3 1162
> 192.168.78.6 80 TCP flags F, seq 0, size 0 ack 1 win 65535, no
> frags
>
> and this:
>
> Jan 17 19:39:26 Denied incoming WAN 85.112.166.15 11406
> 192.168.78.6 80 TCP flags R, seq 1305210837, size 0 ack
> 2803852444 win 0
Okay, these seem to be either scans or valid connections that were too
late in closing - the first is a FIN packet, the second a RST packet.
In either case, if there aren't too many, ignore them - zombies and
misconfigured hosts litter the internet. If it happens too often, you
may want to observe for a while with tcpdump, and try to discover if the
issue is indeed valid connections timing out. If so, increase the
timeout values in sysctl (I wouldn't know which off the top of my head,
but it should be in the man page).
The firewall might also be overloaded, in which case increasing the
timeouts is likely to make it worse.
In any case, though, dropping RST and FIN packets will, at worst, cause
the hosts behind the firewall to keep sockets open for too long - which
can be a performance hit, but will not cause lost connections or
somesuch.
> With some detetctive work I think the firewall has the following pf.conf
> settings for allowing traffic to the www server (fake public ip address):
>
> binat on $EXTIF inet from 192.168.78.6 to any -> 20.1.1.1
> pass in quick on $EXTIF inet proto tcp from any to 192.178.78.6 port www
> flags S/SA modulate state
>
> I think scrub are used on the ext inferface
>
> So now to my question: is the above denied connections correct or should
> they be allowed to the www server, eg. using S/SAFR in the pass rule?
They are probably correct. Due to 'keep state' (ok, 'modulate state' -
but that's simply 'keep state' with some added features), traffic
belonging to the original connection is automatically allowed. This
should include the above FIN and RST packets.
BTW, S/SAFR will allow packets that have SYN set, but not ACK, FIN or
RST. This does not do what you think it does, I suppose.
Joachim
