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=sam...@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=g...@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
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
