@jegr
Gute Idee, probier ich mal.
Danke!

@viragomann
Danke, werde ich mir Montag einmal anschauen.

Das ist das lokale Netzt hinter der pfSense im RZ.

@bon-go said in Wie konfiguriere ich hinter einem PPPOE ein IPv4er Netz richtig?:

Genau das schreibe ich doch die ganze Zeit, s.o.. Damit wäre bei seinem /30er Netz nur eine IP nutzbar. Wenn nun sein ISP direkt nur die IP des /30 Netzes vergibt ohne Standardgateway für dieses Netz (so wie er es grad eben noch geschrieben hat) dann geht halt darüber nie etwas raus ausser Antworten auf eingehende Pakete von irgendwoher. Ja, auch das ist möglich.

Wenn der ISP aber wie schon mehrfach von ihm geschrieben ein /30 delegiert hat - also routet - dann ist da nix Gateway drin, sondern das komplette /30 mit zwei Adressen weitergeroutet auf die Adresse, die die Sende bei PPPoE Einwahl eh bekommt. Standard Routing und gut.

@filontheroad said in Wie konfiguriere ich hinter einem PPPOE ein IPv4er Netz richtig?:

Meine anderen Vlan Clients kriegen aus allen anderen VLAN Netzten auch eine IP durch ihren DHCP Server ;-) nur bei diesem war es nicht der Fall und da bin ich noch am recherchieren wieso.

Kannst du dazu bitte nochmal aufdröseln, ggf. mit Screenshots, was du wo wie warum konfiguriert hattest und was dann ging und was nicht?

Ansonsten verstehe ich beim Drüberlesen gerade nicht , wo du da wie ein VLAN im Spiel hast und welche Adressen da vergeben oder nicht vergeben werden :)

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!