Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Nov 2014 01:51:16 +1100 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Gary Aitken <vagabond@blackfoot.net>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: natd not translating?
Message-ID:  <20141111003306.F31139@sola.nimnet.asn.au>
In-Reply-To: <7fe88aca6228abad2e4ce66abaf42893.squirrel@webmail.blackfoot.net>
References:  <7fe88aca6228abad2e4ce66abaf42893.squirrel@webmail.blackfoot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Sorry Gary, been tied up with $reallife bugs ..

On Thu, 6 Nov 2014 18:03:23 -0700, Gary Aitken wrote:
 > > > On 11/03/14 22:37, Ian Smith wrote:

[.. big chomping throughout ..]

 > Yes, fbsd box is the only way out.
 > Hmmm, I was wondering about bypassing natd for internal only traffic.
 > Then realized it shouldn't be diverted because it stays on the internal
 > interface.  However, I hadn't considered traffic that just went in and
 > back out the gateway.
 > 
 > I have a non-gateway ip addr reserved for use by natd, and currently have
 >   divert 8668 ip from any to any via ep0
 > Since I have a non-gateway addr reserved for the natd xlations,
 > it seems like
 >   divert 8668 ip4 from not me to not me via ep0
 > should have identical behavior; but it doesn't.
 > It seems like nothing came through to clients.

Well, traffic coming back in from remote hosts IS 'to me' (ie, to any 
address configured on any interface on this box) before it's been 
translated by NAT to an inside host address :)

And that IP is presumably the gateway for the inside hosts, so I'm still 
not clear what you mean by non-gateway address .. but never mind.

 > > Are you running any services accessible from outside on any of your IPs?
 > 
 > yes.
 > All served by the fbsd gateway box at the moment,
 > on outward-facing (ep0) interface ip.

Strangely, there's no man page for ep nor if_ep on 8.x or 9.x?

[..]

 > heh.  <Sheepish grin> Due to various problems along the way,
 > I'm pleading the 5th.
 > Waiting for a disk delivery to upgrade to 9.3

Fair enough.  I'm still running my main non-server workhorse on 8.2-R.

 > I've been using tcpdump on the outward facing net and running
 > natd -verbose to see the translations and the complaints,
 > which works pretty well.
 > I guess I was expecting logging to show the rejected packets, not
 > just tell me something was rejected.  I'll lower my expectations :-(

ipfw's logging is consistent and typically limited to 100 or whatever 
else you specify, so if you want to see some more, just 'ipfw resetlog N 
[..]' for the next 100 or so .. otherwise it won't bother you again, but 
you get full details of all translations till then.  Perhaps using 
'diverted' as a selection or skipto option on some rules may be handy.

 > Thanks for your insights and suggestions; only open question at the
 > moment is the
 >   divert 8668 ip4 from not me to not me via ep0
 > one.

That rule will work with packets from inside going out, but as above, 
not the returned packets coming in, which are indeed 'to me'.

It's really best - and certainly easiest to follow - to have separate 
nat-or-divert rules for incoming and outgoing traffic:

Packets coming in from inside are never translated, that only happens to 
these packets on the way out, to outside.  This is likely all you need:

  ipfw add divert [log] natd ip4 from ${inside_net} to any out \
    recv ${inside_if} xmit ${outside_if}

which you'll see doesn't match inside traffic not leaving your net, nor 
traffic generated on this box, but specifically matches the only traffic 
natd would translate anyway.

[ then optionally, for curiousity ]
  ipfw add count [log] ip4 from any to any out recv ${inside_if} diverted
[ and pedantically .. these two counts should add up to the divert rule ]
  ipfw add count [log] ip4 from any to any out recv ${inside_if} not diverted

Packets coming in from outside all need passing to nat/divert to see if 
they match a connection, unless this box also receives packets for other 
IPs, in which case it's also sensible to avoid 'wasting natd's time'.

  ipfw add divert natd [log] ip4 from any to ${alias_address} in \
    recv ${outside_if}

[ then optionally]
  ipfw add count [log] ip4 from any in recv ${outside_if} diverted
[ etc ]

Also specifying 'target_address 255.255.255.255' makes sure packets not 
matching an established nat connection go to alias_address; see natd(8).

There, that's about all I know - all from memory, add salt to taste :)

cheers, Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141111003306.F31139>