[solved] pfsense OpenVPN hinter Fritzbox 7490



  • Hallo zusammen,

    ich habe eine pfsense Firewall mit einem OpenVPN Server eingerichtet. Das WAN Interface steckt an der Fritzbox und bekommt per DHCP die Adresse 192.168.178.5 zugewiesen. Das LAN Interface hat die IP 192.168.20.1. In diesem Subnetz 192.168.20.0/24 hängen ein paar Clients auf diese ich über VPN zugreifen möchte. Das OpenVPN Subnetz ist 192.168.21.0/24.

    Die Fritzbox macht die Interneteinwahl etc. und bekommt eine dynamische IP zugewiesen. Daher habe ich über die myfritz Funktion das dynamische DNS eingerichtet. Der Name löst schon mal die IP auf.
    Die Fritzbox hat die IP Adresse 192.168.178.1. Unter den Freigaben habe ich den Port 1194 UDP für IPv4 auf die IP Adresse 192.168.178.5 (pfsense WAN Interface) freigegeben.

    Auf der pfsense habe ich eine Regel definiert damit der Port 1194 UDP auf die WAN Address erlaubt wird.
    Zusätzlich habe ich eine Regel unter OpenVPN erstellt die alles erlaubt.

    So nun habe ich das Problem die VPN Einwahl von einem Client funktioniert nicht.

    Was benötigt Ihr um mir zu helfen? Habe schon gelesen das es am doppelten NAT liegen könnte? Was bedeutet das und wie kann ich es richtig machen?

    Kann ich die VPN Einwahl auch direkt auf dem WAN Interface sprich über die IP 192.168.178.5 testen? Dann würde ich die Fritzbox erstmal außen vor lassen um das auszuschließen.



  • Moin,

    soweit sollte alles funktionieren, double NAT ist kein Problem, betreibe ich selber so.
    Was natürlich Kokolores ist der pfSense eine IP per DHCP zuzuweisen. Es ist ein Gerät Deiner Infrastruktur, die bekommen feste IPs. Das ist aber nicht Ursache für Dein Problem, könnte aber mal zu einem Problem werden.

    Was für ein Client? Welches Betriebssystem? Hast Du das Logging beim Client mal aktiviert und Dir die Meldungen angesehen? Was sagt das Log auf der pfSense bei einem Verbindungsversuch?
    Kommt überhaupt was an?

    @johndo said in pfsense OpenVPN hinter Fritzbox 7490:

    ... So nun habe ich das Problem die VPN Einwahl von einem Client funktioniert nicht.

    Das ist leider etwas zweiteutig formuliert, funktioniert es von einem anderen Client? Oder von keinem? Oder hast Du nur 1 Client von dem es nicht funktioniert?

    -teddy



  • Hallo,

    das mit der DHCP Adresse am WAN Interface verstehe ich, und würde es auf eine fixe IP abändern. Es war gestern schon ziemlich spät daher reiche ich nun noch die Konfigurationen sowie Fehlermeldungen nach.

    pfsense
    Firefox_Screenshot_2019-06-20T19-50-19.927Z.png

    Firefox_Screenshot_2019-06-20T19-56-35.826Z.png

    Firefox_Screenshot_2019-06-20T20-01-50.102Z.png

    Firefox_Screenshot_2019-06-20T20-09-49.860Z.png

    Firefox_Screenshot_2019-06-20T20-10-17.823Z.png

    Firefox_Screenshot_2019-06-20T20-12-10.064Z.png

    Firefox_Screenshot_2019-06-20T20-15-59.033Z.png



  • @johndo das eigentlich Interessante wäre jetzt Verbindungsversuch starten und dann unter Status --> System Logs -->OpenVPN schauen was passiert ist.

    -teddy


  • Rebel Alliance Moderator

    @johndo said in pfsense OpenVPN hinter Fritzbox 7490:

    Die Fritzbox hat die IP Adresse 192.168.178.1. Unter den Freigaben habe ich den Port 1194 UDP für IPv4 auf die IP Adresse 192.168.178.5 (pfsense WAN Interface) freigegeben.

    Gibt es eine Grund, warum du nicht einfach der pfSense ne statische IP gibst und schlichtwegs alles per exposed Host auf diese weiterleitest? Weniger Ärger und weniger rumsuchen bei einem Fehler sind garantiert.

    Zusätzlich Hinweise zu OpenVPN wenn dus eh gerade neu aufsetzt:

    • Wenn schon Zertifikate, sollte man vllt noch ne CRL nutzen. Kann hilfreich sein.
    • Server Einstellungen: AES-256-CFB? Noch nirgends gesehen, macht IMHO keinen Sinn. Old-school / compat. ist CBC.
    • Force all traffic through tunnel ist Absicht? Dann aber ggf. kein NATting vergessen, damit der Client dann via VPN ins Internet kommt...
    • Compression am Besten mit "no comp" disablen, nicht mit compress xy.
    • Push comp. settings to client kann helfen
    • Force DNS Cache Update kann unter Windows helfen
    • Wenn DNS Leaking ein Problem ist Block Outside DNS noch anmachen
    • UDP Fast I/O kann manchmal helfen, kommt auf die Verbindung an. Mit Bufferwerten spielen.
    • GW creation sollte nur auf dem stehen, was auch genutzt wird - in dem Fall auf IPv4 only
    • Verbosity auf 3 stellen solange du testest - gibt mehr Infos!

    Zusätzlich empfehle ich bei neuen VPNs aus Security und Performance Gründen:

    • AES-256-GCM direkt einstellen (beim NCP dann 256-GCM und notfalls 256-CBC für Fallback darunter hinzufügen)
    • DH Parameter: ECDH only
    • ECDH curve: brainpoolP384r1 oder secp384r1
    • SHA-384
    • No LZO compression

    Alternativ kann man obiges auch mit der p-521 Kurve (secp521r1) oder brainpoolP512r1 und SHA-512 machen. 384 reicht aber gut aus. Sowohl die secpXXXr1 als auch brainpool Kurven sind u.a. Empfehlungen von BSI und anderen Stellen. Abwärtskompatibel kann man auch auf RSA mit 3-4k Stärke gehen, kleiner als 2k ist aber ein No-Go. Gleiches auch für IPSEC, dort sollten 3DES, MD5, SHA1 und IKE1 agressive auf der Blacklist stehen. Minimum AES-256-CBC (weil die Gegenstellen meist zu dumm sind für GCM) und SHA-256 Minimum. Optimal wären IKEv2, AES256-GCM, SHA-512 und DH30 oder 31 (brainpool 512 oder curve25519).



  • Hallo,

    ich habe nun auf der Fritzbox die pfsense als exposed Host eingerichtet. Danach habe ich die OpenVPN Server Konfiguration angepasst.

    Firefox_Screenshot_2019-06-21T09-48-36.275Z.png

    Ich habe den neuen OpenVPN Client für Windows exportiert und installiere diesen nun auf dem Client und teste. Mal eine generelle Frage. Kann ich den aus meinem eigenen Netz das überhaupt testen? Oder muss das von extern geschehen?


  • Rebel Alliance Moderator

    @johndo said in pfsense OpenVPN hinter Fritzbox 7490:

    Kann ich den aus meinem eigenen Netz das überhaupt testen? Oder muss das von extern geschehen?

    Extern. Du bist in dem Netz/LAN dass du per VPN pushst. Das geht nicht, die Route würde nicht angenommen werden.



  • 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
    


  • 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.



  • Hi,

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



  • 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?



  • @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?



  • @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.



  • 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.



  • @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



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



  • 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.



  • 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?



  • 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?



  • 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!


  • Rebel Alliance Moderator

    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 :/



  • 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



  • @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.


  • Rebel Alliance Moderator

    @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.



  • @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


  • Rebel Alliance Moderator

    @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


Log in to reply