Date: Sun, 15 Jul 2001 00:47:44 -0700 (PDT) From: Mike Hoskins <mike@adept.org> To: Brian McDonald <brianmcd@columbus.rr.com> Cc: freebsd-stable@freebsd.org Subject: RE: $diety, I hate natd. (SOLUTION) Message-ID: <Pine.BSF.4.21.0107150024420.24130-100000@snafu.adept.org> In-Reply-To: <NDBBJIBLKNMEAOCBGPMDGEEKEIAA.brianmcd@columbus.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ I'm reposting this to the list for archival purposes. It was initially
a private message, but I don't think any harm will be done by CC'ing the
list with my response. As expected, it was a trivial oversight on
my part. Thanks to everyone that offered help. ]
On Fri, 13 Jul 2001, Brian McDonald wrote:
> You have IPDIVERT in your kernel?
> You have IPFORWARD in?
IPDIVERT and IPFIREWALL_FORWARD...
> Conceptually, IPFW/natd interaction isn't super clear from the man page, but
> I've found it pretty predictable once you get it. For starters - the
> default natd rule really should divert ALL packets. I've done bypass rules
> before, for performance reasons, but the ipfw rule for nat should be "divert
> <divert port> ip from any to any via <external interface>"
This is what I'm doing now. When I run natd verbosely, I see the packets
hit the outbound interface/port, and get translated to the internal
IP/port... but the packets disappear at this point. Tcpdump on the
internal interface at this time shows no traffic passed... so there must
be something up with my fw rules...
> Secondly - pay attention to when the NAT takes place, and try to figure how
> your firewall rules will react to that. NATD changes the packet in place,
> so if you are 'inbound external' then after NATD changes the IP addresses,
> it's going to be processed by the remaining rules as in via <external
> interface>. For example, if you have private net filters, make sure they
> are applied BEFORE the NATD rule, otherwise, a rule such as "deny ip from
> any to 192.168.0.0/16 via <external interface>" will trash the inbound
> packet. After the NATD rule happens, all rules should reference your
> internal network as if it were routable.
I'm going to stare at my rulechain a bit more... :)
>
> The rc.firewall script is a good reference for basic rule structures, and
> I'd be happy to help out if you can send me the rules, or at least a
> reasonable simulation thereof :)
Right now, tcpdump ran on the backend interface is showing Syn's but no
Acks. ...
Ok, duh. Just got it. Added,
allow tcp from any to ${iip}:80 in via fxp0
thanks to your suggestion above. Before when I ran tcpdump I just saw
one-way Syns. When I added your suggested rule, I got Syns both
ways... from there it was just a matter of adding 'keep-state' so the
appropriate dynamic rules get generated... and now TCP traffic is flowing
from ${oip}:8080 to ${iip}:80 as I'm writing this.
Thanks for your help,
-Mike
--
Eat drink and be merry, for tomorrow they may make it illegal.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107150024420.24130-100000>