[solved] pfsense OpenVPN hinter Fritzbox 7490

johndo

Hi,

so hat etwas gedauert musste erstmal einen externen Client einrichten :). Dieser steht nun bei einem bekannten auf dem Teamviewer läuft und dort habe ich den VPN Client installiert. Es kommt folgender Fehler beim Client:

Fri Jun 21 12:54:00 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Feb 21 2019
Fri Jun 21 12:54:00 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Fri Jun 21 12:54:00 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Fri Jun 21 12:54:03 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Fri Jun 21 12:54:03 2019 UDP link local (bound): [AF_INET][undef]:1194
Fri Jun 21 12:54:03 2019 UDP link remote: [AF_INET]x.x.x.x:1194
Fri Jun 21 12:55:03 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jun 21 12:55:03 2019 TLS Error: TLS handshake failed

EDIT:

Die OpenVPN Client Konfiguration sieht so aus:

dev tun
persist-tun
persist-key
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
auth SHA384
tls-client
client
resolv-retry infinite
remote dyndns.name 1194 udp
verify-x509-name "OpenVPN-Server-Zertifikat" name
auth-user-pass
pkcs12 fw01-UDP4-1194-testbenutzer.p12
tls-auth fw01-UDP4-1194-testbenutzer-tls.key 1
remote-cert-tls server

nodau

Hast du zufällig einen IPv6 Anschluss? Falls ja, lege die Portfreigaben auf der Fritte selbst fest, sowohl für ipv4 als auch ipv6. Bei mir hats mit der Kabelfritte und Dualstack nur so funktioniert. Vorher sind die Pakete nicht mal bis zur Sense gekommen.

johndo

Hi,

wie kann ich den das testen bzw. wo sehe ich das? Wenn ich meine offizielle IP anzeigen lassen ist es eine IPv4 Adresse.

nodau

Im Onlinemonitor der Fritte siehst du das. Wenn da nur ipv4 steht, dann hast du auch nur das.

EDIT: der OpenVPN Server läuft aber?

johndo

@bahsig said in pfsense OpenVPN hinter Fritzbox 7490:

Hast du zufällig einen IPv6 Anschluss?

Oder mal noch anderst gefragt. Macht es Sinn es gleich so einzurichten das es mit IPv4 und IPv6 funktioniert? Könnte ja sein das mein Anschluss irgendwann mal vom Provider umgestellt wird oder?

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.

Firefox_Screenshot_2019-06-21T12-07-01.240Z.png

Firefox_Screenshot_2019-06-21T12-07-08.331Z.png

Firefox_Screenshot_2019-06-21T12-07-22.577Z.png

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:

Firefox_Screenshot_2019-06-21T14-08-17.943Z.png

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 :).

Firefox_Screenshot_2019-06-22T11-21-22.535Z.png

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