0

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?

WoJ
  • 3,365
  • 8
  • 46
  • 75
  • Use metrics to send traffic the way you want. Having the same metric on both interfaces does not help anything except creating random scenarios. – Overmind Mar 15 '19 at 13:31
  • @Overmind: would you mind expanding a bit? My understanding is that the metrics are used for equivalent routes (when there is a wired a wireless card for instance and the wired is to be preferred) - which is not the case here. A packet sent to `192.168.10.2` matches the second route, and only this one. – WoJ Mar 15 '19 at 14:47
  • And a packet set to 1.2.3.4 where will it go ? Well, it will go through the int with the lowest metric. – Overmind Mar 18 '19 at 06:16
  • @Overmind: if it does not match any specific route, it will go via the default gateway. in case there would be more than one, the metric would be taken into account. Route affinity has priority, only then (equal routes) the metric is taken into account. – WoJ Mar 18 '19 at 08:39
  • Well many times the intent is not to have it go through the default GW. – Overmind Mar 18 '19 at 11:07
  • @Overmind: this is what specific routes are for, or metrics for routes with the same specificity. – WoJ Mar 19 '19 at 13:45

1 Answers1

0

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).

WoJ
  • 3,365
  • 8
  • 46
  • 75