Route spagetti

[Lane]

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