OpenVPN 2.5.9 auf 2.6.3

[hsiewert]

Hallöle Zusammen,

Hat jemand von euch OpenVPN 2.6.x als Client unter Windows am laufen ?

Client = Windows 10 / OpenVPN2.5.9
FW =  23.1.7_3 (OpenVPN 2.6.3)

Meine Aktuelle VPN-Config Clientseitig sieht so aus.
--------
dev tun
persist-key
cipher AES-128-GCM
persist-tun
auth SHA256
client
resolv-retry infinite
verify-x509-name "....." subject
remote-cert-tls server
comp-lzo no

remote-random
remote vpn...1 1194 udp4
remote vpn...2 1195 udp4
remote vpn...3 1196 udp4
remote vpn...4 1197 udp4
remote vpn...5 1198 udp4
remote vpn...6 1199 udp4
remote vpn...7 1200 udp4
remote vpn...8 1201 udp4

float 
tun-mtu 1500 
sndbuf 524288
rcvbuf 524288
key-direction 1

verb 3
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
--------

Läuft soweit gut.

Sobald ich auf den Clients Version 2.6.x installiere bekommt ich ein sonderbares Verhalten.
Die Clients können sich zwar mit dem VPN verbinden, es kommen aber keine Daten mehr durch bzw. "tröpfeln". Manchmal kann der Client auf alle Resource zugreiffen, nach einem Client-Neustart geht nichts mehr oder die Verbindung arbeitet als "Einbahnstrasse", Pakete laufen zur Firewall aber kommen nicht mehr zurück.

Korrekturen der Client-Config (und der Gegenstelle) auf
--------
client
dev tun
data-ciphers-fallback AES-256-CBC
persist-tun
persist-key

auth SHA1

resolv-retry infinite
verify-x509-name "....." subject
remote-cert-tls server
allow-compression no

remote testvpn 1193 udp4

float 
tun-mtu 1500 
sndbuf 524288
rcvbuf 524288
key-direction 1

verb 3
<ca>
...
</ca>
<cert>
...
</cert>
<key>
...
</key>
--------

Haben auch keinen Erfolg gebracht. Ich stehe ein bissle auf dem Schlauch.
Habt Ihr eine Idee ?

[hsiewert]

Die entsprechende Server-Config für den Testserver, die die FW generiert:

dev ovpns2
verb 3
dev-type tun
dev-node /dev/tun2
writepid /var/run/openvpn_server2.pid
script-security 3
daemon openvpn_server2
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
down /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
local "test-vpn--public-ip"
client-connect "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '2'"
tls-server
server 172.20.103.64 255.255.255.192
client-config-dir /var/etc/openvpn-csc/2
tls-verify "/usr/local/opnsense/scripts/openvpn/ovpn_event.py '2'"
lport 1193
management /var/etc/openvpn/server2.sock unix
push "dhcp-option DNS [IP Internet DNS1]"
push "dhcp-option DNS [IP Internet DNS2]"
push "register-dns"
push "block-outside-dns"
push "redirect-gateway def1"
client-to-client
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /usr/local/etc/inc/plugins.inc.d/openvpn/dh.rfc7919
crl-verify /var/etc/openvpn/server2.crl-verify
persist-remote-ip
float
max-clients 12
sndbuf 0
rcvbuf 0
push "sndbuf 524288"
push "rcvbuf 524288"

[Patrick M. Hausen]

Pack mal

Code: [Select]

providers legacy defaultin die Client-Config.

[hsiewert]

Das schmeisst keinen Fehler.

Allerdings bekomme ich beim Verbinden:

Mon May 22 19:16:59 2023 Preserving previous TUN/TAP instance: OpenVPN TAP-Windows6
Mon May 22 19:16:59 2023 Blocking outside dns using service succeeded.
Mon May 22 19:16:59 2023 Initialization Sequence Completed
Mon May 22 19:16:59 2023 Register_dns request sent to the service
Mon May 22 19:16:59 2023 MANAGEMENT: >STATE:1684775819,CONNECTED,SUCCESS,172.20.97.6,[Public-IP-Address],1195,,
Mon May 22 19:16:59 2023 Data Channel: cipher 'AES-256-GCM', peer-id: 0
Mon May 22 19:16:59 2023 Timers: ping 10, ping-restart 60
Mon May 22 19:16:59 2023 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
Mon May 22 19:17:09 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:17:19 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:17:29 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:17:39 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:17:49 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:17:59 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:18:09 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:18:20 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)
Mon May 22 19:18:29 2023 write to TUN/TAP : Der an einen Systemaufruf übergebene Datenbereich ist zu klein.   (fd=ffffffffffffffff,code=122)

---
Der Fehler kommt beim Zugriff auf das Zielnetzwerk. OpenVPN 2.6.4 ist auch keine Lösung, das tut gar nicht.

[Patrick M. Hausen]

Sorry, Ende der Ideen. Bin auch nicht so der OpenVPN Guru. Mein Vorschlag zielte auf ein Inkompatibilität mit den neueren Clients, die hier schon öfter im Forum auftauchte.

Ich würde jetzt die üblichen Werkzeuge rausholen: Routing-Tabelle angucken, tcpdump ...

[hsiewert]

Es beruhigt mich ja schon etwas, dass ich vermutlich nichts übersehen habe ...
Ich grabe mal weiter.