id summary reporter owner description type status priority milestone component version severity resolution keywords cc 1272 One client kills other client session via false client floating kia0 stipa "One client can effectively stop VPN traffic of another client by 'client float' mechanism in case of reuse peer_id. Steps to reproduce: OpenVPN 2.4.8 process acting as server using tun interface and UDP. Client authentication is by SSL key/certificate, different for all clients. Option 'duplicate-cn' is not set. At least one client (""aggressor"") uses single key/cert on two or more devices simultaneously, so the sessions preempts each other. Another client (""victim"") connects at time between aggressor's first and second device and get reuse peer_id from the stale aggressor's session (you need a luck to have peer_id reused). When a packet from first aggressor's session came to the server, it floats the victim's session to first aggressor's and stop respond to victim. Victim can't get traffic from VPN and then drops the session by keep-alive timeout As aggressor's sessions preempts each other continuously, it can randomly freezes/kills other client sessions Here is scenario: 1) Aggressor connects from the first device, ip:port is a.b.c.d:xxx, authenticates using key1/cert1, get peer_id=123, have sessions A1 2) Aggressor connects from the second device ip:port=e.f.g.h:yyy, authenticates using same key1/cert1, get peer_id=234, get session A2 replacing A1. Server logged ""new connection by client 'aggressor' will cause previous active sessions by this client to be dropped"". Peer_id 123 is freed. The first device don't informed about this and still have A1 valid 3) Victim connects from ip:port=i.j.k.l:zzz, authenticates using key2/cert2 and occasionally get peer_id=123, get session V1 4) Aggressor's first device sends network traffic to VPN using session A1 which is still valid on the device. Data packet with peer_id=123 come to the server and is not dropped. The server think this packet is from V1 because it has this peer_id. Server erroneously floats V1 to A1 logging ""peer 123 floated from i.j.k.l:zzz to a.b.c.d:xxx"" 5) As session keys in A1 and V1 are different, server drops incoming data traffic from both and logging errors ""local/remote TLS keys are out of sync"" or somewhat similar. 6) Victim does not see keep-alive packets come back and drops V1 after configured timeout. First aggressor's device do the same for A1 7) First aggressor's device reconnects, makes a session A3, which preempts A2. The scenario repeats 8) Victim try to reconnect and can have a luck if peer_id got is different from 234 I think good result can be not to float peer by just peer_id or to just drop stale A1 packets on server at step 4 " Bug / Defect closed major release 2.4.9 Generic / unclassified OpenVPN 2.4.8 (Community Ed) Not set (select this one, unless your'e a OpenVPN developer) fixed client float peer_id reuse tct