Enable Correct Routing with VPN Interface

ip-routinglinux-networkingnetworkingroutingvpn

I installed wireguard on a server in a LAN and have a problem with a single ping between two components. the topology is as follows:

  • srv is a Linux machine (Ubuntu 18.04) which has one physical interface with the IP 192.168.10.2 and a virtual interface with IP 192.168.20.1
  • remote is a machine which connects to the LAN via wireguard and has IP 192.168.20.2
  • internal is a machine on the LAN which has IP 192.168.10.5

Generally speaking, machines on the real LAN are in 192.168.10.0/24 and on the VPN in 192.168.20.0/24.
There are no iptables restrictions anywhere.
IP Forwarding is enabled on srv.

The problem: I can ping everything from everywhere, except 192.168.10.2 from 192.168.20.2 (the physical NIC IP on the server from the remote machine which is on the VPN).

Specifically

  • I can reach from remote both the srv side of wireguard (192.168.20.1) and anything else on the LAN (192.156.10.5 in the list above).
    • I can reach remote from srv (via the VPN)

The routing table on srv (br0 is the "physical" interface, in reality this is a bridge but it does not matter here)

default via 192.168.10.1 dev br0 proto dhcp metric 1024
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.2
192.168.20.0/24 via 192.168.20.1 dev wg0 proto static
192.168.20.0/24 via 192.168.10.2 dev br0 proto dhcp metric 1024

The routing table on remote

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.237.76.1      10.237.78.2     25
      10.237.76.0    255.255.252.0         On-link       10.237.78.2    281
      10.237.78.2  255.255.255.255         On-link       10.237.78.2    281
    10.237.79.255  255.255.255.255         On-link       10.237.78.2    281
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     192.168.10.0    255.255.255.0     192.168.20.1     192.168.20.2    135
     192.168.20.0    255.255.255.0         On-link      192.168.20.2    291
     192.168.20.2  255.255.255.255         On-link      192.168.20.2    291
   192.168.20.255  255.255.255.255         On-link      192.168.20.2    291
     192.168.56.0    255.255.255.0         On-link      192.168.56.1    281
     192.168.56.1  255.255.255.255         On-link      192.168.56.1    281
   192.168.56.255  255.255.255.255         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link      192.168.56.1    281
        224.0.0.0        240.0.0.0         On-link       10.237.78.2    281
        224.0.0.0        240.0.0.0         On-link      192.168.20.2    291
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link      192.168.56.1    281
  255.255.255.255  255.255.255.255         On-link       10.237.78.2    281
  255.255.255.255  255.255.255.255         On-link      192.168.20.2    291

What can be the reason for a packet sent from 192.168.20.2, going though 192.168.20.1 not to reach 192.168.10.2?

Best Answer

The problem was with the double route

192.168.20.0/24 via 192.168.20.1 dev wg0 proto static
192.168.20.0/24 via 192.168.10.2 dev br0 proto dhcp metric 1024

The first one is added as part of the setup of wg0. It is correct.

The second one is retrieved from DHCP, which sends this route to clients so that they know how to reach 192.168.20.0/24, that is the VPN network.

This information is not only not useful on the host which hold the VPN, but actually harmful as [some terrible things happen, I am not sure what] when a packet from the VPN network is routed to the VPN server (the same host)

Removing the second route solved the problem, but raised another one (not related).