How to send out some traffic via my vpn connection

Question

I had a working setup where I could access all my work resources which are accessed via VPN going via my server previously however at some point recently this stopped working for no obvious reason.

desktop - server - (vpn) - work

Currently I have the following routing tables:

Desktop:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.100 0.0.0.0 UG 2 0 0 eth0
10.2.1.0 192.168.1.10 255.255.255.0 UG 2 0 0 eth0
10.103.1.0 192.168.1.10 255.255.255.0 UG 2 0 0 eth0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Server:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.100 0.0.0.0 UG 2 0 0 eth0
10.2.1.0 192.168.213.85 255.255.255.0 UG 0 0 0 tun0
...
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.213.0 192.168.213.85 255.255.255.0 UG 0 0 0 tun0
192.168.213.85 0.0.0.0 255.255.255.255 UH 0 0 0 tun0

I forgot the IP's of the boxes:

Server:

eth0: flags=4163 mtu 1500
 inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
 inet6 fe80::4a5b:39ff:fed9:821b prefixlen 64 scopeid 0x20
 ether 48:5b:39:d9:82:1b txqueuelen 1000 (Ethernet)
 RX packets 189718543 bytes 130295498473 (121.3 GiB)
tun0: flags=4305 mtu 1500
 inet 192.168.213.86 netmask 255.255.255.255 destination 192.168.213.85
 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)

Desktop:

eth0: flags=4163 mtu 1500
 inet 192.168.1.12 netmask 255.255.255.0 broadcast 192.168.2.255

Work:

10.2.1.134

Current IPTables rules:

# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*nat
:PREROUTING ACCEPT [1499:134874]
:INPUT ACCEPT [1499:134874]
:OUTPUT ACCEPT [1088:107916]
:POSTROUTING ACCEPT [1088:107916]
COMMIT
# Completed on Mon Mar 11 15:46:11 2013
# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*mangle
:PREROUTING ACCEPT [1680356:728348964]
:INPUT ACCEPT [1680356:728348964]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1399840:350789030]
:POSTROUTING ACCEPT [1400230:350882435]
COMMIT
# Completed on Mon Mar 11 15:46:11 2013
# Generated by iptables-save v1.4.16.3 on Mon Mar 11 15:46:11 2013
*filter
:INPUT ACCEPT [363:36065]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1399845:350789898]
:fail2ban-Apache - [0:0]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-Apache
-A INPUT -p tcp -m tcp --dport 1985 -j fail2ban-SSH
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 60151:60161 -j ACCEPT
-A INPUT -p udp -m udp --dport 6889 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A fail2ban-Apache -j RETURN
-A fail2ban-SSH -j RETURN
COMMIT
# Completed on Mon Mar 11 15:46:11 2013

As you can see, I've added the routing rules to the desktop to allow it to push traffic over to the server for the specified network. Work is on 10.2.1.0/24 (Ignore the others, they are just extra parts of non-important networks right now).

I think I may of had an iptables rule previously which was doing something to the traffic however I lost it during a power cut (doh!) and now can't figure out what I did previously to get it working.

• BatchyX: route and ifconfig are deprecated on linux, use ip route and ip addr instead. ip route show more info than route, including items (e.g. preferred source address) that can make the difference between a working network and a broken network, and also provides ip route get, which is very handy for debugging routing problems

Answer 1

I think there is an error in the routing table of the server.

The tunnel interface (vpn connection) is listed as 192.168.213.86 with the remote point being 192.168.213.85. Yet in the routing table you have

192.168.213.0 192.168.213.85 255.255.255.0 UG 0 0 0 tun0
192.168.213.85 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
0.0.0.0 192.168.1.100 0.0.0.0 UG 2 0 0 eth0

The problem is reaching 192.168.213.85 via 192.168.1.100. You need to remove the middle table entry. And rather route to the remote end via the local tun interface. If memory serves right, the correct syntax should be:

route del -host 192.168.213.85 gw 0.0.0.0 
route add -host 129.168.213.85 gw 192.168.213.86

• djsmiley2kStaysInside: As far as I understand it, the second line is showing that 192.168.213.85 is directly connected, via tun0, and there is no gateway to connect to that host (hense the H). Also, this routing table is on the server. The connection on the server works. It's the connection from my desktop which fails (the one with only routes to 10.2.1.0/24 and 10.103.1.0/24.

Answer 2

In the end I rebooted and it works again.

Seems to be some strange bug related to the fact we had a powercut or I resumed from hibernation. Either way, all the details including routing tables and IPTables are indentical from before and after the reboot.

Annoying, but alas, it's fixed.

• John Mee: Trying turning it off and back on again: youtube.com/watch?v=nn2FB1P_Mn8