13

After having spent now hours troubleshooting, trawling potential solutions on this site and others, and I am resigned to beg the advice of my betters. I am working to route all network traffic on an instance of Ubuntu over a Cisco VPN at a university. Using either the built in network manager or vpnc, I can successfully establish a connection to the VPN, and can successfully route traffic to any university IP over the VPN. However, aside of those specific IP ranges, I cannot seem to conjure any route which will successfully map all network traffic over the VPN.

So far, I've attempted:

route add -net 0.0.0.0 gw homeportal dev tun0
route add -net 0.0.0.0 tun0
route add -net 0.0.0.0 gw 128.122.252.77 dev tun0
route add -net 0.0.0.0 gw 128.122.252.77 dev eth0
iptables -A FORWARD -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

And many other silly, ineffective, things that I cannot remember well enough to transcribe accurately.

In addition, I've tried routing smaller IP ranges, and specific IPs, each to no avail. I'm not really sure what's going wrong, as the extent of the effects I've been able to observe are failures of name resolution, and failures to route traffic over the VPN. What am I doing wrong here?

Edit-

Here is the output of ip route show after starting the VPN connection with VPNC:

default via 192.168.1.254 dev eth0  proto static 
10.0.0.0/8 dev tun0  scope link 
91.230.41.0/24 dev tun0  scope link 
128.122.0.0/16 dev tun0  scope link 
128.122.252.68 via 192.168.1.254 dev eth0  src 192.168.1.32 
128.122.253.46 dev tun0  scope link 
128.122.253.79 dev tun0  scope link 
172.16.0.0/12 dev tun0  scope link 
192.168.0.0/16 dev tun0  scope link 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.32  metric 1 
193.175.54.0/24 dev tun0  scope link 
193.205.158.0/25 dev tun0  scope link 
193.206.104.0/24 dev tun0  scope link 
195.113.94.0/24 dev tun0  scope link 
203.126.200.0/24 dev tun0  scope link 
203.174.165.128/25 dev tun0  scope link 
212.219.93.0/24 dev tun0  scope link 
216.165.0.0/17 dev tun0  scope link

More information-

I've successfully routed arbitrary traffic over this VPN in MS Windows via the Cisco AnyConnect client with default configuration. Here is what the routing table looks like when the AnyConnect client is working (this is a different computer behind the same router at 192.168.1.254).

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.254     192.168.1.13     30
         10.0.0.0        255.0.0.0    192.168.128.1  192.168.128.197      2
      91.230.41.0    255.255.255.0    192.168.128.1  192.168.128.197      2
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      128.122.0.0      255.255.0.0    192.168.128.1  192.168.128.197      2
   128.122.252.68  255.255.255.255    192.168.1.254     192.168.1.13     31
       172.16.0.0      255.240.0.0    192.168.128.1  192.168.128.197      2
      192.168.0.0      255.255.0.0    192.168.128.1  192.168.128.197      2
      192.168.1.0    255.255.255.0         On-link      192.168.1.13    286
     192.168.1.13  255.255.255.255         On-link      192.168.1.13    286
    192.168.1.254  255.255.255.255         On-link      192.168.1.13     31
    192.168.1.255  255.255.255.255         On-link      192.168.1.13    286
     192.168.31.0    255.255.255.0         On-link      192.168.31.1    276
     192.168.31.1  255.255.255.255         On-link      192.168.31.1    276
   192.168.31.255  255.255.255.255         On-link      192.168.31.1    276
    192.168.128.0    255.255.255.0         On-link   192.168.128.197    257
  192.168.128.197  255.255.255.255         On-link   192.168.128.197    257
  192.168.128.255  255.255.255.255         On-link   192.168.128.197    257
    192.168.203.0    255.255.255.0         On-link     192.168.203.1    276
    192.168.203.1  255.255.255.255         On-link     192.168.203.1    276
  192.168.203.255  255.255.255.255         On-link     192.168.203.1    276
     193.175.54.0    255.255.255.0    192.168.128.1  192.168.128.197      2
    193.205.158.0  255.255.255.128    192.168.128.1  192.168.128.197      2
    193.206.104.0    255.255.255.0    192.168.128.1  192.168.128.197      2
     195.113.94.0    255.255.255.0    192.168.128.1  192.168.128.197      2
    203.126.200.0    255.255.255.0    192.168.128.1  192.168.128.197      2
  203.174.165.128  255.255.255.128    192.168.128.1  192.168.128.197      2
     212.219.93.0    255.255.255.0    192.168.128.1  192.168.128.197      2
      216.165.0.0    255.255.128.0    192.168.128.1  192.168.128.197      2
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      192.168.1.13    286
        224.0.0.0        240.0.0.0         On-link     192.168.203.1    276
        224.0.0.0        240.0.0.0         On-link      192.168.31.1    276
        224.0.0.0        240.0.0.0         On-link   192.168.128.197  10000
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      192.168.1.13    286
  255.255.255.255  255.255.255.255         On-link     192.168.203.1    276
  255.255.255.255  255.255.255.255         On-link      192.168.31.1    276
  255.255.255.255  255.255.255.255         On-link   192.168.128.197  10000
===========================================================================
5
  • I imagine that it will be clear that network routing is quite new to me, so I would appreciate a fairly high level of verbosity in answers.
    – deftfyodor
    Commented Aug 10, 2014 at 8:43
  • 1
    It would be helpful if you could state whether you are using any client (anyconnect?), and if you could post your routing table, thank you. Commented Aug 10, 2014 at 9:32
  • Do so using ip route, by the way. Commented Aug 10, 2014 at 9:35
  • 2
    Yes, please do not use obsolete routing commands: use ip route show for the routing table. Obsolete commands hide some of the complexities which are possible and helpful also with VPNs, let alone VLANs,... Commented Aug 10, 2014 at 9:38
  • @grawity, @MariusMatutiae - Sure thing, I've edited the question with the command output. Thanks for mentioning the ip route command, I hadn't run across it before.
    – deftfyodor
    Commented Aug 10, 2014 at 9:45

2 Answers 2

3

Your local network is 192.168.1.0/24, as shown by this line in your routing table:

 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.32  metric 1

Your VPN network is 10.0.0.0/8, as shown by this line:

 10.0.0.0/8 dev tun0  scope link 

Currently, your default router is:

 default via 192.168.1.254 dev eth0  proto static 

which is of course what you do not want, because it belongs to your local LAN: thus all of your stuff is routed through your local gateway, as if the VPN did not exist.

 You do have however, the all-important statement

 128.122.252.68 via 192.168.1.254 dev eth0  src 192.168.1.32  

which is the route to your VPN-provider.

EDIT:

I had not realized that the routing table is simply the one that is obtained from your VPN, without your intervention. This may indicate (indirectly) that your service provider is willing to forward only the traffic explicitly allowed in your table through the interface tun0, and may have taken further steps to block all other traffic, in which case your efforts will be futile.

However, assuming that your provider is willing to forward all of your traffic, what you need to do is the following.

First, you need to find out whether there is a gateway willing to accept your connection on the other side, because we need its IP address. I will give you four methods to do this.

1) With the pc connected to the VPN, try the following command:

   sudo dhclient -v tun0

If everything goes well, you should see a reply containing this line:

 DHCPOFFER of a.b.c.d from x.y.w.z

x.y.w.z is the IP address of the local gateway. You may have to shutdown your VPN after this test, and maybe even to reboot your pc, because we will have just messed up the routing table pretty well.

2) Alternatively, you may try navigating to one of the allowed sites (those that appear in your routing table as going through the tun0 interface), then issuing the command:

  ip neigh show

You should get a list of pcs contacted through the ARP protocol, with MAC and IP address; most likely, you will receive either zero or one reply. If you get a single reply, then that's your router.

3) If you get no such reply, then you may try with

  sudo nmap -sn 10.0.0.0/8

(which is going to be very slow). Your gateway will be one of the pcs listed, most likely the one with address ending in .1 or in .254, if any such exist.

4) Use the tcpdump command:

  sudo tcpdump -n -i tun0

and see the IP addresses spewed out by the command.

If you get no proper reply to this test either, it means someone has really tightened the screws in his network.

But let us be optimistic, and suppose you now have a candidate IP address x.w.y.z for the remote router. You will need to delete the default gateway, (as sudo!):

  ip route del default via 192.168.1.254

an add the new one:

  ip route add default via x.w.y.z 

and try to navigate.

Let me repeat: since your provider has allowed traffic only to a few selected IP addresses through his VPN, it is possible he may have taken extra measures (=firewall) to prevent a smart user to force his generic traffic through his VPN. In this case, there is nothing you can do. But if he did not, the above steps should help you find a solution.

6
  • Thank you for the very elaborate reply, however entering the second half, I experience a bit of a hiccough. the output of ip addr show dev tun0 reads 10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 192.168.128.193/24 brd 192.168.128.255 scope global tun0 valid_lft forever preferred_lft forever, with no peer address to be observed. In addition, the routing table I posted earlier had not been modified by me at all- it was generated entirely by the vpn client.
    – deftfyodor
    Commented Aug 10, 2014 at 18:05
  • @deftfyodor Please see my edit. Commented Aug 11, 2014 at 6:49
  • Using the tcpdump command, I was indeed able to discern the gateway, and route default traffic to it. Unfortunately, it still only works for the specifically provisioned IP ranges. I'm certainly inclined to believe that there is some additional security measure in place- however I have no problem at all routing arbitrary traffic over the same VPN in MS Windows using the AnyConnect client- so there must surely be more to the story.
    – deftfyodor
    Commented Aug 11, 2014 at 19:39
  • @deftfyodor Can you check whether your routing table in Windos is different from that in Linux? Commented Aug 11, 2014 at 19:53
  • It is generally similar, though there are some elements which differ- in particular, 0.0.0.0 is set to route via my network router as the gateway, holding the VPN gateway as the interface. I've edited the question to show the Windows routing table.
    – deftfyodor
    Commented Aug 11, 2014 at 20:02
3

All of your route commands are missing netmasks, so they only match the specific 0.0.0.0 address, not the entire internet. So replace 0.0.0.0 with 0.0.0.0/0 in the first command you tried:

ip route add -net 0.0.0.0/0 gw homeportal dev tun0

There may be one caveat which I'm not sure if your VPN client solves by itself: the tunnel endpoint needs to be excluded from being routed via the VPN, it has to be routed via your eth0 interface. So if adding this default route breaks your VPN, add a specific route for your VPN endpoint:

ip route add <ENDPOINT>/32 dev eth0

1
  • 2
    I think the second one is supposed to be ip route, no? Also, while it's always a good idea to add netmasks, it seems that route assumes /0 when adding 0.0.0.0 Commented Aug 10, 2014 at 10:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .