Date: Thu, 16 Jan 2003 11:39:20 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@FreeBSD.ORG Subject: Re: natd port forwarding acting wierd Message-ID: <20030116113920.GA20544@happy-idiot-talk.infracaninophi> In-Reply-To: <3E267204.4030505@netscape.net> References: <3E267204.4030505@netscape.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 16, 2003 at 01:49:08AM -0700, WillyB wrote:
> I finally got natd and ipforwading set up but have a slight problem I
> don't understand.
>
> The IP forwarding works from the internet, through the cable modem and
> through the freeBSD router I set up for my internal network, to a www
> server on the private lan.
>
> I can't connect to my server however from my local net using the ip of
> the external net.
If you're following the way natd is setup in /etc/rc.firewall, viz
this chunk of code:
case ${firewall_type} in
[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt])
case ${natd_enable} in
[Yy][Ee][Ss])
if [ -n "${natd_interface}" ]; then
${fwcmd} add 50 divert natd all from any to any via ${natd_interface}
fi
;;
esac
esac
notice that the rule to divert packets into natd only selects packets
that traverse the external interface (${natd_interface} in
/etc/rc.conf) of your gateway machine. Packets from your internal
(192.168.0.0/24) network will not pass through that interface even if
they are destined for your nat'ed address, so they won't hit the
divert rule and they won't get nat'ed.
Now, you might think that the obvious answer is just to drop the 'via
${natd_interface}' part of the divert rule, so that all packets
passing across your gateway machine pass through nat'ing.
Unfortunately, this will fail to work --- apart from the fact that it
will probably screw things up by trying to nat packets going via the
loopback interface and all sorts of other unintended consequences,
your original aim of being able to access your internal server as if
you were coming from outside your net still won't work.
What happens is this:
You send a packet to the NAT address on your gateway.
The modified firewall rules pass the packet through the divert socket
to natd, which rewrites the destination address to be that of your
internal server. Nb. the *source* address in the packet is left
untouched.
The packet is then sent across your internal network to your server.
The server deals with it as normal, and generates a response packet
back to the *original sender*, with it's own address as the source.
That happens to be to a machine on the local network, so the response
packet gets delivered straight there. Normally, the response packet
would be to a remote network and the packet would have to pass through
your gateway to get there, thus giving the natd machinery the chance
to process it, and replace the sender address with the nat address.
Now, the original machine is expecting to have a tcp conversation with
a machine using your nat address. Unfortunately the packets it
receives in response appear to come from some machine on your local
net. In order to preserve sanity it ignores those packets and keeps
listening out for the expected response from the place it sent the
packets to. Eventually it all times out and everybody gives up in
disgust.
There are two possible solutions to this problem.
i) Split Horizon. Usually implemented in terms of DNS, but you
can fudge the issue using /etc/hosts on your internal machines if
that's easier for you. All this does is arrange things so that a
lookup for www.mysite.com returns the address of the server on the
internal network when looked up from inside, and the address of
the nat gateway when looked up from outside.
ii) Reverse Proxy. Instead of accessing your internal server via
a NAT gateway, set up a web proxy on your gateway machine. Unlike
a normal web proxy, instead of grabbing web pages from out on the
net for the benefit of your internal systems, the reverse proxy
grabs web pages from your internal machine for the benefit of the
rest of the net. The NAT gateway will rewrite one out of the
sender or recipient addresses of any packets addressed to it,
whereas the proxy will effectively rewrite both the sender and
recipient addresses, solving the problem detailed above.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030116113920.GA20544>