Why can I ping client → server, but not server → client, in a Wireguard context?

Question

I have Wireguard set up on an Arch server (the server is both on the LAN 192.168.10.0/24 network as 192.168.10.2, and the WG one (192.168.20.0/24, he is 192.168.20.0).

I connect to this server from a client on the Internet (I will use client and server words to make it clear which peers I am talking about). The WG IP is 192.168.20.3.

What works

I can connect from the client to the server → from the client all of the below are OK

ping 192.168.20.0 → client to WG endpoint on the server
ping 192.168.10.2 → client to the server LAN IP
ping 192.168.10.68 → client to a machine on the LAN

What does not work

I cannot ping the client from the server:

root@srv ~# ping 192.168.20.3
PING 192.168.20.3 (192.168.20.3) 56(84) bytes of data.

^C
--- 192.168.20.3 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6081ms

Since the client → sever connectivity is OK, it means that the routing is fine (packets can go to the devices on the LAN and come back afterward)

The routing table on the server:

root@srv ~ [1]# ip r
default via 192.168.10.1 dev enp3s0 proto static
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-4f4174b6b888 proto kernel scope link src 172.18.0.1
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.2
192.168.10.0/24 dev wg0 proto static scope link
192.168.20.0/24 dev wg0 proto kernel scope link src 192.168.20.0

On the client:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.113     45
        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.0.0    255.255.255.0         On-link     192.168.0.113    301
    192.168.0.113  255.255.255.255         On-link     192.168.0.113    301
    192.168.0.255  255.255.255.255         On-link     192.168.0.113    301
     192.168.10.0    255.255.255.0         On-link      192.168.20.3      5
   192.168.10.255  255.255.255.255         On-link      192.168.20.3    261
     192.168.20.0    255.255.255.0         On-link      192.168.20.3      5
     192.168.20.3  255.255.255.255         On-link      192.168.20.3    261
   192.168.20.255  255.255.255.255         On-link      192.168.20.3    261
        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.0.113    301
  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.0.113    301
===========================================================================
Persistent Routes:
  None

score 0 · Accepted Answer · answered Jul 16 '22 at 14:11

0

This is due to the firewall on my laptop (the "client") that drops all incoming packets (except a few services) and since this is a centrally managed service I cannot do anything to fix the connectivity.

answered Jul 16 '22 at 14:11

WoJ

3,365
8
46
75

You sure it is the firewall you did not deactivate the ping response on the client? – Blockchain Office Jul 16 '22 at 17:17
@BlockchainOffice: yes. My work laptop is closed down outside of the AD domain so it is normal that a packet with an external source (such as a WG client) is rejected. I found them in the firewall logs (dropped). – WoJ Jul 16 '22 at 17:20
Ok so you found the solution for your problem? – Blockchain Office Jul 16 '22 at 17:21
@BlockchainOffice: well, yes - this is why I posted it as an answer. – WoJ Jul 16 '22 at 17:23

Why can I ping client → server, but not server → client, in a Wireguard context?

1 Answers1