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>