Date: Sat, 2 Oct 2004 02:21:16 +1000 (EST) From: Leon Garde <leon@nelsonbay.com> To: miha@ghuug.org Cc: freebsd-net@freebsd.org Subject: Re: confusion with natd Message-ID: <20041001232632.Y93609@localhost>
next in thread | raw e-mail | index | archive | help
Confusion 1. nat replaces routing. Mikail says he cant get routing to work, so he is using nat. Seems to me that to get nat going, he needs to fix the routing. Confusion 2. The sentiment "routing is hard" is wrong. Routing is easy. routes specify where to send a packet based on where it is going. confusion 3. Routing by source is not easy. routing by source is a subfunction of policy routing, an overview here,... http://www.bsdnews.org/01/policy_routing.php The other way to route by source is to use a rule like this 'ipfw add 1 fwd 192.168.10.2 from 192.168.0.3 to any ' What this does is set the default route for packets from 192.168.0.3 to go via the tunnel, which cures the problem. No further firewall rules apply, its on its way down tun0! to make use of this, turn off the nat on host A's tunnel. On host b, you need a route back to 192.168.0 via the tunnel in rc.conf put ... static_routes="192.168.0" route_192.168="-net 192.168.0/24 192.168.10.1" .... which means the 192.168.0/24 network is reached by 192.68.10.1 That allows the return packets from host b's nat. Another way to solve the problem is to VPN 192.168.0.3 to host B instead of /as well as Host A to host B. I think the problem with mikail's rules is that the vpn packets upon return appear at 10 and so bypass tun0's divert in recv tun0. So move rule 6 to rule 16, and the packets then appear after rule 10, hit rule 16 and get de-nat'ed, and so work as normal. I might be wrong there, but I think the vpn traffic is natd'd by rl1's NATD, so is avoiding tun0's natd... the order of the rules would appear to be important. (or would the ipfw table have to be looked through more than once for each packet? ie by sysctl setting the one_pass variable ? ) ------------------------ Leon Garde leon@nelsonbay.com Ph 02 4984 1422
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041001232632.Y93609>