summaryrefslogtreecommitdiffstats
path: root/src/vnet/ip/ip_container_proxy.c
diff options
context:
space:
mode:
authorAlexander Chernavin <achernavin@netgate.com>2022-09-26 15:11:27 +0000
committerAlexander Chernavin <achernavin@netgate.com>2022-09-27 10:50:32 +0000
commit522a5b33321ea198fe73f3180a692c316c63575f (patch)
tree2b9159990ff7f5d96bf507bb0e74dbe3f663cbda /src/vnet/ip/ip_container_proxy.c
parentab15770ec63367498dd277c83a577a52594953e8 (diff)
wireguard: fix re-handshake timer when response sent
Type: fix As per the protocol: A handshake initiation is retried after "REKEY_TIMEOUT + jitter" ms, if a response has not been received... Currently, if retransmit handshake timer is started, it will trigger after "REKEY_TIMEOUT + jitter" ms and will try to send a handshake initiation via wg_send_handshake() given that no responses have been received. wg_send_handshake() will verify that time stored in REKEY_TIMEOUT has passed since last handshake initiation sending and if has, will send a handshake initiation. Time when a handshake initiation was last sent is stored in last_sent_handshake. The problem is that last_sent_handshake is not only updated in wg_send_handshake() when sending handshake initiations but also in wg_send_handshake_response() when sending handshake responses. When retransmit handshake timer triggers and a handshake response has been sent recently, a handshake initiation will not be sent because for wg_send_handshake() it will look like that time stored in REKEY_TIMEOUT has not passed yet. Also, the timer will not be restarted. wg_send_handshake_response() must not update last_sent_handshake, because this time is used only when sending handshake intitiations. And the protocol does not say that handshake initiation retransmission and handshake response sending (i.e. replying to authenticated handshake initiations) must coordinate. With this fix, stop updating last_sent_handshake in wg_send_handshake_response(). Also, this fixes tests that used to wait for "REKEY_TIMEOUT + 1" seconds and did not receive any handshake initiations. Then they fail. Also, long-running tests that send wrong packets and do not expect anything in reply may now receive handshake intiations, consider them as replies to the wrond packets, and fail. Those are updated to filter out handshake initiations in such verifications. Moreover, after sending wrong packets, error counters are already inspected there to confirm packet processing was unsuccessful. Signed-off-by: Alexander Chernavin <achernavin@netgate.com> Change-Id: I43c428c97ce06cb8a79d239453cb5f6d1ed609d6
Diffstat (limited to 'src/vnet/ip/ip_container_proxy.c')
0 files changed, 0 insertions, 0 deletions