@sebden Was @NOCling sagt. Leider nur mit (überholtem) Aggressive Mode (), SHA-512 und DH2 (völlig wilde Zusammenmischung als hätte jemand gewürfelt) sinnvoll nutzbar. IKE v1 Aggressive Mode AES-256 (CBC) SHA-512 DH Group 2 Zusätzlich sinnvoll: pfSense als: "Responder only" - FB Verbindung aufbauen lassen Wenn es Probleme gibt, dass alle Stunde die Verbindungen abreißen: DPD ausmachen, dead peer detection ist wohl ziemlich guffelig auf der Fritte. Mit Responder und ohne DPD liefen die eigentlich halbwegs gerade, alles andere liegt eher an der Rumpelkammer von AVM.

@marcm said in Dedizierter Server mit Proxmox > pfSense VM > Webserver VM: Ja, wenn ich von außen auf die IP gehe, kommt die Meldung. pd-admin bringt leider alles bei der Installation mit. Apache, Phython, bla bla bla... Was aber nicht heißt, dass man die Konfiguration nicht anpassen könnte. Leider ist immer noch die Frage offen, woher die Meldung kommt. Wenn sie vom Webserver selbst kommt, sollte man das entsprechend anders konfigurieren können, dass der Zugriff akzeptiert wird. Was ist der Webserver Antwortcode zu dieser Meldung?

@silas21 said in Pfsense + OpenVPN Zugriffe auf ein zweites Subnetz: oder ist es möglich der VPN-Verbindung noch eine 2 Adresse (IPv4 Local networks) hinzuzufügen? Du meinst, ein zweites Subnetz? Entweder das oder ein Haken bei Redirect Gateway für den Fall, dass auch der Internettraffic über die VPN gehen soll, sind Voraussetzung, dass du auf den Drucker kommst. Nachdem letzteres nicht interessant sein dürfte, sollte das "Local Networks" Feld so aussehen: 192.168.100.0/24,192.168.10.0/24 Du könntest die Route auch nur auf den Drucker beschränken, indem du als zweites Netz 192.168.10.155/32 angibst. Zusätzlich braucht es noch eine Outbound NAT-Regel, falls die nicht automatisch erstellt wurde. Es sollte eine Regel für WAN und die Quelle 192.168.101.0/24 aufscheinen, anderenfalls, musst du in den Hybridmode wechseln und die Regel manuell erstellen.

So, Zwischenstand nach drei Tagen Betrieb: Hatte dann in den States in der Tat Auffälligkeiten gefunden...über die Schnittstellen Filterung war da ein Rechner mit falscher IP unterwegs...nach Korrektur der Verkabelung stehen in den Fehlern überall freundliche Nullen, da bin ich mal froh! Die States Ansichten haben mich dann also dahin gebracht...danke für die Anregungen.

@johndo Probiere doch mal testhalber, ob die Verbindung besser läuft, indem du am Klienten mal von UDP auf TCP wechselst für die SIP-Verbindung. Wirkt wahre Wunder in manchen Szenarien

@tobi said in Neue Hardware alte Konfig übernehmen: Da sagte die Fritze wohl "hier passt was nicht". Ich musste also die alte Sense als Gerät in der Frizte löschen und dann die neue Hardware kam sofort ohne Probleme rein. Nettes Teil. Ich mag solche Geräte gar nicht, die von selbst solche Aktionen setzen. Ich habe aber auch noch nie eine FB besessen.

@tobi Meine Heim-pfSense läuft virtualisiert auf der Box. Daneben beherbergt sie noch meine Nextcloud, einen Musikserver und einen DLNA Server. Mir war es wichtig, alles möglichst kompakt und ohne viele Kabeln zu haben. Vielleicht wäre das auch für dich interessant, bspw. einen Video Überwachungsserver zusätzlich darauf laufen zu lassen. Das setzt allerdings ein gewisses Vertrauen in die Technik voraus.

@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. [image: 1633637892803-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