Cannot ping second IP address on another machine's interface

Question

I have an OpenVPN client connected to an OpenVPN server.

The server has the following routes:

default via 10.109.185.65 dev eth0 proto dhcp src 10.109.185.84 metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
10.109.185.64/27 dev eth0 proto kernel scope link src 10.109.185.84
10.109.185.65 dev eth0 proto dhcp scope link src 10.109.185.84 metric 100

The client has the following address on the tun0 virtual interface created by OpenVPN:

11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
link/none
    inet 10.8.0.3/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::3c55:91d1:e8cf:7c55/64 scope link flags 800
      valid_lft forever preferred_lft forever

From the server, I can ping the client by doing ping 10.8.0.3 and it works fine.

Then I added a second IP address to tun0 on the client by doing ip addr add 10.100.1.2/24 dev tun0. It shows up on the tun0 interface as:

inet 10.100.1.2/24 scope global tun0
   valid_lft forever preferred_lft forever

On the server, I added a route for that subnet by doing ip route add 10.100.1.0/24 dev tun0. It shows up in the route list as:

10.100.1.0/24 dev tun0 scope link

But trying a ping 10.100.1.2 on the server failed.

Then I noticed that both the server and client had the following iptables FORWARD rule:

ACCEPT     all  --  10.8.0.0/24          anywhere

So I added another FORWARD rule for the 10.100.1.0 subnet by doing iptables -A FORWARD -s 10.100.1.0/24 on both the server and client.

But trying a ping 10.100.1.2 on the server still fails.

Is there anything else I need to do in order to be able to ping 10.100.1.2 from the server?

Answer 1

Three things to consider:

1. Routing

The second IP range (10.100.1.0/24) will be directly attached to tun0 interface. Therefore your machine will know how to get to 10.100.1.0/24 network without you injecting any static route statements. Soon after adding the second IP, execute the following command and you will see that the route has been dynamically added to the table.

$ sudo ip route show

2. Point to Point network

When you create a VPN tunnel, you create a point to point network using a virtual network adapter (tun0 in this case) between VPN server and client. Assigning a second or third or more IP addresses to this interface complicates point to point.

3. Solution

Create a new virtual network adapter that you will assign the second IP address of choice. No route statements will be required, unless needed. Also, no further iptables rules will be required. (You must delete static routes that you made earlier, and also delete the additional iptables rule. You don't need any of those to make your stuff work)

From VPN server:

$ lsmod | grep dummy

Above command check if "dummy" network drivers (modules) are loaded in the kernel. If not loaded, check the documentation here

$ sudo ip link add tun99 type dummy
$ sudo ip link set dev tun99 up

Above command will create a new virtual network adapter named tun99

$ sudo ip address change dev tun99 10.100.1.1

Above command will assign an IP address of 10.100.1.1/32 to a newly created network adapter tun99

Since it is a point to point network, no route statements will be required

From VPN client:

$ sudo ip link add tun99 type dummy
$ sudo ip link set dev tun99 up
$ sudo ip address change dev tun99 10.100.1.2

Test for connectivity by sending ping requests from VPN client to VPN server's IP 10.100.1.1

$ ping 10.100.1.1

Answer 2

 iptables -A FORWARD -s 10.100.1.0/24

If this command did not include a -j ACCEPT, all you did was add a traffic counter to measure the number of packets+bytes matching the 10.100.1.0/24 network reaching that point in the ruleset. If you specify a rule with no action, it will just sit there, count the packets matching the rule, and do nothing else.

Also, the -A option appends the new rule to the end of the existing set if rules in the table; the rules are processed in order, and if there was a "deny all" rule as the last rule of the table (which is a commonly recommended practice), no rules after it will have any effect whatsoever. If so, you should have inserted the new rule into a more appropriate location.