| Message ID | 20221012133457.1927871-3-arne@rfc2549.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [Openvpn-devel,1/3] Move dco_installed from sock->info to sock->info.lsa.actual | expand |
Hi, On Wed, Oct 12, 2022 at 03:34:56PM +0200, Arne Schwabe wrote: > This allows a reconnect in p2p mode and has the side effect of updating > the peer address with the peerid Maybe I am just holding it wrong, but the patch does not change the situation for my p2p reconnection problem. First connect works fine (tls p2p, UDP, one side --tls-client, one side --tls-server). Second connect, server says Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: TLS: new session incoming connection from [AF_INET6]::ffff:194.97.140.5:13846 Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: VERIFY OK: depth=1, C=US, ST=California, L=Pleasanton, O=OpenVPN community project, CN=OpenVPN community project CA, emailAddress=samuli@openvpn.net Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: VERIFY OK: depth=0, C=DE, ST=Bavaria, L=Munich, O=OpenVPN community project, OU=DCO F14 client, CN=freebsd-14-amd64, emailAddress=gert@greenie.net Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305 Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: peer info: IV_PROTO=42 Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1553', remote='link-mtu 1541' Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1' Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: P2P mode NCP negotiation result: TLS_export=1, DATA_v2=1, peer-id 4549764, cipher=AES-256-GCM Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1 Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: TLS: tls_multi_process: untrusted session promoted to trusted Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: No encryption key found. Purging data channel keys Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256 Nov 28 14:23:10 ubuntu2004 tun-udp-p2p-tls-sha256[770748]: [freebsd-14-amd64] Peer Connection Initiated with [AF_INET6]::ffff:194.97.140.5:13846 ... and then, nothing more from openvpn, and the kernel starts logging... Nov 28 14:23:11 ubuntu2004 kernel: [22040621.308786] ovpn_udp_encap_recv: received data from unknown peer (id: 4549764) Nov 28 14:23:12 ubuntu2004 kernel: [22040622.140640] ovpn_udp_encap_recv: received data from unknown peer (id: 4549764) Nov 28 14:23:12 ubuntu2004 kernel: [22040622.212277] ovpn_udp_encap_recv: received data from unknown peer (id: 4549764) The recent patches *have* improved the situation noticeably, because without them, the client would end up in a timeout (because UDP reply packets would go to "the old address+port of the client") - so now changing IPv4 <-> IPv6 between connection attempts works fine. Just "installation in kernel" doesn't. I am slightly confused about the concept of peer-id here, though - so we do P2P NCP, and the peer-id is EKM'ed. Will that result in the *same* peer-id on both sides? Or in a pseudorandom number that differs per side (in which case "tell the kernel" might end up with a different number)? gert
Hi, On Mon, Nov 28, 2022 at 02:26:31PM +0100, Gert Doering wrote: > On Wed, Oct 12, 2022 at 03:34:56PM +0200, Arne Schwabe wrote: > > This allows a reconnect in p2p mode and has the side effect of updating > > the peer address with the peerid > > Maybe I am just holding it wrong, but the patch does not change the > situation for my p2p reconnection problem. I was holding this wrong... applied to my tree, ran server tests, but forgot to "push to the repo that the server tests use". So, without the patch, the problem is easily reproduceable as written below :-) Now testing the actual patch. gert
Hi,
On Mon, Nov 28, 2022 at 02:35:24PM +0100, Gert Doering wrote:
> Now testing the actual patch.
Doesn't work...
without 3/3, I have the
ubuntu2004 kernel: [22034799.495703] ovpn_udp_encap_recv: received data from unknown peer (id: 1114473)
on reconnect, but at least TLS handshake succeeds.
*With* 3/3, I am back to "after half the handshake, UDP packets are
sent to the *old* peer IP+port"
2022-11-28 16:51:27 us=427942 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-11-28 16:54:06 us=24986 TLS: new session incoming connection from [AF_INET6]::ffff:194.97.140.5:43940
2022-11-28 16:54:06 us=26336 read UDPv6 [ECONNREFUSED]: Connection refused (fd=4,code=111)
2022-11-28 16:54:08 us=115117 read UDPv6 [ECONNREFUSED]: Connection refused (fd=4,code=111)
2022-11-28 16:54:08 us=379075 read UDPv6 [ECONNREFUSED]: Connection refused (fd=4,code=111)
and in tcpdump...
client -> server
16:54:37.726666 IP 194.97.140.5.43940 > 195.30.8.84.51201: UDP, length 14
server -> client
16:54:37.728030 IP6 2001:608:1:995a:250:56ff:febb:2084.51201 > 2001:608:0:814::fb00:14.14151: UDP, length 22
16:54:37.728081 IP6 2001:608:0:814::fb00:14 > 2001:608:1:995a:250:56ff:febb:2084: ICMP6, destination unreachable, unreachable port, 2001:608:0:814::fb00:14 udp port 14151, length 78
meh.
gert
diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index 8db4f2ce1..e56028c0c 100644 --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -150,6 +150,13 @@ check_dco_key_status(struct context *c) return; } + /* If the DCO peer id changed, we need to readd the peer */ + if (c->c2.tls_multi->dco_peer_id != -1 + && c->c2.tls_multi->peer_id != c->c2.tls_multi->dco_peer_id) + { + dco_p2p_add_new_peer(c); + } + dco_update_keys(&c->c1.tuntap->dco, c->c2.tls_multi); }
This allows a reconnect in p2p mode and has the side effect of updating the peer address with the peerid Signed-off-by: Arne Schwabe <arne@rfc2549.org> --- src/openvpn/forward.c | 7 +++++++ 1 file changed, 7 insertions(+)