@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

Resolver läuft? Regelwerk für das VLAN Int erlaubt Zugriff auf this Firewall mit dem Dienst DNS? Wenn kein Regel vorhanden ist die das erlaubt, dann greift die implicit deny, die siehst du aber nicht, die ist unsichtbar aber immer auf jedem Interface ganz unten vorhaden.

hi @jegr, ja ich habe dank deiner Info einfach mal die pfB_PRI1_v4 manuell in die Interface Rules mit einem anderen Bezeichner hinterlegt und nun klappts auch wieder. Stört mich auch nicht wenn die autorule von pfBlocker nicht aktiv ist, aber es ist schon seltsam gewesen, weil es eben immer bis Dato funktioniert hatte. Soll mir auch recht sein wie du schon selbst meintest wenn nicht "auf Gutdünken" irgendwo eine neue Regel anglegt wird durch die Anwendung selbst. Danke für die Unterstützung! VG

@mx-hero-0 Da kann ich mich tatsächlich Mic nur anschließen. Du versucht eine Firewall Version zu "analysieren", die Okt. 2017 released wurde und es nicht nur etliche Updates seither gab, sondern auch etliche Sicherheitsfixes und Verbesserungen. 4 Jahre alte Software auf alter Hardware, da ist potentiell ein Broadcast Log noch das Kleinste der Probleme :/ Dringend updaten, vor 4 Jahren bspw. ne APU2 Büchse gekauft (auch wenn ich sie nicht mag), dann hätten sich die ~200€ schon lange rentiert Cheers

@viragomann said in SMB Freigabe auf VIP NATen?!?: Die ist einfach im Hostnamen (Computername) zu setzten. Kannte ich auch noch nicht, jetzt mal eingerichtet, danke. Du und @JeGr solltet allerdings recht behalten, das Backup funktioniert inzwischen generell nicht mehr.

@benjaminbeckcsl Ohne Konfiguration ist das echt schwer

man nimmt was man eben an hardware hat

@gabylein said in internes Routing: Die RFC1918 Regel unterbindet das aber , also kommt kein Connect zustanden. Welche RFC1918 Regel? Von LAN/internen Netzen aus gibt es default keine. @gabylein said in internes Routing: IP aus Netz1 über Gateway 1 mit dann fester IP 1 -> feste IP 2 Gateway 2 auf die jeweilige intere IP spricht. Klingt erstmal nicht ideal. Wozu möchte man unnötig den Traffic 2x durch die Firewall ziehen wenn man den Host intern direkt erreichen kann? Ansonsten: kann man machen, muss nur das Outbound NAT richtig konfigurieren. Wenn der Weg sauber gebaut ist, das Routing und die Interface Configs stimmen, sollte es da auch keine Probleme geben, dass man - so unnötig es ist - einmal mit der Kirche ums Dorf fahren kann ;) Wie und wo schaltet ich das interene Routing aus ? Routing schaltet man nie aus, das ist Quark. Ohne Routing läuft gar nichts. Der Weg ist wahrscheinlich nicht korrekt konfiguriert. Es ist recht egal, wenn man über irgendeinen Client in LAN1 -> WAN 1 -> WAN 2 IP -> wieder rein -> LAN 2 -> irgendein Host aufrufen will. Das geht. Aber die Kette muss saubere Outbound NAT auf WAN1 nutzen (damit die interne IP maskiert wird mit WAN1 IP) und dann kann die auch via WAN2 wieder rein in LAN2 rutschen ohne Problem weil der Client dann denkt, die Anfrage kommt von draußen. Wie aber oben gesagt: aus Routing Sicht macht das keinen Sinn und sowas würde man versuchen zu vermeiden um direkt zu routen um sich die ganzen Lags und Latenzen und Bandbreitenprobleme der WANs/routing loops zu sparen. Cheers

@bob-dig @NOCling war es unklar bzw. er meinte es andersrum, aber PF arbeitet in seinem File entsprechend top-down: Aliase Tabellen NAT (Forwards); BiNAT, Outbound Rules Floating Gruppen Interfaces der Reihe nach ab. Und ja auch Aliase und Tabellen sind Entities, die im Regelwerk ne Rolle spielen. Wären die nicht zuerst eingelesen, könntet ihr sie nicht in NAT oder Regeln verwenden, daher sind sie mit aufgelistet. Und für die generelle Info ist die Party nie vorbei :P