[gelöst] OpenVPN 2.6.x: Authenticate/Decrypt packet error: packet HMAC authentication failed

[heisenberg]

Hi,

ich versuche hier OpenVPN aufzusetzen, bekomme aber immer wieder den Fehler Authenticate/Decrypt packet error: packet HMAC authentication failed am Client. Grundsätzlich lief das schon mal, aber ich habe die Konfiguration heute nochmal verändert und seitdem geht es wieder nicht mehr. Leider habe ich die Config von vor der Veränderung nicht mehr. Ich weiss nur, dass ich an den Werten cipher und data-ciphers rumgespielt habe und die Reihenfolge der Direktiven etwas verändert habe.

Ich habe schon reichlich zum Thema gegoogelt. Die üblichen Ursachen bei dem Fehler sind:

• Einstellungen cipher bzw. data-ciphers inkompatibel (sind identisch gesetzt. s. u.)
• auth-Einstellung unterschiedlich (den Fehler hatte ich zwischendurch auch mal, habe neben der Einstellung hier (SHA256) auch mal SHA512 ausprobiert: -> Gleicher Fehler.)
• tls-auth key unterschiedlich (sind definitiv identisch)

Debug-Level 6 bringt auch keine weiteren Informationen.

Zum Setup

• Server und Client: Debian 12
• Umgebung: Nicht-Produktive Testumgebung
• Zertifikate erstellt mit EasyRSA3 (Siehe: https://community.openvpn.net/openvpn/w ... nVPN-Howto)

Server-Config

Code: Alles auswählen

port 443
proto tcp
dev tun

ca [inline]
cert [inline]
key [inline]
dh [inline]

tls-server
tls-auth [inline] 0

server 192.168.255.0 255.255.255.0
topology subnet

cipher AES-256-CBC
data-ciphers AES-256-CBC
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
auth SHA256
auth-nocache

keepalive 20 60
persist-key
persist-tun
user nobody
group nogroup

verb 3

<ca>
-----BEGIN CERTIFICATE-----
MII...H1w=
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MII...4Ik=
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIG...RqU=
-----END PRIVATE KEY-----
</key>
<dh>
-----BEGIN DH PARAMETERS-----
MII...CAQI=
-----END DH PARAMETERS-----
</dh>

<tls-auth>
-----BEGIN OpenVPN Static key V1-----
e706...269f
-----END OpenVPN Static key V1-----
</tls-auth>

Client-Config

Code: Alles auswählen

remote myopenvpnserver.domain.tld
port 443
proto tcp-client
dev tun

ca [inline]
cert [inline]
key [inline]  

tls-client
tls-auth [inline] 1

cipher AES-256-CBC
data-ciphers AES-256-CBC
auth SHA256

persist-tun
persist-key

verb 3

mute 20

# only for udp, so set to 0 for tcp
explicit-exit-notify 0

user nobody
group nogroup

<ca>
-----BEGIN CERTIFICATE-----
MII...H1w=
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MII...lLE=
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIG...QIA=
-----END PRIVATE KEY-----
</key>

<tls-auth>
-----BEGIN OpenVPN Static key V1-----
e706...269f
-----END OpenVPN Static key V1-----
</tls-auth>

Log auf dem Server:

Code: Alles auswählen

openvpn --config server2.conf
2023-08-04 16:24:58 Note: cipher 'AES-256-CBC' in --data-ciphers is not supported by ovpn-dco, disabling data channel offload.
2023-08-04 16:24:58 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2023-08-04 16:24:58 library versions: OpenSSL 3.0.9 30 May 2023, LZO 2.10
2023-08-04 16:24:58 DCO version: N/A
2023-08-04 16:24:58 net_route_v4_best_gw query: dst 0.0.0.0
2023-08-04 16:24:58 net_route_v4_best_gw result: via 1.2.4.65 dev ens18
2023-08-04 16:24:58 Diffie-Hellman initialized with 4096 bit key
2023-08-04 16:24:58 TUN/TAP device tun0 opened
2023-08-04 16:24:58 net_iface_mtu_set: mtu 1500 for tun0
2023-08-04 16:24:58 net_iface_up: set tun0 up
2023-08-04 16:24:58 net_addr_v4_add: 192.168.255.1/24 dev tun0
2023-08-04 16:24:58 Could not determine IPv4/IPv6 protocol. Using AF_INET
2023-08-04 16:24:58 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-08-04 16:24:58 Listening for incoming TCP connection on [AF_INET][undef]:443
2023-08-04 16:24:58 TCPv4_SERVER link local (bound): [AF_INET][undef]:443
2023-08-04 16:24:58 TCPv4_SERVER link remote: [AF_UNSPEC]
2023-08-04 16:24:58 UID set to nobody
2023-08-04 16:24:58 GID set to nogroup
2023-08-04 16:24:58 Capabilities retained: CAP_NET_ADMIN
2023-08-04 16:24:58 MULTI: multi_init called, r=256 v=256
2023-08-04 16:24:58 IFCONFIG POOL IPv4: base=192.168.255.2 size=253
2023-08-04 16:24:58 MULTI: TCP INIT maxclients=1024 maxevents=1029
2023-08-04 16:24:58 Initialization Sequence Completed
2023-08-04 16:25:02 TCP connection established with [AF_INET]1.2.3.174:45314
2023-08-04 16:25:02 1.2.3.174:45314 TLS: Initial packet from [AF_INET]1.2.3.174:45314, sid=01c5faa0 e2e99981
2023-08-04 16:25:02 1.2.3.174:45314 VERIFY OK: depth=1, CN=valhalla-ca-001
2023-08-04 16:25:02 1.2.3.174:45314 VERIFY OK: depth=0, CN=balmora
2023-08-04 16:25:02 1.2.3.174:45314 peer info: IV_CIPHERS=AES-256-CBC
2023-08-04 16:25:02 1.2.3.174:45314 peer info: IV_PROTO=746
2023-08-04 16:25:02 1.2.3.174:45314 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-08-04 16:25:02 1.2.3.174:45314 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-08-04 16:25:02 1.2.3.174:45314 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit ECsecp384r1, signature: ecdsa-with-SHA256
2023-08-04 16:25:02 1.2.3.174:45314 [balmora] Peer Connection Initiated with [AF_INET]1.2.3.174:45314
2023-08-04 16:25:02 balmora/1.2.3.174:45314 MULTI_sva: pool returned IPv4=192.168.255.2, IPv6=(Not enabled)
2023-08-04 16:25:02 balmora/1.2.3.174:45314 MULTI: Learn: 192.168.255.2 -> balmora/1.2.3.174:45314
2023-08-04 16:25:02 balmora/1.2.3.174:45314 MULTI: primary virtual IP for balmora/1.2.3.174:45314: 192.168.255.2
2023-08-04 16:25:04 balmora/1.2.3.174:45314 Data Channel: cipher 'AES-256-CBC', auth 'SHA256', peer-id: 0
2023-08-04 16:25:04 balmora/1.2.3.174:45314 Timers: ping 20, ping-restart 120
2023-08-04 16:25:04 balmora/1.2.3.174:45314 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
2023-08-04 16:25:10 balmora/1.2.3.174:45314 Connection reset, restarting [0]
2023-08-04 16:25:10 balmora/1.2.3.174:45314 SIGUSR1[soft,connection-reset] received, client-instance restarting
2023-08-04 16:25:11 TCP connection established with [AF_INET]1.2.3.174:36706
2023-08-04 16:25:11 1.2.3.174:36706 TLS: Initial packet from [AF_INET]1.2.3.174:36706, sid=ccf4a102 3cf21f85
2023-08-04 16:25:11 1.2.3.174:36706 VERIFY OK: depth=1, CN=vallhalla-ca-001
2023-08-04 16:25:11 1.2.3.174:36706 VERIFY OK: depth=0, CN=balmora
2023-08-04 16:25:11 1.2.3.174:36706 peer info: IV_CIPHERS=AES-256-CBC
2023-08-04 16:25:11 1.2.3.174:36706 peer info: IV_PROTO=746
2023-08-04 16:25:11 1.2.3.174:36706 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-08-04 16:25:11 1.2.3.174:36706 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-08-04 16:25:11 1.2.3.174:36706 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit ECsecp384r1, signature: ecdsa-with-SHA256
2023-08-04 16:25:11 1.2.3.174:36706 [balmora] Peer Connection Initiated with [AF_INET]1.2.3.174:36706
2023-08-04 16:25:11 balmora/1.2.3.174:36706 MULTI_sva: pool returned IPv4=192.168.255.2, IPv6=(Not enabled)
2023-08-04 16:25:11 balmora/1.2.3.174:36706 MULTI: Learn: 192.168.255.2 -> balmora/1.2.3.174:36706
2023-08-04 16:25:11 balmora/1.2.3.174:36706 MULTI: primary virtual IP for balmora/1.2.3.174:36706: 192.168.255.2
2023-08-04 16:25:12 balmora/1.2.3.174:36706 Data Channel: cipher 'AES-256-CBC', auth 'SHA256', peer-id: 0
2023-08-04 16:25:12 balmora/1.2.3.174:36706 Timers: ping 20, ping-restart 120
2023-08-04 16:25:12 balmora/1.2.3.174:36706 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
2023-08-04 16:25:13 balmora/1.2.3.174:36706 Connection reset, restarting [0]
2023-08-04 16:25:13 balmora/1.2.3.174:36706 SIGUSR1[soft,connection-reset] received, client-instance restarting

Log auf dem Client:

Code: Alles auswählen

openvpn --config ~blub/project/openvpn/client.conf
2023-08-04 16:25:02 Note: --data-cipher-fallback with cipher 'AES-256-CBC' disables data channel offload.
2023-08-04 16:25:02 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2023-08-04 16:25:02 library versions: OpenSSL 3.0.9 30 May 2023, LZO 2.10
2023-08-04 16:25:02 DCO version: N/A
2023-08-04 16:25:02 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-08-04 16:25:02 TUN/TAP device tun1 opened
2023-08-04 16:25:02 TCP/UDP: Preserving recently used remote address: [AF_INET]1.2.4.93:443
2023-08-04 16:25:02 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-08-04 16:25:02 Attempting to establish TCP connection with [AF_INET]1.2.4.93:443
2023-08-04 16:25:02 TCP connection established with [AF_INET]1.2.4.93:443
2023-08-04 16:25:02 TCPv4_CLIENT link local: (not bound)
2023-08-04 16:25:02 TCPv4_CLIENT link remote: [AF_INET]1.2.4.93:443
2023-08-04 16:25:02 UID set to nobody
2023-08-04 16:25:02 GID set to nogroup
2023-08-04 16:25:02 Capabilities retained: CAP_NET_ADMIN
2023-08-04 16:25:02 TLS: Initial packet from [AF_INET]1.2.4.93:443, sid=884c5002 91b99fc0
2023-08-04 16:25:02 VERIFY OK: depth=1, CN=valhalla-ca-001
2023-08-04 16:25:02 VERIFY OK: depth=0, CN=valhalla.domain.tld
2023-08-04 16:25:02 P2P mode NCP negotiation result: TLS_export=0, DATA_v2=0, peer-id 0, cipher=(not negotiated, fallback-cipher: AES-256-CBC)
2023-08-04 16:25:02 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit ECsecp384r1, signature: ecdsa-with-SHA256
2023-08-04 16:25:02 [valhalla.domain.tld] Peer Connection Initiated with [AF_INET]1.2.4.93:443
2023-08-04 16:25:02 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-08-04 16:25:02 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-08-04 16:25:04 Initialization Sequence Completed
2023-08-04 16:25:04 Data Channel: cipher 'AES-256-CBC', auth 'SHA256'
2023-08-04 16:25:10 Authenticate/Decrypt packet error: packet HMAC authentication failed
2023-08-04 16:25:10 Fatal decryption error (process_incoming_link), restarting
2023-08-04 16:25:10 SIGUSR1[soft,decryption-error] received, process restarting
2023-08-04 16:25:10 Restart pause, 1 second(s)
2023-08-04 16:25:11 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2023-08-04 16:25:11 Preserving previous TUN/TAP instance: tun1
2023-08-04 16:25:11 TCP/UDP: Preserving recently used remote address: [AF_INET]1.2.4.93:443
2023-08-04 16:25:11 Socket Buffers: R=[131072->131072] S=[16384->16384]
2023-08-04 16:25:11 Attempting to establish TCP connection with [AF_INET]1.2.4.93:443
2023-08-04 16:25:11 TCP connection established with [AF_INET]1.2.4.93:443
2023-08-04 16:25:11 TCPv4_CLIENT link local: (not bound)
2023-08-04 16:25:11 TCPv4_CLIENT link remote: [AF_INET]1.2.4.93:443
2023-08-04 16:25:11 TLS: Initial packet from [AF_INET]1.2.4.93:443, sid=38c0d672 b0bf1b80
2023-08-04 16:25:11 VERIFY OK: depth=1, CN=valhalla-ca-001
2023-08-04 16:25:11 VERIFY OK: depth=0, CN=valhalla.domain.tld
2023-08-04 16:25:11 P2P mode NCP negotiation result: TLS_export=0, DATA_v2=0, peer-id 0, cipher=(not negotiated, fallback-cipher: AES-256-CBC)
2023-08-04 16:25:11 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 384 bit ECsecp384r1, signature: ecdsa-with-SHA256
2023-08-04 16:25:11 [valhalla.domain.tld] Peer Connection Initiated with [AF_INET]1.2.4.93:443
2023-08-04 16:25:11 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-08-04 16:25:11 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-08-04 16:25:12 Initialization Sequence Completed
2023-08-04 16:25:12 Data Channel: cipher 'AES-256-CBC', auth 'SHA256'

Es kann sein, dass durch die Anonymisierung die IP-Adressen-Fragemente, CNs oder Hostnamen in den Codeschnipseln nicht zusammen passen. Aber wie schon geschrieben: Das hat grundsätzlich bereits vollkommen funktioniert.

[heisenberg]

Was mich wundert ist bei Verbose Level 6 auf dem Server, diese Ausgabe:

Code: Alles auswählen

2023-08-04 16:54:26 us=452907 balmora/1.2.4.174:33982 Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
2023-08-04 16:54:26 us=452949 balmora/1.2.4.174:33982 Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
2023-08-04 16:54:26 us=452974 balmora/1.2.4.174:33982 Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
2023-08-04 16:54:26 us=453002 balmora/1.2.4.174:33982 Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication

Ich habe aber tls-crypt gar nicht konfiguriert ?!
Auf dem Cliente sehe ich auch auf Verbose Level 6 keine Zeilen mit tls-crypt.

---

Ansonsten: Die Hauptfehlermeldung (HMAC authentication failed) kommt erst ca. 6-10 Sekunden nach der Meldung "Initialization Sequence Completed" (am client).

---

den tls-auth key habe ich jetzt nochmal ausgelagert in eine Datei auf beiden Seiten und ein md5sum drüber gemacht. => Keys sind identisch. Keine Veränderung der Situation. => Rollback.

---

Ich habe jetzt mal tls-auth entfernt und statt dessen keys für tls-crypt und später nochmal für tls-crypt-v2 erzeugt (gemäß hier: https://community.openvpn.net/openvpn/w ... nVPN-Howto). Beide Male kein Erfolg. Fehler bleibt gleich. Es muss wohl etwas anderes sein. => Habe ich mal so gelassen.

---

Mal testweise mit UDP probiert: Gleicher Fehler. => Rollback.

[heisenberg]

Auf Debian 12 ist Openvpn 2.6.3-1+deb12u1 im Repository. Ich habe bei meiner Recherche irgendwo gelesen, dass "die neue Version" Probleme macht. Weiss nicht mehr ob da von 2.6.x die Rede war.

Ich habe jetzt openvpn mal deinstalliert und die letzte 2.5.x Version (=2.5.9) per Source kompiliert. Damit funktioniert es direkt. D. h. der Fehler "HMAC authentication failed" tritt nicht auf.

Trotzdem wird das Interface (tun0) nicht aktiviert und bekommt auch keine Tunnel-IP zugewiesen am Client. Nachdem ich das Interface manuell aktiviere und die Tunneladresse manuell konfiguriere funktioniert der Ping.

Hmmm. Noch nicht wirklich befriedigend.

---

Neueste Openvpn-Config (2.6.5) nochmal geholt und kompiliert: Fehler ist wieder da.

[heisenberg]

Nachtrag: Das nicht aktivierte Interface tun0 und die nicht zugewiesene IP-Adresse lag an der fehlenden Direktive pull.

Lösung
Mit der Direktive pull in der Client-Konfiguration tritt der Fehler "HMAC authentication failed" nicht mehr auf. -> [solved]

Kommentar
Warum man das pull für die TLS-Authentication unbeding braucht, habe ich jetzt aber überhaupt nicht verstanden. Auch die Manpage bringt mir da keine weiteren Erkenntnisse.

Kommentar Nachtrag 4.8. 21:00 Uhr
Ich kann mir vorstellen, dass der Grund der Lösung darin liegt, dass bei Client und Server manche Dinge unterschiedlich konfiguriert sind und dass das Pull dafür sorgt, dass der Client sich die entsprechend richtigen Einstellungen, mit denen das klappt vom Server zieht.