Messages

Hallöle zusammen,

im Grossen und Ganzen läuft alles. Gute Arbeit mal wieder  ;D

Mit OpenVPN hätte ich da noch "Special Effects".

Crl-verify:
Sobald ich in den Settings eine RevocationList auswähle startet die Instanz nicht mehr.

2023-08-03T21:01:24   Notice   openvpn_server10   Options error: --crl-verify fails with '/var/etc/openvpn/server-8-blubber-instance-id-0.crl-verify': No such file or directory (errno=2)

In der erzeuten conf wird auf obige Datei referenziert, auf dem Filesystem ist die Datei unter /var/etc/openvpn/ nicht vorhanden.


Certificate Depth
Springt immer wieder auf "Do Not Check" zurück.


Static Keys
Lassen sich zwar anlegen und benutzen aber nicht mehr löschen.

/usr/local/opnsense/mvc/app/controllers/OPNsense/OpenVPN/Api/InstancesController.php:99: Call to undefined method OPNsense\OpenVPN\Api\InstancesController::delStaticKeyBase()



... und halt meine sonderbare Inkompatibilität, dass der Windows-Client in Version 2.6.5 zwar die Verbindung aufbaut aber keine Daten durchlässt. Version 2.5.9 funzt ...


VG

Hallo Spooner,

das kann man so pauschal nicht sagen. Was soll denn von wo nach wo zugreiffen dürfen.

LG

Hallöle,

bitte teste mal die Kombination mit dem Community-Client 2.5.9

LG

Vermtulich der praktikabelste Weg .... Firewall Downgrade.

Hallöle,

die Kombination von OpenVPN 2.6.3 auf der OPNsense und ein 2.5.9 Client funktioniert.

LG

Hallöle,

welchen Client und welche Version benutzt Ihr ?
Wir haben ein Downgrade auf Client 2.5.9 gemacht, da die Client 2.6.2, 2.6.3 und 2.6.4 nicht funktionieren.

LG

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

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.

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"

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 ?

Läuft, kann ich bestätigen.

Wer IPSec benötigt sollte noch ein bissle mit dem Update auf 23.1 warten.

Dieser Fehler hat bei mir auch zugeschlagen.
https://github.com/opnsense/core/issues/6276

Ich gehe aber davon aus, dass hier wie gewohnt schnell ein offizieller Patch erscheinen wird.

Grüße aus dem nebligen Süden

Ja, sowas ist vorhanden.
So richtig klar ist es aber nicht, wo nun das Problem ist.
Wenn ich von mir zu Hause aus messe (iperf3) kriege ich über VPN in einer Session 50MBit/s, was völlig i.O. ist.

Die Spitze gegen 4:00 Uhr sind Backups, die zu uns laufen. Tagsüber komme ich aber selten über 60MBit/s mit allen Verbindungen hinaus.

Grüße

Heiko

Wir nutzen gerade AES-128-GCM, ich stelle aber gerne auch auf was anderes um.

Hallöle Zusammen,

habt Ihr Erfahrungen mit DEC3850 bzw. DEC4020 im Business Umfeld ?

Ich bertreibe aktuell zwei Boxen (HA) mit CPU D-1518@2.20GHz (4 cores, 8 threads). Darauf 8 OpenVPN Instanzen. Seit ein paar Wochen bekomme ich vermehrt Beschwerden, dass VPN zu langsam ist bzw. das es zu Verbindungsabbrüchen durch die Tunnel kommt. Soweit ich sehen kann ist die CPU dicht.

Aktuell sind 60 Benutzer über VPN verbunden. Unsere 300 MBit/s werden nicht ausgeschöpft.

Grüße