Networking – Manually Setting Interface metric priority of Network Adapters not preferring lower metric route on Windows

cisco-vpn-clientnetworkingroutingsplit-tunnelvpn

After Connecting to Cisco VPN AnyConnect, Now I have two network interfaces having set same default routes, but with different metric values. Even after manually changing/raising the metric value of one default route(i.e. imposed by VPN from metric value 2 to 1000) to give preference to my default route(metric value 26), it's still preferring the VPN one(instead of raising the VPN route metric value from 2 to 1000 as you can see in route print output)

Here is my route print output:

route print
===========================================================================
Interface List
 10...90 4c e5 58 9f 09 ......Atheros AR9285 802.11b/g/n WiFi Adapter
 20...00 05 9a 3c 7a 00 ......Cisco AnyConnect Secure Mobility Client Virtual M
                              niport Adapter for Windows
===========================================================================

 IPv4 Route Table
===========================================================================
  Active Routes:
  Network Destination        Netmask          Gateway       Interface  Metric
         0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.2     26
         0.0.0.0          0.0.0.0         10.0.0.1       10.1.105.2   1000
        10.0.0.0        255.0.0.0         On-link        10.1.105.2   1255
      10.1.105.2  255.255.255.255         On-link        10.1.105.2   1255
  10.255.255.255  255.255.255.255         On-link        10.1.105.2   1255
       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
    164.100.28.5  255.255.255.255      192.168.1.1      192.168.1.2     26
 164.100.176.115  255.255.255.255      192.168.1.1      192.168.1.2     26
     192.168.1.0    255.255.255.0         On-link       192.168.1.2    281
     192.168.1.1  255.255.255.255         On-link       192.168.1.2     26
     192.168.1.2  255.255.255.255         On-link       192.168.1.2    281
   192.168.1.255  255.255.255.255         On-link       192.168.1.2    281
       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.2    281
       224.0.0.0        240.0.0.0         On-link        10.1.105.2   1255
 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.2    281
 255.255.255.255  255.255.255.255         On-link        10.1.105.2   1255
===========================================================================
Persistent Routes:
Network Address          Netmask  Gateway Address  Metric
      0.0.0.0          0.0.0.0         10.0.0.1     999
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination      Gateway
23     58 ::/0                     On-link
 1    306 ::1/128                  On-link
23    306 2001:0:9d38:6abd:348b:29cb:f5fe:96fd/128
                                On-link
23    306 fe80::348b:29cb:f5fe:96fd/128
                                On-link
 1    306 ff00::/8                 On-link
23    306 ff00::/8                 On-link
===========================================================================
Persistent Routes:
None

I doubted of this Persistent route entry block which is there in output above as:

Persistent Routes:
    Network Address         Netmask     Gateway Address  Metric
          0.0.0.0          0.0.0.0         10.0.0.1       999

But after issuing the below delete route command as:

route delete 0.0.0.0 mask 0.0.0.0 192.168.1.1

Now Persistent route entry has gone, its displaying as None.

As you see, Even Metric is 26 which is much lower than 1000, it's still following 1000 metric route. What is going on?

Network Destination       Netmask          Gateway       Interface  Metric
         0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.2     26
         0.0.0.0          0.0.0.0         10.0.0.1       10.1.105.2   1000

Even I have done the following:
In my Adapter Settings (Control Panel\Network and Internet\Network Connections) Advanced Settings Changed the order of the connections so that my connection priority is top on the list over Cisco AnyConnect VPN.

Still If i tracert google.com, still my traffic going over VPN.
Where is the concept of preferring lower cost matrix?
can someone explain to me, what is going over here?

If someone wants to say Cisco AnyConnect Client is playing here behind the scene,

Shall I no more believe on my route print output's?
Shall I no more believe on concept of preferring lower metric value over higher ones?

please, I want to have my doubts clear.

Best Answer

This is likely due to the configurations on the Cisco VPN device you are connecting to not allowing split tunneling. When you disconnect from the VPN the traffic likely utilizes your connection. When you connect to the VPN via the Ciscoanyconnect client, it receives directions from the cisco vpn device to not allow split tuneling, i.e. only allow traffic to come to this device via the tunnel and we will route it from here, so any traffic outside of that remote network is routed from and subjected to, the same security as if you were physically sitting at a location within the network. This is just an assumption, I am not familiar with the setup of the VPN device you are connecting to.

Related Solutions

Linux – Routing all traffic over VPN on Ubuntu Linux

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.

Best Answer

Related Solutions

Linux – Routing all traffic over VPN on Ubuntu Linux

Related Question