Date: Thu, 16 Jan 2003 12:58:15 -0700 From: WillyB <willyb1964n@netscape.net> To: Matthew Seaman <m.seaman@infracaninophile.co.uk> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: natd port forwarding acting wierd Message-ID: <3E270ED7.3090707@netscape.net> References: <3E267204.4030505@netscape.net> <20030116113920.GA20544@happy-idiot-talk.infracaninophi>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your answer and solutions Matthew :)
This is my 4th day of using freeBSD and I'm still very new to it.
I have used RedHat prior to this and when I could not get it to connect
to my ISP via the cable modem I installed freeBSD. ;)
Actually.. I don't fully understand the rc.firewall script, so I made my
own very simple one :)
I will try to implement the reverse proxy solution you wrote about as
this will probably be easiest for me.
Thanks again for your help and very thorough explination. I understand
what's happening now ;)
Re's and Cheers!
WillyB
Matthew Seaman wrote:
> 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
>
--
Your favorite stores, helpful shopping tools and great gift ideas.
Experience the convenience of buying online with Shop@Netscape!
http://shopnow.netscape.com/
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?3E270ED7.3090707>