Ohne Überwachungsaktion wird ein Gateway auch nicht rausgenommen oder abgeschaltet. Dann kann im Normalfall die GW Gruppe nicht wirklich greifen. Wo sind die GWs denn überhaupt eingestellt und verbaut? Wie sehen die NAT Regeln und Firewall Rules aus? Werden die Anschlüsse jetzt immer noch "vertauscht" (was technisch eig. gar nicht geht)? Etc etc.

@viragomann said in Komisches verhalten bei Zugriff:

intra-BSS

kaum machts man richtig gehts auch,
vielen Dank ! Ich ging davon aus das das Standard ist und kam nicht auf die Idee danach zu suchen .. super, dann bin ich schon mal ein Schritt weiter

@sohei said in Internet Zugang für Amazon Kindle blockieren:

Alternativ statt nur DNS erlauben zu "LAN Address" eben alle Ports erlauben, dann kannst du vom Kindle Tablet auch noch die Sense UI aufrufen oder auch NTP machen statt nur DNS. Und wenn man mal ggf. mit HAproxy spielt, klappt auch das. :)

Das problem daran ist, dass der Kindle nicht nur auf den NextCloud Server zugreifen muss, sondern auch auf andere "Server" und "Dienste" welche (derzeit) alle im LAN Segment stehen. Das würde bedeuten, dass ich für jeden Dienst eine Regel erstellen müsste. Da diese ganze Konfiguration noch maximal dieses Jahr halten muss, ist mir diese Quick-and-Dirty Lösung ganz recht. Wenn wir dann im neuen Haus sind, wird sowieso richtig umgebaut und alle Server in eine DMZ verschoben.

Wie weiter oben schon mehrfach erwähnt: wenn der Kindle und 'die ganzen anderen Geräte im gleichen LAN' letzten Endes an einem Switch vor bzw. hinter der pfSense hängen dann sieht die pfSense das (an ihrem LAN) nicht und man braucht auch keine separaten Firewallregeln dafür. Das ist unnütz. Die Geräte reden über den Switch direkt miteinander.

Die Firewallregeln für den Kindle sind nur dazu da:

um DNS, DHCP und NTP der pfSense zu nutzen den gesamten restlichen Traffic zur pfSense und ausserhalb des LAN (eben auch den kompletten Internetverkehr) zu blockieren

@bob-dig Wenn ihr Lust auf Experimente habt: Habe aktuell den 2.5er snapshot am Laufen. Der hatte auf einem DHCP konfigurieren Interface mit nackter Konfig (also OOTB) sofort IPv4 UND IPv6 am WAN ... UND sofort auch tracking auf dem default LAN aktiv. Einfach mal hinter ne FB 3490 gehängt und instant alles korrekt drin. Sieht sehr gut aus :)

@thepocky said in pfSense hinter FritzBox 6591 mit mehreren Public-IPs und 1:1 NAT:

Aber ist das eine finale Lösung? Ich bin da skeptisch. Bin froh dass es wieder funktioniert, aber noch nicht ganz zu Frieden.

Kann ich verstehen. Hört sich eher nach verdammt krudem Hack seitens Kabelbetreiber und AVM an, damit sie ums Verrecken den Bridge Modus nicht wieder enablen müssen, den sie bereits mit der alten Box schon aktiv hatten und jetzt absichtlich wieder gesperrt haben, obwohl er problemlos funktioniert hatte. Der Grund wird der sein, dass die Leute das ausnutzen konnten um mehrere IPs zu bekommen und wenn man plötzlich 3 IPs pro Anschluß zusätzlich aktiv hatte, fällt einem die IP Knappheit nur umso mehr auf. Wie "unangenehm"...

Ich habe selbst eine 6591 aber noch bevor Vodafone das Szepter übernommen hat von Unitymedia. Dort wurde plötzlich mit dem v6.xx OS der Bridge Modus aktiv und seither (7.13) ist er an geblieben. Toi toi toi.
Würde mich jetzt nicht sonderlich treffen, da kein Business Anschluß und nur eine IP, aber wäre trotzdem ärgerlich.
a143f515-a743-4171-806f-76edd33ed51f-image.png

Dass es also das Feature nicht mehr gibt, ist schlicht gelogen, sie wollen es nur nicht mehr rausrücken, denn wie du schon festgestellt hast, hat die Fritze selbst im Bridge Modus selbst noch eine IP und ein Prefix. Für jedes LAN das ich bridge wählt sich das Gerät dann zusätzlich bei VF ein und holt sich eine IPv4/IPv6 Prefix. Damit kann man sich dann lustig (zwar dynamisch aber trotzdem) 4 verschiedene IPs ziehen. Und das wollen sie natürlich um jeden Preis vermeiden.

Grüße

@bosco Nochmal die Frage: Die Screenshots sind aus dem Backend? Vom blog Backend? Dann haben da wie gesagt die anderen ACLs nichts drin zu suchen weil die da durch die Frontend Zuweisung eh nie ankommen würden?

Im Frontend wird boscolab.de ohne irgendwas auch auf das Blog Backend geschickt? Oder woanders hin?

Nochmal zum Verständnis:

dein Frontend(!) weist eine ACL via Host match zu. Diese ACL wird dann in der Aktion (immer noch im Frontend) selektiert und wählt dann nach deiner Angabe ein BACKend aus. In diesem Backend kommen dann auch NUR Zugriffe an, die vorher schon durch die Selektion auch dahin geschickt werden. Darum schreibe ich die ganze Zeit dass deine ACLs und Actions im BACKend für alles was NICHT in dieses Backend gehört sinnfrei sind, weil sie eh nie ausgeführt werden!

Also würde ich erstmal die Backends soweit bereinigen, dass da nur drinsteht was da auch sein muss und dann nochmal im Frontend die Zuweisung von boscolab.de checken, ob das auch definitiv auf das blog backend geschickt wird und dort ankommt. Dann sollte der Redirect auch greifen. :)

@christoph-strauch said in IPSec Routing Problem:

Weiterhin haben wir eine statische Route angelegt auf den C Router über das LAN interface.

Nochmals nachgefragt weil die Frage von @viragomann nicht beantwortet wurde:

Falls die Firewall von B nicht das Default Gateway auf dem C-Router ist, braucht es natürlich auch noch eine statische Route für das Netz hinter A, die auch B zeigt.

@christoph-strauch du hast nur was geschrieben davon, dass ihr auf der Firewall von B eine Route AUF C erstellt habt. Aber was ist mit dem Router C? Hat DER denn die Firewall von B als Default GW?

Das ist ja leicht festzustellen: Wenn wie du schreibst Traffic AN das Netz C auf Firewall B zu sehen ist auf dem ENC0 Interface ANkommend (erster Check) und dann auch auf dem LAN Richtung Router C ABgehend (zweiter Check mit capture) - wenn also der komplette Hinweg bis zum Router C sicher steht und du einen Ping oder bspw. ein HTTP(S) hinschickst und es kommt NICHTS zurück, dann ist das ziemlich sicher der Router C der Murks macht.

Entweder:

Hat Router C NICHT Firewall B als Default GW und sendet daher nichts für IPs aus Range A zurück an B Oder C hat einen Filter drin, dass nichts, was nicht Netz B ist rein darf (damit blockt er alles aus A) Oder Router C hat ggf. intern noch andere Netze/Routings und der Adressbereich von A wird deshalb von C wo ganz anders hingeroutet

Die Möglichkeiten bei sowas sind vielfältig :) Da musst du genau hinsehen.
Ansonsten könnte man noch versuchen ein "Outbound NAT" auf Firewall B zu bauen, was Pakete von Netz A (via VPN Tunnel) empfangen ABgehend auf dem LAN zu C dann auf die Interface Adresse von Firewall B umschreibt. Damit wäre eigentlich dann Routing/Firewall mäßig wenig Grund da, warum Router C die Pakete ablehnen sollte, aber schön ists natürlich nicht so ganz, weil die Geräte in C dann nicht mehr sehen wo der Kram herkommt.

BTW: bei sowas hier wäre ein ordentlicher Netzplan unglaublich hilfreich ;)

@noplan said in NemsLinux SNMP und pfSense:

muss man halt nur wiede rmal eine mysql und eine ubuntu maschine aufstellen

Wofür? Wegen Icinga?

@noplan said in NemsLinux SNMP und pfSense:

erfüllt das ganze ?

Joa, also für NRPE oder dein Nagios Core Gedöngels geht das NRPE Plugin. Icinga kann damit auch, läuft aber IMHO besser mit dem eigenen Agent. Den gibts allerdings leider bis dato nicht packetiert für pfSense - müsste man vielleicht mal in Angriff nehmen oder anfragen. Man kann aber entweder den NRPE einfach nehmen oder statt dessen händisch den Icinga Agent via PKG installieren und konfigurieren. Mit Filer & Shellcmd Packages sollte sich das ganz gut verkraften lassen :)

@richie1985 Nö das sieht OK aus. Das igb0/Sync wird wohl direkt verkabelt sein, daher der Hotplug Event mit dem UpDown-Girl ;) Ansonsten sieht man da leider bezogen auf CARP nicht viel.

@mickman99 Sorry mal wieder die späte Rückmeldung. Habe jetzt Urlaub und kann mich dem Thema wieder expliziter widmen.

Tatsächlich wird der Präfix einwandfrei auf die Interfaces verteilt und stimmen auch mit dem Präfix mit dem der FRITZ!Box überein. Laut Log der FRITZ!Box wird das verteilte Netz an das LAN Interface auch erkannt und als Exposed Host freigegeben.

Ich vertraue allerdings der Firewall der FRITZ!Box nicht so ganz. Ich richte parallel bei einem Nachbar einen OpenVPN Server über IPv6 ein. Auch dort wird der eingehender Verkehr trotz Exposed Host (natürlich nur zum Test so freigegeben) rejected. Sinn macht das nicht.

Zusätzlich ist bei meiner pfsense das Problem aufgetreten, wenn viele Daten auf einmal verarbeitet werden müssen, dass der interne DNS Server abschmiert. Da habe ich auch die Vermutung, dass es an der FRITZ!Box liegt. Der Log der Fritte verrät da allerdings nicht so viel...

@viragomann

Vielen Dank! Das war natürlich der korrekte Tipp :-)

Habe mir ein Alias gebaut der die IPs beinhaltet die auf den VPN zugreifen sollen.

Sieht jetzt so aus und funktioniert:

fc1174e2-453a-4e5b-bb9e-3af38a577d33-image.png

@nowa-it Das gleiche Verhalten konnte ich auch so nachstellen.

Die Einstellung TCPmssFix ist Standardmäßig aktiviert und scheint schon was damit zu tun zu haben. Nur leider wirkt sich das nur auf IPv4 aus und nicht auf IPv6. Dort wird das entweder ignoriert, oder ein falscher Wert wird ausgewürfelt.

@kira12 Das Problem dürfte da eher das fehlende/mangelnde Verständnis sein, von denjenigen, die diese vermeintlichen "HowTos" schreiben und propagieren. Das reicht von "works for me" über "sie wissen es nicht besser" bis zu "mir egal, ich mach das Video eh nur für Klicks" Howtos, daher ist es in der Masse eher schwierig zu wissen, ob etwas wirklich sinnvoll/gut ist oder nicht.

Daher würde ich an der Stelle immer zuerst offizielle Quellen lesen und die neue Doku mit zusammengefügten Inhalten aus dem ehem. Buch und der off. Doku ist dahingehend wirklich gut und erklärt die Grundlagen auch für Themen wie Rule-Processing-Order und Co. Wenn man das im Kopf hat dazu, erklärt es sich von selbst ob/warum manche Regeln weiter oben stehen müssen als andere und warum es - wie in deinem Fall - überhaupt keinen Sinn machen kann.

Wichtig sind lediglich drei Dinge, wenn du policy routing machst (also mit Regeln):

Überlegen, WANN deine Regel zutrifft und ob es alle Fälle trifft, die du so routen möchtest (also ob du dir mit Regeln darüber oder darunter irgendwas abgräbst o.ä.) Das richtige Gateway setzen oder die entsprechende GatewayGruppe Daran denken, dass ein erzwungenes Gateway in einer Regel auch Verkehr DORT hinschickt, der ansonsten mit Gateway * woanders hin laufen würde!

Beispiel für #3: Du hast ein 4-er Konstrukt. WAN, WAN2, DMZ, LAN. Auf dem LAN legst du nun eine Regel an, dass nicht wie bisher any any via * sondern any any via Failover_Gateway_xy geroutet wird. Damit willst du automatisch von WAN auf WAN2 und zurück schwenken wenn WAN mal kaputt gehen sollte. Wenn du sonst aber keine anderen Regeln hast, kommst du jetzt nicht mehr auf deine DMZ Hosts. Warum? Weil vorher mit * alles über die Routing Table geroutet wurde - und da steht natürlich drin: DMZ ist ein lokales Netz, da route ich direkt hin! Jetzt wird alles über WAN oder WAN2 gezwungen. Auch Sachen AN die DMZ die eigentlich lokal wäre.

Wie gehts besser? Entweder man legt generell als sein Default Gateway jetzt nicht mehr WAN oder WAN2 fest sondern direkt eine Failover Gruppe (geht NUR mit Failover! Gruppen, KEINE Loadbalancing Gruppen!). Dann muss man an den Regeln NICHTS ändern, denn "*" steht dann automatisch für "default" und default ist ja WAN bzw. WAN2 je nach Failover Status. Das ist recht neu seit 2.4 und deshalb sprechen viele alte Howtos noch überhaupt nicht davon, dass das heute auch ohne Regeln geht!
Alternativ mit PBR also via Regeln: Man erstellt einfach eine Regel mit Source LANnet und Dest DMZnet (oder einem beliebigen lokalen Alias), das dann wie bisher Traffic einfach mit Gateway * erlaubt. Alles was dann "ins Internet" gehen soll bekommt dann mit einer LANnet to any Regel das Failover oder Loadbalancer Gateway zugewiesen.

Alleine daraus sieht man schon, dass die Howtos mit "Failover Regel ganz nach oben" kompletter Unfug sind, denn praktisch muss diese eher Richtung unten positioniert werden, wenn vorher noch anderer Traffic über bspw. VPNs, interne Netze, VLANs, IPSEC/OVPN Tunnel etc. geroutet werden soll. Daher: lieber informieren oder hier fragen bevor man fragwürdigen 08/15 Howtos folgt, die jemand einfach zusammengeklickt hat.

@kira12 said in MultiWan LoadBalancing und Failover:

z.B. https://forum.netgate.com/topic/58507/multi-wan-dual-and-policy-based-routing-with-failover/3

Alleine was man in dem Thread nachfolgend von bspw. phil liest, ist nochmal genau das was ich beschrieben habe. Die 3 Regeln, die im ersten Topic beschrieben werden einfach blind anzulegen bringt überhaupt nichts bzw. nur etwas, wenn man bisher lediglich vom LAN eine allow any Regel hatte und sonst nichts. Oder auch:

a) You only want 1 rule for each from/to set of addresses - the system will use the first rule it matches, later rules will therefore not be matched/used.

b) The more specific rules must be first in the list, then the specific traffic gets matched and the "other general crud" falls through to match the later general rule.

Man braucht keine 3 Regeln, sondern man wählt für jede Regel aus, ob man diese über ein spezifisches Gateway (LB, Failover, default) schickt oder nicht. Und wie in b) beschrieben, spezifischere Regel bzw. enger gefasste Regeln müssen natürlich on top stehen, sonst würden sie bei einer any any Regel nie abgearbeitet werden. Ansonsten passiert das, was er in https://forum.netgate.com/post/407576 beschreibt. Die Regeln werden gar nicht erst abgearbeitet.

Und zu guter Letzt ist der Beitrag von 2017 und damit lange vor der neuen Default Gateway Switching Methode entstanden. Heute würde das hier problemlos funktionieren OHNE irgendwelche Regeln zu verändern:

failovergw.gif

Einfach ein FO-Gateway anlegen (Tier1 WAN1, Tier2 WAN2 bspw.), dieses als Default Gateway hinterlegen, speichern, fertig. Damit gilt für alle Interfaces und Regeln mit Gateway * automatisch ein Failover 1->2. Ohne Anpassung irgendwelcher Regeln. Wenn man das dann zusätzlich übersteuern möchte um ggf. bestimmten Traffic NUR über 1 oder 2 rauszuschicken oder manchen Traffic dann "Loadbalancen" möchte, kann man das problemlos machen.

Cheers
\Jens

Hi,

deine Hardware scheint mir massiv überdimensioniert. Wenn du das in Betrieb hast wird deine CPU mit 1% Last vor sich herum dümpelt. Wenn du einen anderen Rechner dafür gewinnen kannst wird sich deine Stromrechnung darüber freuen...

Gruß ré

Ich würde hier mal klar Schiff machen.

Sauberes Netzkonzept, pro Standort welches auch ein paar Netze enthält für VLANs.
Dann sauber das VPN (egal auf welcher Bais der Tunnel basieet) mit Routing aufbauen.

Dann brauchst du kein NAT was bei SIP mit oder ohne ALG immer in einem Haufen sch... endet.

Ne Sense kann im SIP rum wählen, ne Fritz ist dafür stumpf zu doof.
Daher hat es vermutlich die ganze Zeit mit den Gurken funktioniert.

Aber im Moment machst du Betrieb durch Zufall!

Certbot oder jeder andere Letsencrypt Client macht mit Domains im "HTTP-1" Modus gar nichts. Er sendet lediglich deinen Ausstellungs-Wunsch zu LetsEncrypt und deren Server greifen via Domainaufruf und HTTP (kein S!) auf die Domain zu, versuchen den .well-known Pfad abzurufen und damit die Domain zu validieren. Done.

Mit Cloudflare als DNS für die eigene Domain geht das nochmal um einige Ecken leichter, weil man statt HTTP die DNS-1 Methode nutzen kann, wenn man die entsprechenden Daten wie API Key, Domain etc. hinterlegt. Dann wird ein TXT Eintrag in der entsprechenden Domain erzeugt (meinedomain.xyz) für den Hostnamen der validiert werden soll, LetsEncrypt testet den DNS (wieder von außen, dein lokaler DNS auf der pfSense ist da völlig irrelevant) und stellt je nachdem ob das klappt das Zert aus oder nicht.
Ebenfalls Done.

Beide Varianten haben nichts(!) mit deinem lokalen DNS und dem Überschreiben mit Host oder Domain Overrides in deiner pfSense zu tun. Der Host oder Domain Override - je nachdem was du brauchst/nutzt - sind lediglich dafür zuständig, dass deine Clients/Server nicht jedes Mal erst auf die externe IP auflösen, auf deiner pfSense rauskommen, da ggf. (wenn aktiviert) via NAT Redirection dann wieder zum Server zurückgespielt werden und insgesamt eben einmal mit dem Paket um den Block fahren, statt direkt ins Haus nebenan zu gehen, zu klingeln und reinzulaufen. Bildlich gesprochen :)

Cheers
\jens

@NOCling @the-other ,

das mit dem VLAN ist ne gut Idee, ich muss mir erstmal den switsch anschauen.
(Ist ein kleiner HP 8 Port Gigabit switch)

Werde mir das auf die todo Liste setzten wenn ich mal wider vor Ort bin.

Wen der VLANs kann werde ich mich ggf. wegen der Konfiguration nochmal melden.

Gruß Peter

ja das ist der plan.

beim import wird der alte (bestehende) alias überschrieben
(zuerst gelöscht dann der neue geschrieben)

jetzt gerade dabei das xml file zu mergen und anschl. zu importieren.

NP

(edit) working .... xml edit und merge inkl restore ... funktioniert ohne reboot .. obwohl er anmerkt ein reboot may be needed

so 1 down 43 to go

[solved]
NP

@viragomann

So ja. :)