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.

@waeck said in pfSense interne DNS auflösen, dann zu PI Hole. Geht das?:

Ist dies möglich?

Ja , wenngleich es auch andersrum geht. Du kannst die PIs einfach für Upstream DNS an die pfSense verweisen und die macht dann die Auflösung nach draußen. Dann musst du nicht mit der internen Domain und DHCP und Co doppelt rumhamstern und die Daten an pfSense und Pi doppelt eintragen

@waeck said in pfSense interne DNS auflösen, dann zu PI Hole. Geht das?:

Ich dachte, dass ich 1.1.1.1 nehmen würde.
Oder gibt es da bessere, die weniger tracken?

Ja, ca. alle anderen überspitzt ausgedrückt. Nur weil die angeblich(!) nicht tracken, heißt nicht, dass es Sinn macht, ALLE DNS Abfragen aus seiner Butze an einen einzigen DNS zu ballern. Einfach den DNS Resolver der pfSense selbst auflösen und nicht weiterleiten lassen, dann fragt der jeden DNS der Welt wenns sein muss. Aber nicht immer nur einen.

Sinnvollerer Weg wäre IMHO:

Per DHCP die PIs (oder den PIhole) rausgeben (bei mir sinds zwei) Bei den PiHoles ist die pfSense als Upstream drin Auf pfSense macht Unbound DNS Resolving (NICHT forwarding) und löst den Kram einfach auf indem er von den ROOTs bis zu den zuständigen DNSen fragt. Ist im ersten Aufruf einen ticken langsamer, danach aber in unbound und deinem Pihole eh gecached. Fertig :)

Ja man kann das auch alles via pfBlockerNG vllt nachbauen, hat aber IMHO bei DNS Blocking das Problem, dass wenn man nicht alles gleichbehandeln will es wenig Optionen gibt. PiHole kann da nicht nur UI technisch einen bessere Figur machen, sondern kann auch mehrere IP-Ranges und Gruppen verwalten auf die verschiedene Blocklisten angewendet werden können.

Cheer

@dk_e said in regelmäßiger WAN ausfall. Einfach neustart hilft ABER:

Aber noch ne Frage, hast du das irgendwo im Log gesehen oder wie bist du auf die Idee genommen (noch so um zu lernen:).

Im Log hab ich nur gesehen dass eine Realtek zum Einsatz gekommen ist. Realtek & FreeBSD da gibt es haufenweise Foreneinträge die das Zusammenspiel von diesen Karten und dem Betriebssytem thematisieren.