0

I am running ubuntu 12.04 and only want the vpn for specific applications that can bind to vpn port(address). If I connect to the VPN with all the traffic routed through the VPN port everything works fine (as second route below shows). If I check option "Use this connection only for resources on its network", the route looks like I would expect it, and other programs can reach the internet, but I cannot connect to a remote server binded to the vpn port, such as "telnet google.com 80 -b 10.187.1.9" It seems that I can get packets out, but maybe not in. Anyone know what is wrong with the route?

With "Use this connection only for resources on its network" set: (Can't connect to remote server just using tun0 (10.187.1.9)

0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth2
10.187.1.1      10.187.1.9      255.255.255.255 UGH   0      0        0 tun0
10.187.1.9      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
130.185.155.58  192.168.1.1     255.255.255.255 UGH   0      0        0 eth2
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth2
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth2

Default Option: (I can connect to remote server using tun0, but all traffic is being routed through tun0)

0.0.0.0         10.187.1.9      0.0.0.0         UG    0      0        0 tun0
10.187.1.1      10.187.1.9      255.255.255.255 UGH   0      0        0 tun0
10.187.1.9      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth2
185.3.135.58    192.168.1.1     255.255.255.255 UGH   0      0        0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth2
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth2
CptanPanic
  • 101
  • 2

2 Answers2

1

I don't think the -b option does what you think it does.

If you do a tcpdump you will see that the telnet connection will go out the default gateway, but have a source IP address of 10.187.1.9. The issue becomes that even though your source IP address has changed - your routes are all destination based; you will always go out the default gateway in your current configuration.

So to resolve this there are two solutions.

  1. Use your VPN for all connections - i.e. make your VPN your default gateway.
  2. Implement source routing - or a policy route. This will create a route based on the source IP address of your packet.

Method 1, is simple - you have done it already in fact.

Method 2, a basic way of doing this looks like the following:

ip rule add from <source>/<mask> table <name>
ip route add default via <VPN GW> dev tun0 table <name>

OR

ip route add default dev tun0 table <name>

Where <name> will be something in /etc/iproute2/rt_tables (you can create a name) or you can use a number.

Sources:

http://www.saeedpazoki.com/how-to-implement-source-routing-with-linux/

https://superuser.com/a/377039/161569

Community
  • 1
prateek61
  • 373
  • 2
  • 7
0

OpenVPN uses an entre subnet to accommodate its virtual interfaces at the server side as well as the connecting clients. In your case, this subnet seems to be configured as 10.187.1.0/24. OpenVPN is assigning 10.187.1.1 for the server side and it is splitting the rest of the subnet up in smaller subnets for each client connection. By default it will use /30 with 2 usable addresses, one network address and one broadcast address for compatibility reasons and assign the first of the usable addresses to the server and the second to the connecting client. In your example this would be 10.187.1.9 (server) and presumably 10.187.1.10 (client).

So, your first problem is running telnet google.com 80 -b 10.187.1.9 - you are instructing telnet to bind to a non-local address, which would not work. The second problem is that Linux is doing routing decisions by evaluating the destination address only by default. As google.com is resolving to something not local to your network and not covered by any other route, the packet is relayed through the default route, which would be 192.168.1.1 in your case and which probably knows nothing about the 10.187.1.0/24 subnet, so it effectively drops the packet. If you need this traffic to take the route through tun0, you should tell Linux explicitly:

echo "200   vpn" >> /etc/iproute2/rt_tables
ip rule add from 10.187.1.0/24 table vpn
ip route add table vpn default dev tun0

This will create an additional routing table registration with the name vpn, add a rule to use this routing table if a packet is originating from the 10.187.1.0/24 subnet and add a default route through tun0 (which is a point-to-point interface, so the route specification does not need a gateway address) for all traffic routed through the vpn table.

the-wabbit
  • 40,737
  • 13
  • 111
  • 174