Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Jul 2001 19:49:01 -0300
From:      "Daniel C. Sobral" <dcs@newsguy.com>
To:        mikescott@clara.net
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: natd passes inconsistent addresses to ipfw?
Message-ID:  <3B61EFDD.ABD61EC3@newsguy.com>
References:  <3B61424F.23282.7D8482@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
mikescott@clara.net wrote:
> 
> With the following ipfw config fragment,

Which happens not to include the rule that is denying your packets...

> 
> # 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
> 00100  15    882 divert 8668 ip from any to any via tun0
> 00200   0      0 allow ip from any to any via lo0
> 00300 405 102963 allow ip from any to any via ed0
> 00400   0      0 unreach port log logamount 100 tcp from any to any
> 113 in recv tun0
> 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
> 00800   1    210 allow udp from any 53 to any in recv tun0
> 00900   1     60 allow udp from any to any 53 out xmit tun0
> 01000   1     76 allow udp from any 123 to any 123 via tun0
> 65435   0      0 allow icmp from any to any
> 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
> 
> (Note that dynamic rule shows the external IP address, where I
> would have expected the internal address).  The security log
> contains:
> 
> Jul 25 08:26:00 data /kernel: ipfw: Accounting cleared.
> 
> Jul 25 08:26:39 data /kernel: ipfw: 700 Accept TCP
> 213.104.70.121:1041 195.8.69.73:119 out via tun0
> (   ^^^^   Note the external address, setting up the dynamic rule)

Sure. Packet enters through fxp0 (or whatever you have), packet gets
diverted and natted, packet is then allowed by the keep-state rule.

> Jul 25 08:26:39 data /kernel: ipfw: 600 Deny TCP 195.8.69.73:119
> 192.168.0.2:1041 in via tun0
> (   ^^^^   Note the Internal address, which doesn't match the
> dynamic rule)

Sure. Packet enters through tun0, packet gets diverted and natted,
packet is then denied by the established rule (not having been
recognized by the one with state).

> 
> Jul 25 08:26:39 data /kernel: ipfw: 700 Accept TCP
> 213.104.70.121:1041 195.8.69.73:119 out via tun0
> 
> Jul 25 08:26:39 data /kernel: ipfw: 600 Deny TCP 195.8.69.73:119
> 192.168.0.2:1041 in via tun0
> (and so on...)
> 
> Not surprisingly, the connection then hangs.  Running natd with the
> -v option as well only shows the expected address translations;
> nothing amiss.
> 
> With less robust, non-dynamic rules, everything works fine.  Can
> anyone spot what's going on here please?

It's doing precisely what you told it to. Perhaps if you would move the
check-state before the nat?

-- 
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@the.secret.bsdconspiracy.net

	wow regex humor... I'm a geek

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?3B61EFDD.ABD61EC3>