Date: Fri, 15 Dec 2006 16:42:35 -0600 From: Lane <lane@joeandlane.com> To: freebsd-questions@freebsd.org Subject: Route spagetti Message-ID: <200612151642.35712.lane@joeandlane.com>
next in thread | raw e-mail | index | archive | help
Hello, I have a routing problem ... I think. I have an established OpenVPN hosted on FreeBSD 6.1 using tun0 configured for 10.11.13.x. The OpenVPN configuration currently uses the "client-to-client" directive so that vpn Windows clients could access a separate central proprietary (Windows) database (also on the vpn). Response time and security have prompted me to investigate the use of qemu, hosted on FreeBSD, to house the proprietary database. I configured the qemu Windows image on my development machine and configured it to use tap0 10.11.12.150->10.11.12.151. The Windows side of the interface is 10.11.12.151 and FreeBSD keeps 10.11.12.150. I have used netmask 255.255.255.0 and 255.255.255.252 with no discernible change in behaviour (which I'm getting to). Everything worked correctly in development - I could establish a Terminal Services session with the Windows client and do whatever I needed to do, including access the internet from the qemu-hosted session. However when I pushed the image out to the vpn server, I found something odd: When logged into the remote qemu-hosted Windows session via Terminal services, I can ping any interface on the vpn host (10.11.12.150, 10.11.13.1, and defaultrouter). I can also ping any client connected to the vpn tun device (10.11.13.X). However I cannot route from the Windows session to the public internet. Typically there is a tight firewall in place on the vpn host, but I have disabled the firewall rules and stil been unable to access the public internet from within the qemu-hosted session, while I *am* able to access the internet from a shell on the vpn host. Is this necessarily a job for natd? Or is there some simpler way to get 10.11.12.150 to forward 10.11.13.x packets to tun0 and all others to the defaultrouter on the host machine? I'm looking at "ipfw add forward ..." but it does not look promising. Thanks for your time. I know I can be long-winded. lane
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612151642.35712.lane>