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
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"