[solved] pfsense OpenVPN hinter Fritzbox 7490

[johndo]

@bahsig

Hi,

ja, der läuft. Ich sehe auch im WAN Regelwerk sobald ich mich mit dem VPN Client verbinde das da Pakete übertragen werden. Also würde ich mal sagen da kommt schon irgendwas an.

[nodau]

Ohne Ankündigung wird da kein Provider was umstellen. Welchen Provider nutzt du denn?

EDIT: Stelle mal testweise das Protokoll am OpenVPN-Server auf UDP ipv4 und ipv6 auf allen Schnittstellen ein. Der Rest kann so bleiben.

[johndo]

@bahsig

Hi,

der Anschluss ist ein IPv4. Habe es aber mal umgestellt, aber gleicher Fehler.

[nodau]

Wenns ein reiner IPv4 Anschluss ist, dann kannst du auf der Sense alles fest auf IPv4 setzen.

[johndo]

Hallo zusammen,

ich habe nun einen weiteren Test gemacht um mal die Firtzbox usw. auszuschließen. Das heißt ich habe einen Client direkt an das WAN Interface der pfsense gehängt.
Dann habe ich in der pfsense im WAN Interface "Block private networks and loopback addresses" und "Block bogon networks" deaktiviert, da mein WAN Interface eine private IP Adresse (192.168.178.5) besitzt.

Wenn ich nun auf meinem Client (192.168.178.10) den OpenVPN Client starte kommt die gleiche Fehlermeldung wie vorher über die Fritzbox. Von daher kann ich schon mal sagen es liegt nicht an der Firtbox bzw. dem externen Zugang.

Nun sehe ich im Log aber etwas mehr:

Jun 21 15:34:37 	openvpn 	76290 	192.168.178.10:1194 OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
Jun 21 15:34:37 	openvpn 	76290 	192.168.178.10:1194 TLS_ERROR: BIO read tls_read_plaintext error
Jun 21 15:34:37 	openvpn 	76290 	192.168.178.10:1194 TLS Error: TLS object -> incoming plaintext read error
Jun 21 15:34:37 	openvpn 	76290 	192.168.178.10:1194 TLS Error: TLS handshake failed
Jun 21 15:35:42 	openvpn 	76290 	192.168.178.10:1194 TLS error: The server has no TLS ciphersuites in common with the client. Your --tls-cipher setting might be too restrictive.
Jun 21 15:35:42 	openvpn 	76290 	192.168.178.10:1194 OpenSSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
Jun 21 15:35:42 	openvpn 	76290 	192.168.178.10:1194 TLS_ERROR: BIO read tls_read_plaintext error
Jun 21 15:35:42 	openvpn 	76290 	192.168.178.10:1194 TLS Error: TLS object -> incoming plaintext read error
Jun 21 15:35:42 	openvpn 	76290 	192.168.178.10:1194 TLS Error: TLS handshake failed 

EDIT:
Zur Info mein Client ist ein Windows 10.

[johndo]

Hi,

die VPN Einwahl funktiomiert nun. Ich musste die OpenVPN Konfiguration auf folgende Parameter stellen:

Damit funktioniert es.

Ich nutze als pfsense eine SG-3100 welche Verschlüsselung muss ich den dafür nutzen?

[johndo]

So,

nun läuft das ganze auch hinter der Fritzbox. Letztendlich war es die OpenVPN Konfiguration. Es hat etwas mit den Verschlüsselungs Einstellungen zu tun.
Von was sind diese den eigentlich abhängig? Bzw. woher weiß ich welche funktionieren?

[johndo]

Hallo zusammen,

so habe nun rausgefunden warum es mit der AES-256-GCM Verschlüsselung nicht funktioniert hat. Aus irgendeinem Grund hatte ich noch eine alte OpenVPN Version auf der pfsense die mit diesem Chiper noch nicht umgehen konnte.

Ich habe den OpenVPN Server über den Package Manager mit dem openvpn-client-export auf die aktuelle Version gebracht. Danach habe die Verschlüsselungparamater wieder umgestellt und den neu exportierten OpenVPN Client installiert. Nun funktioniert alles :).

Danke für eure Hilfe!

[JeGr]

Das Problem ist, dass wenn du den Main Cipher (AES-xxx) umstellst, du auch den Client umkonfigurieren musst. Das ist einer der wenigen Werte, die der Client kennen muss! Daher wirds nicht geklappt haben.

Aber was ich sehe:

• AES-256-GCM
• SHA-384
• ECDH Kurve secp384r1

macht mich glücklich. Danke, dass ich jetzt diese Woche wenigstens 2 aktuelle und sichere VPN Konfigurationen sehen durfte. Gibt leider viel zu viel Murks gerade :/

[Gladius]

Eine Bemerkung im Hinblick auf die Verfechter von AES-256 kann ich mir nicht verkneifen.

Als Fazit kann man feststellen, daß AES-128 auch in Zukunft gegen Brute-Force sicher ist,
eingeschlossen die Verwendung von Quantencomputern.

Ein Angriff auf das kryptographische Verfahren selbst ist nicht bekannt. Sollte es einen
geben, gibt es schon jetzt andere (z. B. chacha20poly1305) Verfahren.

LG

[tpf]

@JeGr said in [solved] pfsense OpenVPN hinter Fritzbox 7490:

Das Problem ist, dass wenn du den Main Cipher (AES-xxx) umstellst, du auch den Client umkonfigurieren musst. Das ist einer der wenigen Werte, die der Client kennen muss! Daher wirds nicht geklappt haben.

Aber was ich sehe:

• AES-256-GCM
• SHA-384
• ECDH Kurve secp384r1

macht mich glücklich. Danke, dass ich jetzt diese Woche wenigstens 2 aktuelle und sichere VPN Konfigurationen sehen durfte. Gibt leider viel zu viel Murks gerade :/

Haben wir denn schon irgendwo eine best practice-Übersicht? Ich bin mir ganz sicher, dass viele hier es schlicht wissen, was zum dann aktuellen Zeitpunkt die sicherste Konfiguration ist. Könnte man dann ja oben anpinnen.

[JeGr]

@tpf said in [solved] pfsense OpenVPN hinter Fritzbox 7490:

Haben wir denn schon irgendwo eine best practice-Übersicht? Ich bin mir ganz sicher, dass viele hier es schlicht wissen, was zum dann aktuellen Zeitpunkt die sicherste Konfiguration ist. Könnte man dann ja oben anpinnen.

Jup habe ich m.W. schon mehrfach mal geschrieben bzw. darauf hingewiesen. Aber könnte man durchaus pinnen, ja.

[Gladius]

@tpf said in [solved] pfsense OpenVPN hinter Fritzbox 7490:

Ich bin mir ganz sicher, dass viele hier es schlicht wissen, was zum dann aktuellen Zeitpunkt die sicherste Konfiguration ist.

Welche Konfiguration ist denn aus heutiger Sicht unsicher und worauf beruht die Unsicherheit?

Es gibt genug Möglichkeiten für eine hinreichend sichere Kommunikation mit OpenVPN.
Die Frage nach der sichersten ist vergleichbar mit der Frage nach dem sichersten
Flugzeug für den Transfer von A nach B. Airbus A350 oder Boeing 787?

LG

[JeGr]

@Gladius said in [solved] pfsense OpenVPN hinter Fritzbox 7490:

aus heutiger Sicht unsicher und worauf beruht die Unsicherheit?

Das "warum" ist etwas sehr ausführlich, da kann man sich IMHO selbst ganz gut anlesen. Die "sicherste" Konfiguration per se gibt es auch nicht, aber es gibt sicherlich sichere(re) Konfigurationen im Gegensatz zu solchen, die Schwächen aufweisen.

Was bspw. IPSec angeht sind das Konfigurationen die bspw. DES, 3DES oder auch MD5 bzw. SHA1 benutzen sowie DH Gruppen <=2k RSA einsetzen. Warum? Weil es einfach heute bereits theoretische oder sogar praktische Angriffsszenarien gibt, diese Verschlüsselungen aufzubrechen und somit das "P" in VPN nicht mehr erfüllt sind. Genauso wie man PPTP heute ebenfalls nicht mehr zu VPNs zählen kann.

In Kürze gilt das für OVPN auch. Dabei gehts aber nicht nur um Sicherheit aber auch um Abbildbarkeit in Crypto Beschleunigern, weshalb es ggf. eben unsinnig ist, AES-CBF oder -OFB zu nutzen, wenn der Crypto Beschleuniger CBC oder GCM wesentlich stärker beschleunigen kann.
Bei Blowfish ist aber mit SWEET32 tatsächlich ein Angriffsvektor bekannt. Auch DES, 3DES und RC4 und Konsorten sind anfällig. Für PerfectForwardSecrecy (PFS) braucht es einen sicheren Schlüsselaustausch (Key Exchange, KEX). Ist der der zu schwach gewählt kann es einem Angreifer gelingen die Sitzung vollständig hinterher aufzudröseln. Daher ist kleiner als 2k (2048) schon länger nicht mehr als genügend anzusehen.

Diese Punkte kennt man bspw. auch aus TLS/SSL Zertifikaten und der Zertifikatsgenerierung. Auch hier wird empfohlen mind. 2048bit DH Keys sauber zu erzeugen, die TLS Suite selbst auf min. 1.2 zu setzen und bspw. als Signatur Algorithmus für die Zertifikate SHA-256 zu nutzen, da SHA-1 zu schwach wurde. Genauso auch bei OpenSSH, die kürzlich auch mehrere Schnitte gemacht haben und diverse alte Ciphersuites und Blockcipher ausgemottet haben (Blowfish und alle RC bspw.) und bei denen bspw. inzwischen gar kein RSA Key mehr empfohlen wird (und wenn dann nur mind. 2k besser 4k), sondern ED25519 Keys (elliptische Kurve EC25519).

Die Diskussion ist da weniger "Airbus vs. Boeing", sondern eher: Boeing 7x7-400 Frachtklasse hatte mehrfache Fehler im Triebwerk und bleibt "grounded", müssen wir ggf. die 7x7 Passenger auch runterholen und einmotten oder lassen wir die noch weiter rumkurven, obwohl vielleicht weil gleicher/sehr ähnlicher Body/Frame es ein ähnliches Problem geben könnte? Oder gehen wir nicht zur 787 die ganz anders funktioniert und motten den Rest gleich ein?

Grüße