Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
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 –  BatchyX Mar 16 '13 at 20:02
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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
share|improve this answer
    
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. –  djsmiley2k Mar 15 '13 at 20:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.