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  +----------Y
  | Router       |_____|              |      |          |
 vio0      vio1  |     |VPN Gateway   `""""""|  Generic |
-public IP-  | vio0     |  Server  |
  `----.---------'     `..............|    eth0
       |                                     L__________J
 |    The        |
 | Internet      |
 |                |
 |  VPN Client    |
 |  wg1
 | vio0 -public IP-
 |                |

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

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

VPN_Client $ route -n get
   route to:
  interface: wg1
 if address:

And on the router, which is the default gateway for the 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
   route to:
  interface: vio1
 if address:

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

Server $ ping                                                                                                          
PING ( 56(84) bytes of data.                                                                                       
From icmp_seq=1 Redirect Host(New nexthop:                                                                          
64 bytes from icmp_seq=1 ttl=254 time=4.49 ms                                                                                
From icmp_seq=2 Redirect Host(New nexthop:                                                                          
64 bytes from 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                                                                                                       [28/1974]
PING ( 56 data bytes
--- 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 > 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)                                                                                                                     > 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)                                                                                                                    > ICMP protocol 1 port 30619 unreachable, length 36                                               
        (tos 0x0, ttl 64, id 42979, offset 0, flags [none], proto ICMP (1), length 84)                                             > ICMP echo reply, id 28868, seq 4, length 64    

Using ping from both the Router and the VPN gateway to 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!

  • 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


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.