Date: Tue, 19 Nov 2002 10:42:59 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Shawn Barnhart <swb@grasslake.net> Cc: ipfw@FreeBSD.ORG Subject: Re: Stateful rules Message-ID: <20021119104259.B68560@xorpc.icir.org> In-Reply-To: <003701c28ff1$2bd513b0$62229fc0@ad.campbellmithun.com>; from swb@grasslake.net on Tue, Nov 19, 2002 at 11:29:10AM -0600 References: <001a01c28fea$0200c7c0$62229fc0@ad.campbellmithun.com> <20021119085612.A67523@xorpc.icir.org> <003701c28ff1$2bd513b0$62229fc0@ad.campbellmithun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
just what to you want to achieve with stateful rules, given that you have already natd ? you are trying to write a configuration that is totally non-trivial because the firewall code will see the packet multiple times, with both the original and the nat'ed address. And finally you are forgetting the 'setup' option from the tcp keep-state rules, which does not make a difference with legitimate traffic, but leaves the firewall open to traffic that you don't want. Re. the deny rule, it might well be that the packets you see matching it are retransmission of the FIN packets from the server, which arrive once the dynamic rule has already expired and so do not match rules 400, 500 and 510 cheers luigi On Tue, Nov 19, 2002 at 11:29:10AM -0600, Shawn Barnhart wrote: > > ----- Original Message ----- > From: "Luigi Rizzo" <rizzo@icir.org> > To: "Shawn Barnhart" <swb@grasslake.net> > Cc: <ipfw@FreeBSD.ORG> > Sent: Tuesday, November 19, 2002 10:56 > Subject: Re: Stateful rules > > > > those rules do not make a lot of sense. > > perhaps you should post your entire ruleset if you want us > > to understand what is going on. > > ----- Original Message ----- > From: "Luigi Rizzo" <rizzo@icir.org> > > > > those rules do not make a lot of sense. > > perhaps you should post your entire ruleset if you want us > > to understand what is going on. > > > > No more confusing than: > > ipfw add check-state > ipfw add allow tcp from my-subnet to any setup > ipfw add deny tcp from any to any > > ...which is a direct cut/paste from the ipfw man page. > > The full ruleset on this specific machine isn't much more complicated: > > 00050 divert 8668 ip from any to any via xl0 > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 check-state > 00500 allow tcp from 10.11.12.16/29 to any keep-state > 00510 allow tcp from 192.168.1.0/24 to any keep-state via xl1 > 00600 allow udp from 10.11.12.16/29 to any keep-state > 00610 allow udp from 192.168.1.0/24 to any keep-state via xl1 > 02000 allow log icmp from any to any > 03010 allow tcp from any to 10.11.12.20 80 > 03020 allow tcp from any to 10.11.12.20 25 > 03030 allow udp from any to 10.11.12.20 53 > 64000 deny log ip from any to any > > When web browsing, some return packets hit the deny rule at the end, but > with no apparent impact on the web client, even though they should have > matching dynamic rules, because they're passed out initially with a > keep-state rule. UDP applications (DNS, games) don't ever generate > apparently failed or missing dynamic rules, even though the games generate a > huge amount of udp traffic. > > I'm speculating that the packets are return web data because they appeared > during active web browsing, had a source port of 80 and a high-numbered > destination port. > > This particular machine has NAT enabled, but I've seen similar results on a > machine with no NAT enabled. > > I suspected I might have been overrunning the net.inet.fw.dyn_max values, > but monitoring showed I wasn't. I was also curious about the role played by > net.inet.fw.dyn_buckets relative to dyn_max since the manpage isn't clear to > me about this. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021119104259.B68560>