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.
Best Answer
I have to admit that I do not (yet) fully understand what you are trying to achieve. But I think you want your Ubuntu (and Debian) server to be reachable by an IP you got through OpenVPN (incoming traffic) but send your own (= Ubuntu servers) traffic through the eth0 interface local to your (Ubuntu) server ("spoofing") the VPN-IP. Or along these lines. I am not sure if this is a very good idea (probably depends on why you do it) but I assume there is a reason for it and as you say it does work with Debian. So let's not elaborate on this (although it might still be important later on).
Further I wonder why the line
included in your VPN configuration does not (seem to) lead to an entry in your routing table.
Also I am not sure what the goal/insight of the two traceroutes you show is... You seem to be trying to traceroute to
8.8.8.8through the VPN tunnel. As this is outgoing traffic I do not really understand its relevance to your problem. And I would say (looking at your routing table) that the traffic you generate this way is not (should not be?) going through the tunnel. I see that it looks like this is the case on Debian though... But I don't see why this is the case. Looking at the routing table I would rather assume the traceroute packages you try to send out ontap0are (should be?) "re-routed" toeth0(default route).Now this brings me to the guess I would take for your problem: IP forwarding. Could it be that your Debian box has it enabled while it is disabled on Ubuntu? You can find more information (how to find out if IP forwarding is enabled for example) by visiting the link above (or use your favorite search engine or the Ubuntu manual).
Your being able to reach the SSH daemon on Ubuntu suggests that you are very close :). So it might be crucial to know what you mean by
What are you trying to do (i.e. what service are you trying to connect to) when the Ubuntu machine "is not reachable"? Access its web server? What IP is this service listening on?