Cannot ping second IP address on another machine's virtual interface

sllinux · 08-22-2020, 04:51 AM

I have an OpenVPN client connected to an OpenVPN server.

The server has the following routes:

Code:

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:

Code:

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:

Code:

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:

Code:

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:

Code:

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?

ferrari · 08-22-2020, 05:26 AM

I'm not quite sure why you're adding secondary IP addresses to the tun0 interface. However, I can explain that when wanting to reach subnets behind a given OpenVPN client, the 'iroute' directive is needed (as well as a route on the server)....

https://community.openvpn.net/openvpn/wiki/RoutedLans?
https://openvpn.net/community-resour...server-subnet/

Apologies if I'm on the wrong track here. I don't quite get your question.

sllinux · 08-25-2020, 02:04 AM

Quote:

Originally Posted by ferrari

I'm not quite sure why you're adding secondary IP addresses to the tun0 interface. However, I can explain that when wanting to reach subnets behind a given OpenVPN client, the 'iroute' directive is needed (as well as a route on the server)....

https://community.openvpn.net/openvpn/wiki/RoutedLans?
https://openvpn.net/community-resour...server-subnet/

Apologies if I'm on the wrong track here. I don't quite get your question.

The reason I added a secondary IP address to tun0 is because there is a device connected to the client, and we want to access the device through the secondary IP address, not the 10.0.8.3 address.

I tried adding the following lines to server.conf:

Code:

route 10.100.1.0 255.255.255.0
push "route 10.100.1.0 255.255.255.0"
client-to-client
client-config-dir /etc/openvpn/server/ccd

I also added the following to the /etc/openvpn/server/ccd/client_name file:

Code:

iroute 10.100.1.0 255.255.255.0

The server is still not able to ping 10.100.1.2.

One strange thing I noticed is that on the server, OpenVPN created the following route:

Code:

10.100.1.0/24 via 10.8.0.2 dev tun0

10.8.0.2 is another OpenVPN client we have, but I want the 10.100.1.0 subnet to go through the 10.8.0.3 client. The /etc/openvpn/server/ccd/client_name file is for the 10.8.0.3 client, so why did OpenVPN create the route "via 10.8.0.2"? But even after I manually deleted that route and created a new route "via 10.8.0.3", the server still couldn't ping 10.100.1.2.

ferrari · 08-25-2020, 02:26 AM

Quote:

The reason I added a secondary IP address to tun0 is because there is a device connected to the client, and we want to access the device through the secondary IP address, not the 10.0.8.3 address.

That's not the solution. The tunnel address can be left out of the equation. Assuming that you have a device connected to the VPN client host eg via eth1 (with vtun0 tunnel via eth0), then you add a route to the device subnet from the server (and either a default route or static route back to the server from the client). For example...

server------INTERNET------eth0<client>eth1----192.168.4.0/24----device
vtun0=======tunnel=======vtun0

The client CCD file (configured in the server) should contain the following directive
iroute 192.168.4.0 255.255.255.0

The main server config file will contain...
route 192.168.4.0 255.255.255.0

As per the second link I gave...

Quote:

Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

sllinux · 08-25-2020, 10:49 AM

Our network will actually look like this, because we will have multiple clients, each of which will have a device attached to it. There could end up being hundreds of clients on the right side.

Code:

device manager<10.8.0.2 client>---OpenVPN server---INTERNET---eth0/tun0<10.8.0.3 client>eth1---10.0.2.0/24---device<10.0.2.2>
                                               \---INTERNET---eth0/tun0<10.8.0.4 client>eth1---10.0.2.0/24---device<10.0.2.2>
                                               \---INTERNET---eth0/tun0<10.8.0.5 client>eth1---10.0.2.0/24---device<10.0.2.2>

So each device ends up being assigned the same 10.0.2.2 address on the client subnet. That's why we want to add a unique 10.100.1.x address to the tun0 interface on the client, so that the device manager can access each device.

So it wouldn't work to have "route 10.0.2.0 255.255.255.0" in the main server config file.

ferrari · 08-25-2020, 02:35 PM

I manage a network with a number of remote networks connected via tunnel routers. They generally all employ unique unique managed IP space. However, I have a couple of client situations whereby I have to use NAT to cope with internal/external addressing. You should be able to do the same here with suitable SNAT and DNAT rules in each of your clients.