Can reach VPN peer only after ping from this peer

Question

Problem

I have two linux PCs connected to a local network and to a WireGuard VPN network. (let's say VPN subnet = 10.66.66.0/24 and PC A=10.66.66.9 and PC B=10.66.66.10).

The problem is that I can't ping and ssh from A to B through VPN, but it works if I ping any IP (even that doesn't exist) in VPN subnet from B in advance or while A is trying to ping/ssh B.

The local A to B and B to A ping/ssh works fine and A is always reachable for other VPN peers.

So the problem is only with B PC in VPN network.

Configs

WireGuard server config:

[Interface]
Address = 10.66.66.1/24,fd42:42:42::1/64
ListenPort = 60207
PrivateKey = privatekey
PostUp = iptables -I INPUT -p udp --dport 60207 -j ACCEPT
PostUp = iptables -I FORWARD -i eth0 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport 60207 -j ACCEPT
PostDown = iptables -D FORWARD -i eth0 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

### Client
[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
AllowedIPs = 10.66.66.9/32,fd42:42:42::9/128

### Client
[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
AllowedIPs = 10.66.66.10/32,fd42:42:42::10/128

### Client
...

A config:

[Interface]
PrivateKey = privatekey
Address = 10.66.66.9/32,fd42:42:42::9/128

[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
Endpoint = endpoint:60207
AllowedIPs = 0.0.0.0/0,::/0

B config:

[Interface]
PrivateKey = privatekey
Address = 10.66.66.10/32,fd42:42:42::10/128

[Peer]
PublicKey = pubkey
PresharedKey = preshardkey
Endpoint = endpoint:60207
AllowedIPs = 10.66.66.0/24,fd42:42:42::0/112

---

Problem example

1. ping from A to B through VPN

A:~ $ ping 10.66.66.10
PING 10.66.66.10 (10.66.66.10) 56(84) bytes of data.

(no more output)

2. ping non existent VPN subnet IP (or A) from B, while A to B ping is going

B:~ $ ping 10.66.66.5
PING 10.66.66.5 (10.66.66.5) 56(84) bytes of data.
From 10.66.66.1 icmp_seq=1 Destination Host Unreachable
From 10.66.66.1 icmp_seq=2 Destination Host Unreachable
From 10.66.66.1 icmp_seq=3 Destination Host Unreachable
From 10.66.66.1 icmp_seq=4 Destination Host Unreachable
...

3. Suddenly a lot of A to B ping output appears after the previous step

A:~ $ ping 10.66.66.10                                                                                                             (12-09 15:40)
PING 10.66.66.10 (10.66.66.10) 56(84) bytes of data.
64 bytes from 10.66.66.10: icmp_seq=1 ttl=63 time=26756 ms
64 bytes from 10.66.66.10: icmp_seq=8 ttl=63 time=19592 ms
64 bytes from 10.66.66.10: icmp_seq=9 ttl=63 time=18568 ms
64 bytes from 10.66.66.10: icmp_seq=7 ttl=63 time=20615 ms
64 bytes from 10.66.66.10: icmp_seq=10 ttl=63 time=17544 ms
64 bytes from 10.66.66.10: icmp_seq=11 ttl=63 time=16520 ms
64 bytes from 10.66.66.10: icmp_seq=12 ttl=63 time=15496 ms
64 bytes from 10.66.66.10: icmp_seq=13 ttl=63 time=14472 ms
64 bytes from 10.66.66.10: icmp_seq=14 ttl=63 time=13448 ms
64 bytes from 10.66.66.10: icmp_seq=15 ttl=63 time=12424 ms
64 bytes from 10.66.66.10: icmp_seq=16 ttl=63 time=11400 ms
64 bytes from 10.66.66.10: icmp_seq=18 ttl=63 time=9352 ms
64 bytes from 10.66.66.10: icmp_seq=17 ttl=63 time=10376 ms
64 bytes from 10.66.66.10: icmp_seq=19 ttl=63 time=8328 ms
64 bytes from 10.66.66.10: icmp_seq=20 ttl=63 time=7304 ms
64 bytes from 10.66.66.10: icmp_seq=21 ttl=63 time=6279 ms
64 bytes from 10.66.66.10: icmp_seq=22 ttl=63 time=5256 ms
64 bytes from 10.66.66.10: icmp_seq=23 ttl=63 time=4232 ms
64 bytes from 10.66.66.10: icmp_seq=24 ttl=63 time=3208 ms
64 bytes from 10.66.66.10: icmp_seq=25 ttl=63 time=2185 ms
64 bytes from 10.66.66.10: icmp_seq=26 ttl=63 time=1160 ms
64 bytes from 10.66.66.10: icmp_seq=27 ttl=63 time=137 ms
64 bytes from 10.66.66.10: icmp_seq=28 ttl=63 time=94.4 ms
64 bytes from 10.66.66.10: icmp_seq=29 ttl=63 time=94.6 ms

And now I can ping and ssh from A to B for a while.

Answer 1

There are two likely explanations:

1. The firewall at B wasn't configured to allow incoming WireGuard UDP packets through. When the 'Server' sends a packet to B, it's rejected as unrecognized.

   Once B tries to ping something in the VPN and sends an outgoing WireGuard packet, its firewall starts accepting incoming packets as it recognizes that they're "reply" packets which belong to an active flow. If the flow becomes idle for several minutes, the firewall forgets it and starts rejecting the incoming packets again.

2. B is behind NAT, and the NAT gateway at B wasn't configured to forward incoming WireGuard UDP packets to B's private address.

   The explanation is mostly the same as with the firewall – the first outbound packet creates the NAT state and allows replies to go through.

One easy solution for all problems would be to enable PersistentKeepalive= on B, under its [Peer] configuration for the 'Server'. This would make B periodically send packets to the 'Server', so that it always knows an up-to-date endpoint address and all firewalls and NAT gateways along the path keep tracking the UDP packet flow.

(Often the UDP flow timeout is between 30 and 120 seconds, so try a keepalive interval of 100 seconds; if that's not enough, do 20 seconds.)

If the location of B is static, another solution would be to manually define all necessary configuration – manually set a local port in its [Interface] configuration; allow UDP packets to that port through its firewall; create "port forwarding" rules if necessary; and set a static Endpoint for B on the 'Server'.