Why specific rouing rule is added after VPN connection is setup on Linux?

Question

After VPN connection is setup the following routing rule is added by default:

vpn_server_ip previous_default_gateway

This rule appears useless for me. Why it is added?

Note:

1. VPN connection is not the connection that is used to connect to the Internet.
2. vpn_server_ip does not belong to the virtual network.

Example:

In example I will use '$ route -n' notation. Before VPN connection was setup I had

0.0.0.0 192.168.0.1

Routing table afterward looks like following:

193.196.65.76 192.168.0.1
0.0.0.0 192.168.0.1
147.38.45.1 0.0.0.0 iface ppp0

So I can understand why

147.38.45.1 0.0.0.0 iface ppp0

is added. 147.38.45.1 the IP of a server in VPN. But I do not understand why

193.196.65.76 192.168.0.1

is added, 193.196.65.76 is the IP of dialin server. Maybe it's just a precaution for the case IP of dialin server is in VPN network?!

Answer 1

When explaining this, the interface name is important. I'll create an example and explain here.

This is the routing table before connecting to VPN. We have our primary interface in the 10.0.2.0/24-network, IP address 10.0.2.15, default route -> 10.0.2.2. Everything occurs on eth1.

k@workstation:~$ ip r
10.0.2.0/24 dev eth1  proto kernel  scope link  src 10.0.2.15  metric 1 
default via 10.0.2.2 dev eth1  proto static 

This is the routing table after connecting to VPN. The first entry added is just as your question; The VPN endpoint through our former primary gateway, through eth1. It also adds the local network for the new IP-address I just got. And then it changes the default gateway to be through VPN.

k@workstation:~$ ip r
123.123.123.123 via 10.0.2.2 dev eth1  proto static 
10.8.0.21 dev tun0  proto kernel  scope link  src 10.8.0.22 
10.8.0.1 via 10.8.0.21 dev tun0  proto static 
10.0.2.0/24 dev eth1  proto kernel  scope link  src 10.0.2.15  metric 1 
default via 10.8.0.21 dev tun0  proto static 

The route ensures that the traffic to the VPN-endpoint flows through the physical network interface, and does not attempt to route it through VPN - as that would be impossible since that traffic is tunneled through the physical network.

Even if the primary gateway isn't changed - the VPN software will often do this just in case the VPN endpoint is located on the same subnet as your new IP-address. This is also why you can not talk to the VPN-endpoint on the same IP-address and expect "local connectivity" after the connection is established.

(The example is made using OpenVPN)