I have an OpenVPN client running on a server of mine obtaining a public IP on a remote network in a different country. The client configuration is as follows:
dev tap
remote a.b.30.7
float a.b.30.7
port 5167
ifconfig a.b.28.178 255.255.255.128
route-gateway a.b.28.129
#redirect-gateway def1
secret woot.key
cipher AES-128-CBC
dhcp-option DNS a.b.8.8
redirect-gateway is commented so that my server (running openvpn client) isn't "taken over" by the VPN connection. I can bind services to the tap0 interface (ie httpd, etc) and run a website off of this IP in another country. The ISP that the server the openVPN client is running on is on does not have egress filtering in place, so traffic for the VPN can just go out the default gateway of eth0 with the public IP in another country. Only inbound traffic is routed through the VPN (ie incoming httpd requests), but outbound traffic goes out eth0 spoofed with the VPN public IP. Without ANY mucking around with routes or iptables, this simply works with no issues.. on a DEBIAN server. The obvious benefit being I have the speed and routing of my regular eth0 interface, but with an IP in a different country.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.y.150.64 0.0.0.0 255.255.255.224 U 0 0 0 eth0
a.b.28.128 0.0.0.0 255.255.255.128 U 0 0 0 tap0
0.0.0.0 x.y.150.65 0.0.0.0 UG 0 0 0 eth0
x.y being the actual server's network and a.b being the remote openvpn network.
The problem? The EXACT same thing DOES NOT WORK in Ubuntu and I cannot figure out why. I have done this on countless Debian servers without issue and absolutely no custom routes or any type of iptables rules. Neither server run a firewall. I believe this is a very basic issue, or Ubuntu has some kind of weird thing going on. It's worth noting that the VPN does work on the Ubuntu servers if I uncomment redirect-gateway (as it should), except this is not what I want. I still need to access the server from it's main interface, eth0.
Debian server trace (WORKING):
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
1 blah (a.b.29.1) 39.161 ms 39.140 ms 39.332 ms
2 asdf (a.b.30.1) 40.870 ms 40.879 ms 40.850 ms
3 sth-sbb2-ank35-1-ge26-100.dcs.net (217.78.35.5) 40.816 ms 40.818 ms 40.783 ms
4 google-gw.dcs.net (217.78.35.14) 40.780 ms 40.601 ms 40.565 ms
etc. fine here.
Ubuntu server trace (NOT WORKING):
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
borked.
8.8.8.8 being googles public DNS.
The VPN IP is not accessible from the outside world. Interestingly, if I were to:
ssh -b [debian.server.openvpn.client.IP] user@[ubuntu.server.openvpn.client.IP]
I am able to connect/ping/see it. This is with two seperate VPN clients running on both the Debian and Ubuntu box, on the same a.b network as in the route table (different IP's on the remote network). The debian server VPN client IP is publically accessible, but on the Ubuntu server it's not! Only from within a.b!
The goal is to spoof traffic out eth0 instead of sending it back over the VPN and wasting VPN bandwidth. Also, the same VPN configuration will work on a debian server without problem. I can put the config for the VPN that's on the Ubuntu box onto the Debian box and it's fine.
Debian server runs Debian 5 64bit with 2.6.32-bpo.5-xen-amd64
Ubuntu server runs Ubuntu 10.04.1 LTS with 2.6.32-24-server
I thought this may be an issue with kernel modules and tun.ko, as I didn't see it with modprobe -l on the Ubuntu server but DID on the debian server. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565856 if interested. I tried the workarounds to no avail. I think it's something else.
Any help is greatly appreciated! I apologize for lack of proper networking terms where necessary, I only have intermediate networking knowledge and since this has worked for me with ease in debian have not had to do anything special.
