WireGuard, keepalive time doubled?

[Jan Johansson]

Hello!

I was experimenting with wireguard keepalive and noticed that
keepalive packets seems to be sent on double the time that I have
set which I find a bit unintuitive.

The peer is setup like this on side a

wgpeer k....
wgpsk (present)
wgpka 60 (sec)
wgendpoint b.b.b.174 2222
tx: 868, rx: 496
last handshake: 96 seconds ago
wgaip c.c.c.33/32

debug log on side a

11:41:04 wg /bsd: wg0: Sending handshake initiation to peer 4
11:41:04 wg /bsd: wg0: Receiving handshake response from peer 4
11:41:04 wg /bsd: wg0: Sending keepalive packet to peer 4
11:41:04 wg /bsd: wg0: Receiving keepalive packet from peer 4
11:43:03 wg /bsd: wg0: Sending keepalive packet to peer 4
11:45:03 wg /bsd: wg0: Sending handshake initiation to peer 4
11:45:03 wg /bsd: wg0: Receiving handshake response from peer 4
11:45:03 wg /bsd: wg0: Sending keepalive packet to peer 4
11:45:03 wg /bsd: wg0: Receiving keepalive packet from peer 4
11:47:03 wg /bsd: wg0: Sending keepalive packet to peer 4
11:49:03 wg /bsd: wg0: Sending handshake initiation to peer 4
11:49:03 wg /bsd: wg0: Receiving handshake response from peer 4
11:49:03 wg /bsd: wg0: Sending keepalive packet to peer 4
11:49:03 wg /bsd: wg0: Receiving keepalive packet from peer 4
11:51:03 wg /bsd: wg0: Sending keepalive packet to peer 4

tcpdump on side b show the following traffic

11:41:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] initiation from 0xcccc
11:41:03 b.b.b.174.2222 > a.a.a.64.1111: [wg] response from 0x8888 to 0xcccc
11:41:04 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x8888 nonce 0
11:41:04 b.b.b.174.2222 > a.a.a.64.1111: [wg] keepalive to 0xcccc nonce 0
11:43:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x8888 nonce 1
11:45:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] initiation from 0xdddd
11:45:03 b.b.b.174.2222 > a.a.a.64.1111: [wg] response from 0x0000 to 0xdddd
11:45:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x0000 nonce 0
11:45:03 b.b.b.174.2222 > a.a.a.64.1111: [wg] keepalive to 0xdddd nonce 0
11:47:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x0000 nonce 1
11:49:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] initiation from 0x1111
11:49:03 b.b.b.174.2222 > a.a.a.64.1111: [wg] response from 0x6666 to 0x1111
11:49:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x6666 nonce 0
11:49:03 b.b.b.174.2222 > a.a.a.64.1111: [wg] keepalive to 0x1111 nonce 0
11:51:03 a.a.a.64.1111 > b.b.b.174.2222: [wg] keepalive to 0x6666 nonce 1

Is this to be expected or am I missing something?

Both sides run OpenBSD 6.8 amd64 if that affects anything.

Best regards,
Jan J

[Stuart Henderson]

Post by Jan Johansson
Hello!
I was experimenting with wireguard keepalive and noticed that
keepalive packets seems to be sent on double the time that I have
set which I find a bit unintuitive.

FWIW I'm using wgpka 75 with one peer in one place, and wgpka 50 with several peers
in another place, all work as expected here (fairly recent -current). Not sure what
might be different with your setup.

[Alexander Hall]

Post by Jan Johansson
Hello!
I was experimenting with wireguard keepalive and noticed that
keepalive packets seems to be sent on double the time that I have
set which I find a bit unintuitive.

...

Post by Jan Johansson
Is this to be expected or am I missing something?
Both sides run OpenBSD 6.8 amd64 if that affects anything.

Just a random thought; are you running on actual hardware or testing
with some sort of virtualization involved? VMM and friends are known
to sometimes double delays...

/Alexander

[Jan Johansson]

Post by Alexander Hall

Post by Jan Johansson
Is this to be expected or am I missing something?
Both sides run OpenBSD 6.8 amd64 if that affects anything.

Just a random thought; are you running on actual hardware or
testing with some sort of virtualization involved? VMM and
friends are known to sometimes double delays...

That would be it, the side with wgpka set is a virutal machine
running on a OpenBSD 6.8 host.

I will just stick with the documented suggestion of 25 (which
gives me 50 seconds) and works well with the default of 60
seconds for PF udp.multiple states.

Thanks a lot!