Date: Thu, 7 Dec 2006 09:03:46 GMT From: Manuel Schiller<mala@hinterbergen.de> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/106438: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) Message-ID: <200612070903.kB793kPV055366@www.freebsd.org> Resent-Message-ID: <200612070910.kB79ACqB021691@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 106438 >Category: kern >Synopsis: ipfilter: keep state does not seem to allow replies in on spar64 (and maybe others) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 07 09:10:07 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Manuel Schiller >Release: RELENG6_1, STABLE (both tested this week) >Organization: >Environment: (sorry, not connected to the net) GENERIC kernel (no tweaks whatsoever), Sun Ultra1 machine (sparc64 platform) >Description: During the process of moving my router/firewall setup to a new machine (the old one died), I saw that ipfilter seems to do something strange to my packets (when I disable it, the problem disappears, but that's not an option for a firewall :) My ipf.rules has the following lines for the outgoing network interface (I stripped things down to make sure I understand what's happening): pass out quick on hme3 proto tcp from 192.168.x.x to any port = domain flags S keep state pass out quick on hme3 proto udp from 192.168.x.x to any port = domain keep state block out quick on hme3 block in quick on hme3 On the old machine (a pentium box) running FreeBSD 5.5, this would allow out DNS queries, e.g. dig @192.168.x.y www.freebsd.org would work as expected. Now, I can use tcpdump -ni hme3 to look at the packets going out, and I can see the replies coming back, but the replies get blocked by the block rule for the inbound section. Strangely enough, ipfstat -t lists the udp connection, so I assume that the kernel intends to let the replies pass, but somehow it does not seem to do so. I tested things by cvsupping to RELENG6_1 and later STABLE during this week, recompiled things using rm -fr /usr/obj/* cd /usr/src make buildworld make buildkernel make installkernel mergemaster -p make installworld mergemaster CFLAGS have been "-O", I have removed the "-pipe" for some reason I forgot. The machine has been used elsewhere in the past, and it always ran rock solid for weeks under full load compiling stuff without ever crashing. Any hints, ideas or things to test would be greatly appreciated. I intend to look into the kernel sources next weekend (I suspect it's some kind of bug that does not trigger on the more common platforms because I suspect strongly that someone would have noticed it already and I didn't find any hint of that in the mailing lists, problem reports and google), but I'm not too confident when it comes to spotting what's going wrong there. If I missed something obvious, I'd appreciate a pointer. (And I'd be very sorry for the inconvenience.) Manuel P.S. I'm sorry that I couldn't offer you a PR done with send-pr on the offending machine, but it's not in a state fit to send e-mails at the moment, so I have to do this from work... >How-To-Repeat: ipf -Fa -f /etc/ipf.rules (with appropriate rule file) dig @(some-name-server reachable without ipf) www.somesite.whatever >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612070903.kB793kPV055366>