@johndo said in OpenVPN Server für Clients:

Ich habe nun die Möglichkeit eine komplett neue Netgate Appliance 7100 einzurichten. Ich würde nun gerne einen OpenVPN Server inkl. CA analog dem bestehenden Guide einrichten und kann im Anschluss das ganze wieder als HowTo hier im Forum bereitstellen. Eventuell wäre es für den ein oder anderen Interessant.

Ich sehe nicht ganz den Grund für einen Guide, wenn es die Docs/Howtos von Netgate selbst gibt, aber vielleicht gibt es ja durchaus Bedarf. Ich sehe das persönlich ein wenig kritisch, weil sich die Howtos, Docs, Blogs und Co immer weiter Häufen und jeder irgendwas anders bastelt und schraubt und irgendwann stehen dann wieder alle im Kreis und keiner weiß, was man denn dann jetzt tun soll. Am Schlimmsten sind dann die dutzenden (teils sehr schlechten/invollständigen/falschen) VPN Anbieter Tutorials. Darum rate ich da zur Vorsicht, aber ansonsten dokumentiere gerne mit.

@johndo said in OpenVPN Server für Clients:

Die ersten Fragen die ich hätte beziehen sich auf das erstellen der CA. Zur Info die CA soll nur für OpenVPN verwendet werden...

a12620b9-bd3c-4969-b57a-481409d1596e-grafik.png

Sollte man "Randomize Serial" aktivieren? Klingt für mich logisch das immer zu aktivieren? Key type RSA oder ECDSA? Wenn RSA Keysize 4096 oder höher? Wenn ECDSA secp384r1 oder secp521r1? Digest Algorithm sha384 oder höher?

Da die CA nur für OpenVPN genutzt wird und man die Clients eh selbst deployed, kann man hier auch wählen was modern und sicher ist. Wenn man hier keine Rücksicht auf steinalte OpenVPN Versionen in veralteten Geräten, Routern oder sonstwas nehmen muss, kann man hier moderne Standards wählen.

Randomize Serial würde ich hier empfehlen, genauso ECDSA mit mind. prime256. secp384r1 oder 521 muss nicht unbedingt sein. Mehr ist nicht immer besser. Ebenso SHA256. 384 oder 512 sind auch hier nett, aber keine Pflicht. Es geht auch um Performance und Co. Daher würde ich hier auf gute Sicherheit ohne es zu übertreiben setzen.

@johndo said in OpenVPN Server für Clients:

Eine weitere Frage wäre was ist die "Beste" Cryptographic Hardware für mein vorhaben? Voreingestellt ist das hier:

Es hat einen Grund, warum die 7100 (auch wenn sie EOS ist) so ausgeliefert wird. Daran gibt es auch nichts zu ändern. QAT ist für den C3000-Atom immer noch die beste Option. In manchen wenigen Situationen kann IPsec MB ein Quentchen mehr aus der HW herausholen aber im Normalfall bzw. in der Breite wird die QAT Beschleunigung des C3k Atom besser funktionieren. OpenVPN sucht sich via OpenSSL selbständig den Beschleuniger den es nutzen kann. Wenn AES oder QAT da und enabled ist, wird es also gneutzt.

Sofern man dann bei den OpenVPN Settings nicht die Verschlüsselung signifikant absichtlich kaputt konfiguriert, sollte das passen. Auch hier gilt wenn keine Altlast mitgeschleppt wird kann hier das neueste und schnellste ausgewählt werden. Ergo GCM mit 256 und ggf. noch Chacha20 als Alternative. Das wars. CBC ist da Altlast und verhindert ohnehin, dass man DCO benutzen kann. Seit OVPN 2.6 ist das bei Clients - sofern die Konfig nicht Murks ist - eh schon aktiv. Wenn man es auf Serverseite auch noch ins Spiel bringen kann - bestens und senkt Last und erhöht Performance nochmal deutlich. Einige Vergleiche mit IPsec und Wireguard erzielen mit OpenVPN DCO sogar je nach Szenario gleiche oder höhere Geschwindigkeiten ohne das "leichte" Chaos von Wireguards Public/Private Key Konfiguration für jeden Peer.

Daher viel Erfolg :)

Cheers

@viragomann said in OpenVPN - TLS Handshake failed :-(:

ich würde erstmal überprüfen, ob die Pakete überhaupt am Server ankommen.

Naja - wenn ich eine Fehlermeldung vom Server quote, werden sie das wohl…

Ich habe inzwischen - nach vielem Herumprobieren - eine funktionierende Konfiguration. Case closed.

so richtig schlau werde ich aus dem Beitrag nicht.
Habe jetzt mal den Loglevel für openVPN2 auf 11 gesetzt.

Jul 26 14:44:20 openvpn 15236 /usr/local/sbin/ovpn-linkup ovpns2 1500 0 10.42.42.1 10.42.42.2 init
Jul 26 14:44:20 openvpn 15236 /sbin/ifconfig ovpns2 10.42.42.1 10.42.42.2 mtu 1500 netmask 255.255.255.255 up
Jul 26 14:44:20 openvpn 15236 TUN/TAP device ovpns2 exists previously, keep at program end
Jul 26 14:44:20 openvpn 15154 dev = 'ovpns2'
Jul 26 14:44:19 openvpn 82902 Flushing states on OpenVPN interface ovpns2 (Link Down)
Jul 26 14:44:19 openvpn 98318 /usr/local/sbin/ovpn-linkdown ovpns2 1500 0 10.42.42.1 10.42.42.2 init
Jul 26 14:44:19 openvpn 98318 /sbin/ifconfig ovpns2 10.42.42.1 -alias
Jul 26 14:43:51 openvpn 98318 /usr/local/sbin/ovpn-linkup ovpns2 1500 0 10.42.42.1 10.42.42.2 init
Jul 26 14:43:51 openvpn 98318 /sbin/ifconfig ovpns2 10.42.42.1 10.42.42.2 mtu 1500 netmask 255.255.255.255 up
Jul 26 14:43:51 openvpn 98318 TUN/TAP device ovpns2 exists previously, keep at program end
Jul 26 14:43:51 openvpn 98105 dev = 'ovpns2'
Jul 26 14:43:50 openvpn 66818 Flushing states on OpenVPN interface ovpns2 (Link Down)
Jul 26 14:43:50 openvpn 45248 /usr/local/sbin/ovpn-linkdown ovpns2 1500 0 10.42.42.1 10.42.42.2 init
Jul 26 14:43:50 openvpn 45248 /sbin/ifconfig ovpns2 10.42.42.1 -alias

@slu Also, die 23.05.1 war nicht die Lösung! Ich habe an meinem Unify AP einen TCPDUMP durchgeführt und festgestellt, das fragmentierte Paket die Verbindung des AP zum Windows NPS Server verhindern. Habe dann etwas mit den FRAME MTU Raten am NPS rumgespielt, einerlei Erfolg! Erfolg brachte das setzen des nachfolgenden Punktes

Reassemble IP Fragments until they form a complete packet
in den System\Advanced\Firewall & NAT Einstellungen unter VPN Paket processing
Nach setzen dieses Hakens ging mein WLAN (mit Zertifikat) über IPSEC sofort wieder. Das hat mich einiges an
Debug Aufwand gekostet......

@aboutchris Wollte ich gerade als Lösung schreiben - einfach Update Pfad hin- und zurück switchen - aber du hasts selbst schon gefunden. Grund kann einfach sein, dass die Box beim letzten Check einen (dann schon gefixten) falschen Pfad oder Zertifikat abbekommen hat und damit die Paketquellen zerwürfelt. Umsetzen auf einen anderen Pfad lädt das komplett neu statt nur zu updaten, darum klappt das meistens. Müsste via Konsole und mit einem erzwungenen reset/refresh auch gehen, aber in der UI gibts da wenig Möglichkeit aktuell, daher ist da das hin-zurück-schalten der Workaround der oft klappt :)

Aber schön, dass es geklappt hat und gut, dass es jetzt hier für deutschsprachige User auch nochmal zu finden ist!

Cheers
\jens

@Blumagine said in IPv6 Konfiguration:

@JeGr Hallo,
danke schon einmal für deine Hilfe,
folgende Konfiguration - ich habe bei einem Dritten einen Hetzner Dedicated Server gemietet. Auf diesem läuft ein Hyper-V mit drei VMs.

VM pfsense, WAN geht direkt durch auf Hetzner LAN, LAN geht auf virtuellen Hyper-V-Switch
2./3. Windows Server mit LAN am Hyper-V-Switch.

Von Hetzner bekomme ich leider nur ein /64 (2a01:XXXX:XXXX:2d4f::/64), davon habe ich momentan die ::1/64 auf das WAN als feste IPv6 gebunden mit WAN Gateway fe80::1.
EDIT: ich bekomme auch kein zweites /64, da sich der Anbieter schon bei IPv6 überhaupt total quergelegt hat - das bräuchte ja heutzutage keiner... 😧

Wunsch wäre jetzt, dass die beiden Windows-Server am LAN eine IPv6 aus diesem Bereich bekommen (oder zu mindestens ipv6.google.com öffnen können). Leider kann ich im LAN aber nicht das gleiche Präfix eintragen, da mir die pfsense das nicht zulässt?

Liebe Grüße,
Lars

Moin Lars,

dann bleibt wahrscheinlich nichts anderes übrig als das LAN mit einem Lokalen IPv6 Prefix hochzuziehen. Also mit einem Prefix aus dem fdXY:: Bereich, bei welchem empfohlen wird, das zu randomisieren. Also die ersten 64bit der Adresse zufällig mit fd-Prefix zu wählen. Man könnte aber auch ein Auge zudrücken und bspw. bei einem 2a00::xy bspw. das passende fd00::xy intern zu nutzen, damit die Adressen einfacher greifbar werden. Dann müsste es IMHO relativ einfach machbar sein, ein NPt zu definieren mit dem Hetzner IP6/64 auf dem WAN und dem zugehörigen ULA aus dem FD-Bereich.

Also bspw.:

Vom Provider: 2a00:3210:abcd:1242::/64 ULA: fd00:3210:abcd:1242::/64

Und dann das FD-Netz intern eben ganz normal wie ein statisches Netz ausrollen. Entweder mit SLAAC oder wenn Erreichbarkeit von extern via V6 passieren soll, dann statisch eine Dienst-IP6 vergeben (und ggf. die zusätzlichen privacy extensions per SLAAC/DHCP6 erlauben). Diese sollten dann wenn NPt sauber konfiguriert wurde sauber nach draußen gehen.

@Blumagine said in IPv6 Konfiguration:

Wunsch wäre jetzt, dass die beiden Windows-Server am LAN eine IPv6 aus diesem Bereich bekommen (oder zu mindestens ipv6.google.com öffnen können). Leider kann ich im LAN aber nicht das gleiche Präfix eintragen, da mir die pfsense das nicht zulässt?

Natürlich lässt sie das nicht zu, man darf auf zwei unterschiedlichen Interfaces auch nicht die gleiche IP-Range nutzen, da ansonsten ja keiner weiß WO das Paket hin soll. Darum muss man mit zwei verschiedenen Netzen arbeiten.
Man könnte jetzt zwar damit kommen, dass man auch mit einer "transparenten Bridge" arbeiten könnte, aber das ist in den meisten Fällen gerade wenn man mit Netzwerk nicht ganz firm ist eher überkomplex und fehleranfällig.

Cheers

@dogfight76 said in Installation PFSense auf alten PC per USB-Stick:

Und dort ist der gleiche Eintrag wie bei den Gateways die funktionieren, darum verstehe ich nicht warum: AUTH_FAILED
Das betrifft doch den Username und Passwort. Oder ?

Dann ist ganz klar User/Pass bei deinem Client falsch oder wird von der Gegenseite abgelehnt. Ganz egal was woanders eingetragen ist, wenn das hier als Feedback im Log kommt, ist das was deine Config an den Server übermittelt falsch. Dann hast du entweder deine Credentials falsch eingetragen, es haben sich irgendwelche Kontrollzeichen reingemogelt (Leerzeichen, Linebreak o.ä.) oder man muss bei Nord noch irgendwas anderes machen, dass das bei deren Servern funktioniert mit dem Login. Aus Mangel an Account und Co kann ich da leider wenig zu sagen.

Ich habe das hier mit Proton, die dazu auch ne vernünftige Anleitung haben, zweimal für völlig unterschiedliche Standorte durchgespielt - da funktioniert alles einwandfrei. Die Credentials die mir Proton ausgibt, werden sauber beim Client in den Feldern User/Pass eingetragen und ausgelesen und er kann sich verbinden.

Notfalls mal bei Nord nachfragen warum OVPN da sagt, dass User/Pass falsch wären.

Ja daher gibt man bei so einer VM auch die MAC fest vor oder setzt diese als fix.
Dann ändert die sich nicht.

Musste meine Labor + auch schon mal neu machen, also VM Export wieder importiert, done.
Also stelle das jetzt sauber ein im Hypervisor.

@esquire1968-0 said in pfSense 2.7 OpenVPN Problem:

Ich habe jetzt tls-version-min 1.0 in die Server und alle Client Configs eingetragen, jetzt haben wieder alle Clients eine Verbingung.

Tatsächlich haben wir auch noch den ein oder anderen legacy OpenVPN Client, auf dem Server hat hier aber tls-version-min 1.0 ausgereicht.
Die Frage ist jetzt nur wenn der Client mehr kann ob dann auch eine höhere TLS Version verwendet wird...

@viragomann said in VLAN to LAN Interface:

@verdammt
Ja, wenn nur das LAN zum Switch geht und die DMZ Geräte nicht eine gemeinsame Broadcast Domain benötigen, würde ich es so machen.
Das erspart die Bridge und auf der Interface Gruppe lassen sich ebenso NAT- und Firewallregeln definieren. Bietet also fast denselben Komfort bei der Konfiguration. Der DHCP muss natürlich auf beiden eingerichtet werden.

Vielleicht die Subnetze so besser wählen, dass sie sich mit einem /23er zusammenfassen lassen, bspw. 192.168.100./24 u. .101./24.

Danke, das ist auch eine gute Idee.

Bugfix dafür ist BTW jetzt via Pull Request gestellt - schauen wir mal :)
https://github.com/pfsense/pfsense/pull/4646

@Quasimodo-0 said in Nach Upgrade von 2.6 auf 2.7 bootet pfSense in unregelmäßigen Abständen einfach neu:

[05-Jul-2023 00:09:00 Europe/Berlin] PHP Fatal error: Uncaught ValueError: Path cannot be empty in /etc/inc/notices.inc:101

Diese Errors klingen nach einem zusätzlichen Package was irgendwie Terz gemacht hat und mit PHP im Clinch lag. Was genau und warum ist da unklar ohne komplette Paketliste und mehr Logs, aber da es jetzt funktioniert, ist es ggf. was gewesen, dass jetzt nicht mehr installiert ist oder was sich durch alte Konfig-Fragmente vllt. weggeschossen hatte.

Cheers

@bon-go said in einfach neuen SSH Key und self signed Webserver Cert erstellen möglich?:

Ja, ich weiss wie das geht. Es hätte ja sein können, es gibt für 1. eine schnellere und einfachere Möglichkeit als ein ssh-keygen auf der Shell für den ssh Server der pfSense. Die pfSense macht das ja auch wenn der SSH Server erstmalig aktiviert wird.

ja die SSH HOST Keys - die du wahrscheinlich meinst - sind erst seit kurzem Bestandteil des Backups. Du kannst es einfach AUSschalten, dass diese mit exportiert werden, dann hast du den pre-2.5?2.6? Zustand wieder in welchem die Host Keys beim First Boot einfach erzeugt werden.

Das Self-Signed Cert kann auf der Konsole wieder neu erstellt werden:

CLI Menü Option 12 (PHP Shell / Tools) playback generateguicert exit

Und dann hast du ein neues Cert, wobei das bei self-signed relativ gleichgültig ist ob das die gleichen sind oder nicht, da sie eh keine Aussagekraft haben. Bei SSH Host Keys bin ich aber bei dir, das möchte man über Restore Deployment sicher nicht mit ausrollen.

Ansonsten genügt auch ein rm /etc/ssh/*key* um alle SSH Host Keys zu löschen, diese werden dann nach einem Reboot automatisch wieder erzeugt. Alles weitere zum Verständnis kann man der /etc/sshd Konfiguration entnehmen, dort werden die Keys erzeugt wenn nicht vorhanden und entsprechende Extras und Ciphers gesetzt. Herumpfuschen sollte man da allerdings nicht, höchstens sich anschauen, wie man sie bei Bedarf selbst neu erzeugt ohne löschen und reboot.

Cheers

@viragomann okay. Das probiere ich mal.

@viragomann said in Individueller DNS-Server für ein Vlan festlegen:

@DerTom24
Vor einigen Jahren wurde mal der Screenshot erfunden. Heute kann das jedes System. Ein nettes Werkzeug. Solltest du mal versuchen...

Du pingst hier mit der Quelle von einem anderen Subnetz. Das kannst du von einem Gerät in dem Subnetz auch machen. Wäre für mich aussagekräftiger.

Aber okay, wenn das nicht funktioniert, fehlt meist die Outbound NAT Regel für das Subnetz.
Ist das Outbound NAT im Automatik-Modus? Wenn ja, schau, ob das Subnetz in den automatischen Regeln auftaucht. Falls nicht, musst du eine Regel für die Quelle manuell hinzufügen.

@viragomann
OK - vor Jahrhunderten wurde der respektvolle Umgang miteinander erfunden - solltest Du mal versuchen.

Vielen Dank und eine schöne Woche!

@karl047 Hab die Frage von Beginn an verstanden, kann sie aber auch nicht beantworten, da kein Pro. Vermutlich wird ICMP für IPv6 irgendwie anders behandelt.

@JeGr
Schon klar, ich verwende ein /24. Ist auch so eingestellt.

Ich hatte das jetzt dreimal. Aber nachdem ich das heute nochmal ausprobiert habe, um dem weiter nachzugehen, funktioniert das plötzlich. Ich will nicht an Zufall glauben, dazu war das zeitliche Zusammentreffen einfach zu genau, aber ich kann beim besten Willen nicht mehr nachvollziehen, ob ich bei den erste drei Mal etwas anders gemacht habe und wenn ja was.

Ich lege es zu den Akten.

Danke trotzdem für's Lesen / Helfen!

@pixel24
vor einigen Wochen war das ganz extrem, da konnte man oft Stunden lang die IP nicht updaten.