Date: Wed, 5 Nov 2014 19:33:25 +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: <20141105181653.H52402@sola.nimnet.asn.au> In-Reply-To: <54596FE0.7020603@blackfoot.net> References: <mailman.73.1415016001.56588.freebsd-questions@freebsd.org> <20141104160325.W52402@sola.nimnet.asn.au> <54596FE0.7020603@blackfoot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Nov 2014 17:31:28 -0700, Gary Aitken wrote:
> Hi Ian,
>
> Thanks for the reply. I've made a little progress since posting that as of
> today, but not there yet. (see below)
>
> This whole exercise has been an example of why it's a help to all be in the
> same room. Especially when you don't have an alternate network connection! :-(
>
> My understanding is now not necessarily broader than it otherwise might be,
> but it is surely harder won and probably burned in a bit better... At my
> stage in life I can only hope it stays there long enough to get me to the
> end...
Hi Gary .. yes I'm quite old enough to know exactly what you mean :)
> On 11/03/14 22:37, Ian Smith wrote:
> > In freebsd-questions Digest, Vol 544, Issue 1, Message: 9
> > On Sun, 2 Nov 2014 17:36:36 -0700 "Gary Aitken" <vagabond@blackfoot.net> wrote:
> ...
> > > I'm trying to set up natd and can't for the life of me figure out
> > > what's wrong with my config.
> > >
> > > natd.conf:
> > >
> > > use_sockets
> > > same_ports
> > > unregistered_only
> > > verbose
> > > alias_address 66.109.141.60
> > >
> > > What I see:
> > > In {default}[ICMP] [ICMP] 192.168.1.2 -> 128.2.42.52 8(0) aliased to
> > > [ICMP] 192.168.1.2 -> 128.2.42.52 8(0)
> > >
> > > Any thoughts on why natd isn't translating 192.168.1.2 to 66.108.141.60?
> ...
> > Not enough information to have any idea how your NAT box is setup.
> >
> > Need to know the inside and outside interface addresses (eg ifconfig);
> > ipfw rules, especially around those invoking natd (divert rule/s) and
> > where these are placed in your ruleset; who/where is 192.168.1.2, is
> > 66.109.141.60 always your assigned public IP address, freebsd version?
>
> Sorry:
>
> world -> ep0 (66.109.141.*) fbsdbox (192.168.1.1) xl0 -> internal
> 66.109.141.60 is one of my assigned ip addrs.
You have a /24? I can hardly afford my /29 these days. Is fbsdbox
where all your addresses are routed to? If so, to paraphrase julian@,
you don't want to waste natd's time handling packets it doesn't care
about, meaning packets that will never be eligible to be mapped to/from
your internal network .. but that's just a refinement, for later.
Are you running any services accessible from outside on any of your IPs?
> I *think* I got the above problem even with ipfw wide open:
> 00005 allow ip from any to any
> 00010 divert 8668 ip from any to any via ep0
Rule 5 allows everything, so no packets will get as far as rule 10.
Swap those and you do indeed have an open firewall, doing only NAT,
though it's important to specify 'ip4' rather than 'ip' or 'all' in the
divert rule .. natd gets quite upset (TSTL) when passed IPv6 traffic.
> I say *think* because I am further along but did not go back and
> verify the cause. My head is a bit damaged and the wall is bloody.
> I believe the problem was a missing entry in /boot/loader.conf
> (ipdivert_load="YES")
> which I found as a result of this note and the references to others in it:
> http://freebsd.1045724.n5.nabble.com/Kernel-Update-IPFW-not-working-td4208637.html
Ah yes. This was fixed sometime before 9.3 on stable/9 in /etc/rc.d/ipfw:
ipfw_prestart()
{
if checkyesno dummynet_enable; then
required_modules="$required_modules dummynet"
fi
if checkyesno natd_enable; then
required_modules="$required_modules ipdivert"
fi
if checkyesno firewall_nat_enable; then
required_modules="$required_modules ipfw_nat"
fi
}
so I guess you're running 8.x or an earlier 9.x? uname -a?
> Anyway, I'm past that problem and most things are working.
> However, still having some trouble working out my ipfw rules but if I can
> see what's happening I think I can figure it out. However...
Please show your ruleset; the output of 'ipfw show' will do nicely.
Personally, for a setup like yours, I would (and did) start with the
/etc/rc.firewall 'simple' ruleset. Apart from needing rules added to
pass ICMP traffic, still not fixed after many years - it's a good basic
firewall for a small network, unlike those still suggested in the IPFW
handbook page .. though there's been some work done there recently too.
> I can't seem to get logging to work. I have the following in natd.conf:
> log_denied
> log_ipfw_denied
> log_facility local0
> and the following in syslog.conf
> !local0
> *.* /var/log/natd.log
> If I run natd with verbose, I occasionally see
> "natd: failed to write packet back: Permission denied"
> errors on the controlling terminal.
> If I run without verbose (detached), I see no entries in /var/log/natd.log.
That failure may relate to use of log_ipfw_denied (default when using
'verbose' anyway) or it could be to do with IPv6 traffic, as above.
You see no log entries at all? I'd try using the default log. I never
found much value in /var/log/alias.log (natd's default log), compared to
adding a few temporary 'count log' rules before and after the divert
rule/s, and/or running tcpdump in two consoles, one inside and one
outside, while verifying various test traffic as working.
So at least temporarily, add 'log' to various rules so you can see
what's being diverted, passed or denied in /var/log/security. Eg, a
'count log ip4 from any to any' both before and after the divert rule
will show you exactly what natd's done to every packet, while testing.
I don't see the advantage in using another facility either, but it's
your box :) Does /var/log/natd.log already exist? If not you'd need to
touch it first. And have 'log yes' in natd.conf as well as those above.
If I were starting again I'd be using ipfw_nat (in-kernel NAT) instead
of natd anyway; natd(8) is still a useful reference, the descriptions in
ipfw(8) are rather terse if you don't already know natd terminology, but
it maps pretty well one-to-one with natd / divert usage, and is faster.
[Which is something else that needs updating in the Handbook page; yes
Warren, I have been working on that a bit lately, since you mentioned
dru@'s updates .. and hope to have something for you fairly soon :]
> Thanks for any insights.
Well let's see your ruleset (offlist if considered sensitive) and full
natd.conf, and related rules from rc.conf (gateway_enable and such);
also ifconfig, less anything sensitive, could provide a clue or two.
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141105181653.H52402>