0

I set up a WireGuard VPN server "behind" an internet facing router. Said router additionally acts as the default gateway for all clients in this network.

Please apologize my drawing skills:

  ................     ,______________
  |              |     | wg1  172.16.3.5/30  +----------Y
  | Router       |_____|              |      |          |
 vio0      vio1  |     |VPN Gateway   `""""""|  Generic |
-public IP- 10.0.10.1  | vio0  10.0.10.2     |  Server  |
  `----.---------'     `..............|    eth0 10.0.10.10
       |                                     L__________J
  _____|__________
 |    The        |
 | Internet      |
  `'''''p'''''''''
        |
 ,______|_________
 |                |
 |  VPN Client    |
 |  wg1 172.16.3.6/30
 | vio0 -public IP-
 |                |
 '`'''''''''''''''

The tunnel works and the VPN server and client can communicate with each other over their P2P network (127.16.3.4/30) just fine.

Additionally, the VPN client has been configured (using WireGuard's "allowed IP's" function and a static route), to route the 10.0.10.0/24 network through the VPN tunnel:

VPN_Client $ route -n get 10.0.10.0/24
   route to: 10.0.10.0
destination: 10.0.10.0
       mask: 255.255.255.0
    gateway: 172.16.3.5
  interface: wg1
 if address: 172.16.3.6

And on the router, which is the default gateway for the 10.0.10.0/24 network, a static route has been configured as well, in order to direct traffic to the VPN client through the VPN gateway:

Router $ route -n get 172.16.3.4/30
   route to: 172.16.3.4
destination: 172.16.3.4
       mask: 255.255.255.252
    gateway: 10.0.10.2
  interface: vio1
 if address: 10.0.10.1

With this configuration, it is possible to reach the VPN client on 172.16.3.6 from the LAN (in this example, the "Generic server" machine):

Server $ ping 172.16.3.6                                                                                                          
PING 172.16.3.6 (172.16.3.6) 56(84) bytes of data.                                                                                       
From 10.0.10.1 icmp_seq=1 Redirect Host(New nexthop: 10.0.10.2)                                                                          
64 bytes from 172.16.3.6: icmp_seq=1 ttl=254 time=4.49 ms                                                                                
From 10.0.10.1 icmp_seq=2 Redirect Host(New nexthop: 10.0.10.2)                                                                          
64 bytes from 172.16.3.6: icmp_seq=2 ttl=254 time=4.58 ms  

As one can tell, the software is smart and detects that sending the packet directly to the VPN gateway is shorter than going only over the default gateway.

Whilst that works fine, return pings, from the VPN client to the "Generic server", do not work:

VPN_Client $ ping 10.0.10.10                                                                                                       [28/1974]
PING 10.0.10.10 (10.0.10.10): 56 data bytes
^C
--- 10.0.10.10 ping statistics --- 
2 packets transmitted, 0 packets received, 100.0% packet loss

On the "Generic Server", a tcpdump reveals, that the echo request arrives, and a echo reply is attempted to be sent, however "rejected" by the default gateway:

    Server # tcpdump -entvvvi eth0 icmp
    172.16.3.6 > 10.0.10.10: ICMP echo request, id 28868, seq 4, length 64                                                             
52:54:00:96:d5:ed > 52:54:00:63:30:0b, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42979, offset 0, flags [none], proto ICMP
 (1), length 84)                                                                                                                         
    10.0.10.10 > 172.16.3.6: ICMP echo reply, id 28868, seq 4, length 64                                                               
52:54:00:63:30:0b > 52:54:00:96:d5:ed, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 255, id 56306, offset 0, flags [none], proto ICM
P (1), length 56)                                                                                                                        
    10.0.10.1 > 10.0.10.10: ICMP 172.16.3.6 protocol 1 port 30619 unreachable, length 36                                               
        (tos 0x0, ttl 64, id 42979, offset 0, flags [none], proto ICMP (1), length 84)                                                 
    10.0.10.10 > 172.16.3.6: ICMP echo reply, id 28868, seq 4, length 64    

Using ping from both the Router and the VPN gateway to 172.16.3.6 works fine.

  • The router, VPN gateway and VPN client run OpenBSD - the "Generic server" runs openSUSE.
  • The VPN gateway has IP forwarding enabled and is hence technically a "Router" as well.
  • There are host firewalls in place which were set to explicitly pass all ICMP traffic for testing.

Why does the router fail to direct the echo reply to the VPN gateway for dispatch to the VPN tunnel?

Would appreciate any pointers.

Thank you very much for reading!

1
  • Unfortunately, questions about hosts/servers and consumer-grade devices are off-topic here. You could try to ask this question on Server Fault for a business network.
    – Ron Maupin
    Jul 31 at 13:57

1 Answer 1

0

Many routers default to reject (or silently drop) packets where the route points back out of the interface that it was received on.

You need to either configure the router to accept and correctly forward those packets (and optimally issue an ICMP Redirect to skip the hairpin routing on subsequent packets), or make the internal hosts route directly to the VPN gateway, using a static route.

If that isn't really practical you could alternatively use a layer-3 switch in between the hosts and the router. If you point the hosts' default gateway to the L3 switch and the switch's default route to the WAN router with a static route to the VPN gateway, you should be set.

Not the answer you're looking for? Browse other questions tagged or ask your own question.