From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 16:21:21 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 605BC16A4CE for ; Fri, 1 Oct 2004 16:21:21 +0000 (GMT) Received: from proxy.nelsonbay.com (proxy.nelsonbay.com [203.222.55.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id A362C43D4C for ; Fri, 1 Oct 2004 16:21:20 +0000 (GMT) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (bell.nelsonbay.com [203.222.55.34]) by proxy.nelsonbay.com (8.12.9/8.12.9) with ESMTP id i91GLHhn041002; Sat, 2 Oct 2004 02:21:18 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: (from root@localhost) by bell.nelsonbay.com (8.12.11/8.12.11) id i91GLHCW072766; Sat, 2 Oct 2004 02:21:17 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from bell.nelsonbay.com (localhost [127.0.0.1]) by bell.nelsonbay.com (8.12.11/8.12.11) with ESMTP id i91GLHg3072720; Sat, 2 Oct 2004 02:21:17 +1000 (EST) (envelope-from leon@nelsonbay.com) Received: from localhost (leon@localhost)i91GLGC4072691; Sat, 2 Oct 2004 02:21:16 +1000 (EST) X-Authentication-Warning: bell.nelsonbay.com: leon owned process doing -bs Date: Sat, 2 Oct 2004 02:21:16 +1000 (EST) From: Leon Garde X-X-Sender: leon@localhost To: miha@ghuug.org Message-ID: <20041001232632.Y93609@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on bell.nelsonbay.com X-scanner: scanned by Inflex 1.0.12.3 cc: freebsd-net@freebsd.org Subject: Re: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 16:21:21 -0000 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