Date: Sat, 28 Jul 2001 12:19:01 +0100 From: mikescott@clara.net To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: natd passes inconsistent addresses to ipfw? Message-ID: <3B62ADB5.17372.60982A6@localhost> In-Reply-To: <3B61EFDD.ABD61EC3@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Jul 2001, at 19:49, Daniel C. Sobral wrote: > mikescott@clara.net wrote: > > > > With the following ipfw config fragment, > > Which happens not to include the rule that is denying your packets... Untrue -- it's the "deny log tcp from any to any established" in the fragment I gave (# 00600 in the ipfw listing below) > > > > # divert packets through the tunnel interface > > $fwcmd add divert natd all from any to any via tun0 > > ... > > # allow anything I start up (OK) > > # allow connections to continue once made (FAILS!) > > $fwcmd add check-state > > $fwcmd add deny log tcp from any to any established > > $fwcmd add allow log tcp from any to any out via tun0 setup keep- > > state > > > > I get the following typical failures happening > > > > data# ipfw zero > > Accounting cleared. > > > > (Run telnet session) > > > > data# ipfw show ... > > 00500 0 0 check-state > > 00600 8 344 deny log logamount 100 tcp from any to any > > established > > 00700 4 192 allow log logamount 100 tcp from any to any keep- > > state out xmit tun0 setup ... > > 65435 0 0 deny log logamount 100 ip from any to any > > 65535 0 0 deny ip from any to any > > ## Dynamic rules: > > 00700 3 144 (T 5, # 86) ty 0 tcp, 213.104.70.121 1041 <-> > > 195.8.69.73 119 > > ....... > > It's doing precisely what you told it to. Perhaps if you would move the > check-state before the nat? Well, I tried that - moved to to just after the 'flush'. That just hangs totally, presumably because although the packets do match at the check-state, the rules stop being checked as soon as there's a match, so the nat never happens. In fact, *anything* that matches before the nat diversion will stop the latter happening, surely, so the nat *must* be first. I'm worried about the logic of the problem -- it seems to me that there's no way that nat and the dynamic rules can work together correctly, given that both incoming and outgoing packets start at the top and work down the same list of rules. Tthe keep-state and check-state surely have to be on the same side of the nat, because they have to work together *either* on local *or* external addresses, not a mixture. But if they're after the nat (as for all written examples I've seen), then for incoming packets they operate on local addresses, and for outgoing on external addresses, which is not what's wanted. If they're before the nat, we never reach the nat. Am I totally at sea here with my understanding of what's going on? Does anyone on the list have a working example which they could offer, please, and set my mind at rest? -- various incoming sites blocked because of spam: see www.mikescott.clara.net for a list mikescott@clara.net Mike Scott aka mikeascott@ntlworld.com Harlow Essex England To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B62ADB5.17372.60982A6>