@viragomann Dachte ich mir schon, ist aber ist trotzdem schade. Irgendwas ist immer, vor allem wenn etwas einfach umzusetzen ist. Das ganze funktioniert ja überraschend gut, nur das die IP-Adressen von der anfragenden Quelle nicht an den HAProxy weitergereicht werden.

Moin,

ich konnte das Problem nachstellen, wie schon geschrieben mit einer drei stufigen PKI.
Ich habe mein CERT auf die CRL gesetzt mit der Änderung

$subject = $cert_root->content[0]->content[$is_v1 ? 2 : 3];

konnte ich mich nicht mehr anmelden, aus dem VPN Log:
10.0.2.254:37410 VERIFY ERROR: depth=0, error=certificate revoked: CN=XXX, C=DE, ST=XXX, L=XXX, O=XXX, OU=XXX, serial=1

dann habe ich die original Zeile wieder hergestellt

$subject = $cert_root->content[0]->content[$is_v1 ? 4 : 5];

die openVPN instanz neu gestartet und ich konnte mich anmelden.

Kann es vieleicht daran liegen dass von den übergeordneten CAs nur die CERTs imortiert sind, müssen auch die CRLs importiert werden damit der VPN Server die komplette Kette zurückverfolgen kann?

Werde ich morgen Testen.

Grüße

Für 250MBit VDSL würde auch die kleinste Netgate Appliance reichen, hatte die an einer 400/40MBit Cabel Leitung.
Für GBit ist die aber zu langsam, also wurde die vor durch das SG-3100 ersetzt.
Das hat für den Heimbetrieb mehr als genug Power und vom Stromverbrauch her merkt man das nicht, um die 5W Verbrauch sind für die gebotene Leistung und den Durchsatz richtig gut.

@tobi said in IPv6 - Dynamische FW Rules?:

jetzt bei der Telekom und auch später beim neuen Provider EPCAN bekommt man für IPv6 einen Präfix /64

Jein. Du bekommst auf dem WAN normalerweise ein /64er Prefix. Zusätzlich solltest du aber (bzw bekommst du bei Telekom und Co) ein /56er zur Delegation auf die IP6 des Routers, der im /64er Prefix ist. Dieses /56er kann dann für IA_PD (Prefix Delegation) genutzt werden und wird an andere Interfaces dann weitergegeben.

Nur das musste auch wieder eher bedeuten, dass man doch die IP's aus den MAC Adressen abbilden lassen soll und nicht eigene Ranges definieren oder wie? Irgendwie stehe ich gerade auf nem Schlauch 😢

IP6 aus MAC Adresse sind eher die Seltenheit. Der neue Algo der von SLAAC genutzt wird, nutzt nicht mehr die MAC, sondern wird aus anderen Faktoren generiert. Zusätzlich hat ein Gerät mit SLAAC (oder auch DHCP6 wenn so konfiguriert) noch mehrere weitere Adressen für IPv6 Privacy Extensions, rotiert also alle paar Zyklen die IP6 und nutzt eine neue, während die alte noch eine gewisse Zeit aktiv bleibt. Deshalb kann es gut sein, dass ein Client wenn man mal nachsieht zur gleichen Zeit locker ein Dutzend IP6 Adressen hat (inkl. seiner fe80 link local Adresse)

Da via Track Interface dem Interface ja ein bestimmter /64er Prefix aus dem /56er zugewiesen wurde, ist dieser problemlos durch das Interface Alias (VLANname_network) nutzbar. Einzelne Hosts zu packen wir aber eher unschön auch wenn ich nicht weiß, wofür man das unbedingt haben wollen würde.

Man kann aber durchaus auch den Host-Part adressieren, seit 2.5.2/21.05 geht das. Siehe #6626
-> https://redmine.pfsense.org/issues/6626
Es geht also, bspw. Regeln mit ::1243:5678:9012:3456 zu konfigurieren, der Prefix Part wird dann vom Interface abgeleitet. Klappt aber natürlich nur sinnvoll mit einer fixen IP6 also spezifisch eingehend oder ausgehend wenn man nen Service anbietet. Für den Rest ausgehend wird dann ja meist SLAAC/Privacy Extension genutzt.

Vielen Dank für Eure Antworten

Ich habe nun übergangsweise die Fritzbox per LAN2 zusätzlich mit meinem Netzwerk verbunden. So ist nun auch der Zugriff aus allen anderen VLAN auf sie möglich. Ist nicht die Lösung, aber zumindest schon mal eine.

Die Informationen werde ich übers Wochenende in Ruhe zusammenstellen und dann posten.

So viel kann ich jetzt schon sagen: Mit Modem meinte ich, dass die Fritzbox für den Zugang ins WAN zuständig ist. Diese baut die Verbindung auf. Sorry, falls das der falsche Fachbegriff war. Also ungefähr so:

Anschluss vom Anbieter ===> Fritzbox (stellt Verbindung ins Internet her) ===> pfSense (macht alles andere; DHCP, DNS, Firewall, etc.) ===> verschiedene VLANs ===> Endgeräte

Aber irgendwie erkenne ich bei dir gerade keine saubere Netzwerkstruktur. 10er, 192er fehlt nur noch das 172er Netz und du hast alle Privaten Bereiche irgendwie im Mixer.

Ich habe die 192er damals falsch erstellt, es hätte auch ein 10.* Netzwerk sein müssen (mit größerer Maske). Ich dachte, dadurch, dass die VIP Geräte mit 10.* starten, und die IOT Geräte mit 192., kann ich sie direkt einfacher unterscheiden. Natürlich (was ich damals aber irgendwie nicht auf dem Schirm hatte) hätte ich auch einfach 10.0.20. für VIP und 10.0.30.* für IOT vergeben können o.Ä..

Das werde ich bei einer vollständigen Neueinrichtung im Rahmen eines Hardwareupgrades auch in Angriff nehmen.

Das macht die Fritz auch, die Antwort geht dann aber direkt an die pfSense und diese kennt dazu keinen State und blockt das Paket.

Firewalls mögen keine asymmetrisches Routing, das macht immer Probleme!

@nocling
Hi - ja - ich habe es quasi parallel mit deinem Post im Netz gefunden - eingerichtet - läuft ....

Scheinbar macht das das alte Zyxel Modem das anders als die Digibox - jedenfalls läuft es jetzt - vielen dank !

So, da ich meinen Homeserver noch mal umgebaut habe, ergab sich die Gelegenheit einen kleinen Teil des Speichers testweise in VMFS5 zu formatieren.

Tatsächlich kommt der Fehler dann nicht mehr, ich stehe nun schon einige Minuten an der gezeigten Stelle und nichts passiert - das ist erstmal sehr gut.

vmfs5.jpg

Fazit: pfsense bzw. FreeBSD 12 ist mit VMFS 6 nicht kompatibel (außer man tauscht den virtuellen Festplattencontroller von SAS zu SATA).

@gtrdriver Dankeschön. Übernehme ich mal so!

Nabend.

Hier die Bestätigung zu JeGr.

Für all-inkl.com als DDNS Anbieter muss man für IPv6 auf Custom V6 stellen.
Benutzername und Passwort ist klar und als Updateurl dyndns.kasserver.com/?myip6=%IP%
Dann fliegt das.

Vielen Dank.
Nun werde ich die pfSense die Tage auf produktiv setzen und die alte in rente schicken. Danach kann ich dann VPN ggf optimieren.

@pixel24 said in Plötzlich probleme mut ACME + HAProxy:

Oh sorry. Dachte wenn eine Antwort in englisch kommt soll man auch damit antworten.

Nicht wenn du im Deutschen Forenteil bist ;) Zumal Rico ja nur den Link auf die engl. Sektion gepostet hat und nichts in englisch dazugeschrieben hatte :D

Aber wenns dann jetzt erstmal läuft ist das fein 👍

@fnbalu said in pfSense bekommt am Deutsche Glasfaser Anschluss keine IPv6:

Sodele.
Nun bin ich weiter.

Wireguard unterscheidet sich ja grundlegend zwischen Version 2.5.0 und 2.5.2

Was habe ich jetzt.
Die pfSense auf dem VPS hat die Tunnel IP 10.0.0.1 und die zu Hause 10.0.0.2
Die VPS pfSense darf auf 192.168.1.0 zugreifen

Die Routen und Gateway sind angelegt. Aktuell alles noch über IPv4.

Ich kann die Firewall zu Hause pingen unter 192.168.1.1. Also muss der Tunnel ja soweit stehen.

Nur wir sieht das Regelwerk aus wenn ich Mappen möchte?
Ich hätte jetzt gesagt es kommt am WAN an und wird an die jeweilige IP weitergeleitet wenn ich NAT nutze wie vorher.

Der Versuch war 8022 soll auf 443 der pfSense zu Hause mappen.

Aber meine Versuche endeten immer in @4(1000000103) block drop in log inet all label "Default deny rule IPv4"

Versucht habe ich die 8022 an WAN Adress aufzugreifen und Destination ist direkt die 192.168.1.1 oder aber versucht habe ich auch schon das Tunnelgateway.
Immer hing es an der Default Deny Rule, die ich nicht mal habe

Dieses Problem ist auch behoben.
Man benötigt 2 Regeln auf dem VPS.
Zum einen die Inbound Nat, die man ja kennt und dann unter outbound Nat (Hybride Erzeugung) eine Regel wo der Port auf den Wireguard Tunnel gelenkt wird.
Es passt wohl die Rückroute sonst nicht

Hallo

Danke erstmal für die Ausführungen und Ideen....
Ich muss mir mal überlegen wie "tiefgreifend" ich das umsetzten will oder ob man die LTE Verbindung erstmal als "Desaster Plan" integriert so dass man zur Not von Außen drauf kommt (hab ich grad mal mit nem SSH Reverse Tunnel und fixen Schlüsselpaaren probiert - klappt).

Dann könnte man ggfs die VPN´s per Hand auf das LTE Interface umschalten ...

Das OSPE möchte ich erstmal in einer Virtualisierten TEST Umgebung ausprobieren ...

@viragomann Kann ich mich nur anschließen. Eine DMZ mit irgendeiner Art Bridging zu basteln würde mir ziemliche Kopfschmerzen bereiten. Da wäre simples 1:1 NATting oder (noch besser wenn möglich) reines Routing um ein Vielfaches simpler.

Hallo zusammen

vielen Dank für die Hinweise.
Wie gut sind denn die genannten IPU´s in sachen Qualität und Ausdauer ?

@viragomann Darum meinte ich auch, es könnte das oder die NAT Problematik sein:

There are also known issues with NAT, notably that NAT to the interface address works but 1:1 NAT or NAT to an alternate address does not work.

Da ich nicht weiß/sehen kann, wie @zickzack2021 die sensen auf beiden Seiten konfiguriert hat und was da an NAT, CARP oder sonstwas dran hängt, bin ich da auch im Blindflug, wenngleich ich dir recht gebe, dass sich das im Prinzip schon eher nach asym. Routing anhört. Aber auch da müssen wir ja raten, weil wir nicht wissen, wie Standort A/B ins Internet angebunden sind und ob die Sensen auch das Default GW im Netz sind. :)

Guten Abend zusammen 😊

Bei mir hatte es bisher auch fehlerfrei funktioniert, aber von jetzt auf nachher nicht mehr.
Ich habe jetzt über ne Woche nichts mehr damit gemacht und nun funktioniert wieder alles.

Ich habe aber keine Ahnung wieso🤔

Das Thema kann damit geschlossen werden.

Schönen Abend euch 😊