From owner-freebsd-net@FreeBSD.ORG Fri Oct 1 05:43:47 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 DDD4316A4CF for ; Fri, 1 Oct 2004 05:43:46 +0000 (GMT) Received: from beer.ux6.net (beer.ux6.net [64.62.253.29]) by mx1.FreeBSD.org (Postfix) with SMTP id 99F9043D48 for ; Fri, 1 Oct 2004 05:43:46 +0000 (GMT) (envelope-from miha@ghuug.org) Received: (qmail 94253 invoked by uid 113); 30 Sep 2004 22:43:46 -0700 Received: from 205.177.65.128 by beer.ux6.net (envelope-from , uid 112) with qmail-scanner-1.23 (clamdscan: 0.70. spamassassin: 2.64. Clear:RC:0(205.177.65.128):SA:0(4.7/6.0):. Processed in 1.59693 secs); 01 Oct 2004 05:43:46 -0000 X-Spam-Status: No, hits=4.7 required=6.0 X-Spam-Level: ++++ Received: from unknown (HELO ?192.168.0.3?) (miha@beer.ux6.net@205.177.65.128) by localhost with SMTP; 30 Sep 2004 22:43:44 -0700 From: "Mikhail P." Organization: Ghana Unix Users Group To: freebsd-net@freebsd.org Date: Fri, 1 Oct 2004 05:43:42 +0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410010543.42789.miha@ghuug.org> cc: freebsd-isp@freebsd.org Subject: confusion with natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: miha@ghuug.org 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 05:43:47 -0000 Hello FreeBSD Users, I have been playing with OpenVPN for a while, and have successfully configured pretty simple tunnel between local router (FreeBSD, which NATs LAN into inet) and remote host. Now my next target is to route some of the computers in the LAN into above VPN tunnel - that's where I'm stuck. Here's my detailed setup (should be pretty basic and regular): HOST_A: FreeBSD, serves as gateway (NAT) for LAN (192.168.0.0/24) has two NICs: rl0 - internal (192.168.0.1) rl1 - external (connected to DSL modem), runs natd (natd -n rl1) net.inet.ip.forwarding=1 openvpn from ports HOST_B: FreeBSD, remote host, single NIC, public IP. net.inet.ip.forwarding=1 openvpn from ports What has been done so far - I have configured OpenVPN between HOST_A and HOST_B. As in tunnel, HOST_A has ip of 192.168.10.1 and HOST_B has 192.168.10.2, so basically there is P-t-P link over tun0 on each side. I should probably note that HOST_B has no public ip, as it sees inet via DSL modem (which is also most likely NAT'ed by ISP). All is great, and both parties can ping each other via tun0 iface. Now, as noted above, I want to route some of computers in 192.168.0.0/24 into this tunnel, so basically they go internet via HOST_B as the end point. My attempts to play with route never ended well, so I thought of natd on tun0 on HOST_B. I ran into small problem where I can't run more than one instance of natd, but it has been quickly solved by searching google database, so I ended up running natd on tun0 of HOST_B as: natd -interface rl1 natd -port 8568 -interface tun0 As mentioned above, there is already natd on rl1, and thus I have the following rules (the only rules in ipfw) in ipfw: 10 divert 8668 ip from 192.168.0.0/24 to any out xmit rl1 12 divert 8668 ip from any to 192.168.254.1 in recv rl1 (192.168.254.1 is the IP given by DSL modem via DHCP) Next (well, they are actually before these rules) two rules I added into ipfw ipfw add 4 divert 8568 ip from 192.168.0.3 to any out xmit tun0 ipfw add 6 divert 8568 ip from any to any in recv tun0 So basically, this supposed to give me the following picture: 192.168.0.3 travels to "any" via tun0. That picture, however, does not work in real life, and that's why I'm posting here for advise of more experienced users. I can ping "192.168.10.1" (which is HOST_A, remote host) from 192.168.0.3, and packets travel via tun0 with src/dst addresses overwritten by natd. However, if I try to ping any other host on the internet from 192.168.0.3, packets travel via natd on rl1 (I found that using tcpdump), and not via tun0 - that's my major confusion right now. There are no blocking ipfw rules - the only 4 rules sitting in ipfw are those divert rules. I have been pulling hair off my poor head for few hours on this issue, but did not come to solution, so I'm looking for advises. kind regards, M.