8
PfSense Firewallregel anderes Gateway Verständnisfrage
Hallo zusammen,
ich habe eine pfSense, an der hängt WAN-Seitig direkt der ONT der Deutschen Glasfaser und da es noch den Telekom-Anschluss mit 2 Mbit gibt, hängt WAN 2 über eine FritzBox in einer Kaskade.
Im Routing sind Beide Gateways hinterlegt.
Nun bekommen ja alle das Standardgateway mitgegeben.
Da jetzt jedoch seit gestern Abend eine größere Störung im Glasfasernetz vorliegt, wollte ich nun einzelne Clients temporär über die Telekom rausschicken.
Also habe ich eine Alias Any Regel im entsprechenden LAN erstellt und dieser Regel als Gateway die Telekom zugewiesen.
Im Alias sind dann vereinzelte IPs, denen ich den Schwenk erlauben wollte.
Die Regel über die Any Any gezogen, und gespeichert.
Normal müsste doch, weil first Match wins, entsprechende IP über das Telekomnetz rausgehen, oder?
Irgendwie wollte das nicht so recht fliegen, ich hatte aber auch nicht ewig Zeit das zu verfolgen und habe es dann erstmal so belassen.
Ist mein Gedankengang richtig?
ich habe eine pfSense, an der hängt WAN-Seitig direkt der ONT der Deutschen Glasfaser und da es noch den Telekom-Anschluss mit 2 Mbit gibt, hängt WAN 2 über eine FritzBox in einer Kaskade.
Im Routing sind Beide Gateways hinterlegt.
Nun bekommen ja alle das Standardgateway mitgegeben.
Da jetzt jedoch seit gestern Abend eine größere Störung im Glasfasernetz vorliegt, wollte ich nun einzelne Clients temporär über die Telekom rausschicken.
Also habe ich eine Alias Any Regel im entsprechenden LAN erstellt und dieser Regel als Gateway die Telekom zugewiesen.
Im Alias sind dann vereinzelte IPs, denen ich den Schwenk erlauben wollte.
Die Regel über die Any Any gezogen, und gespeichert.
Normal müsste doch, weil first Match wins, entsprechende IP über das Telekomnetz rausgehen, oder?
Irgendwie wollte das nicht so recht fliegen, ich hatte aber auch nicht ewig Zeit das zu verfolgen und habe es dann erstmal so belassen.
Ist mein Gedankengang richtig?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8112017023
Url: https://administrator.de/contentid/8112017023
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
8 Kommentare
Neuester Kommentar
Mahlzeit.
Da die Telekom WAN Leitung in einer Kaskade hängt, werden hier statische Routen von deinem, normalerweise am Glasfaser Anschluss hängenden Subnetz, in das Transfer Netz der Kaskade fehlen. Dann sollte das genau so gehen.
Auch die Floating Rules kontrollieren.
Der WAN Zugriff aus dem Subnetz, welches direkt in der Kaskade liegt klappt aber?
Gruß
Marc
Da die Telekom WAN Leitung in einer Kaskade hängt, werden hier statische Routen von deinem, normalerweise am Glasfaser Anschluss hängenden Subnetz, in das Transfer Netz der Kaskade fehlen. Dann sollte das genau so gehen.
Auch die Floating Rules kontrollieren.
Der WAN Zugriff aus dem Subnetz, welches direkt in der Kaskade liegt klappt aber?
Gruß
Marc
Moin,
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
Gruß
Spirit
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
Gruß
Spirit
Zitat von @Spirit-of-Eli:
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
Die Sense ist ja ohne Speedport unterwegs, was Glasfaser anbelangt und direkt am ONT (ist bei mir daheim ebenfalls so).
Daher ist die Fritzbox hier anzupacken.
Ggruß
Marc
Zitat von @radiogugu:
Die Sense ist ja ohne Speedport unterwegs, was Glasfaser anbelangt und direkt am ONT (ist bei mir daheim ebenfalls so).
Daher ist die Fritzbox hier anzupacken.
Ggruß
Marc
Zitat von @Spirit-of-Eli:
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
solltest du einen neueren Speedport an dem Telekom Anschluss betreiben wird das mit den Routen schwierig. Die lassen sich nicht konfigurieren (auch nicht über das Entwickler Menü). Ich habe das Problem auch hier.
Da hilft dann nur NAT über das Interface zu fahren.
Bei einem alten Speedport kein Thema mit Routen wie schon erwähnt wurde.
Die Sense ist ja ohne Speedport unterwegs, was Glasfaser anbelangt und direkt am ONT (ist bei mir daheim ebenfalls so).
Daher ist die Fritzbox hier anzupacken.
Ggruß
Marc
Okay, die Fritzbox habe ich über lesen. Da lassen sich die Routen eintragen.
Solange der TO keine Klarheit schafft ob NAT oder nicht und wie bei seinem Dual WAN Design die Routing Policies mit den beiden Routen definiert sind ist das Kristallkugeln im freien Fall. 
Auch was genau mit „Im Routing sind beide Gateways hinterlegt“ jetzt genau bedeutet bleibt unklar. Zumindestens für ein Gateway ist das vermutlich gelogen denn die DG Route wird ja dynamisch gelernt. Die Telekom Route müsste wegen der Kaskade statisch angelegt werden.
Ohne wirklich hilfreiche Angaben zum Setup ist das alles Raterei im freien Fall.
Grundlagen Setups für so ein Design wie immer
https://www.heise.de/select/ct/2016/24/1479992026108405
https://docs.netgate.com/pfsense/en/latest/multiwan/index.html
Auch was genau mit „Im Routing sind beide Gateways hinterlegt“ jetzt genau bedeutet bleibt unklar. Zumindestens für ein Gateway ist das vermutlich gelogen denn die DG Route wird ja dynamisch gelernt. Die Telekom Route müsste wegen der Kaskade statisch angelegt werden.
Ohne wirklich hilfreiche Angaben zum Setup ist das alles Raterei im freien Fall.
Grundlagen Setups für so ein Design wie immer
https://www.heise.de/select/ct/2016/24/1479992026108405
https://docs.netgate.com/pfsense/en/latest/multiwan/index.html
Hmmm
Dann hatte ich bisher einen Denkfehler
WAN 1, auch Standard Gateway hängt direkt an der Glasfaser am ONT. Das Interface ist somit mit DHCP konfiguriert.
WAN 2 ist eine alte Fritte die Telefon macht.
192.168.101.1
Von dort halt an das Interface von WAN 2, dieses statisch auf 192.168.101.10/24 eingestellt.
Gateway ist auf die 1
Nun dachte ich, man könne ganz banal vom LAN Interface über der Any Any Regel, welche ja auf WAN 1 standardmäßig zeigt, temporär eine zusätzliche Regel definieren.
Source der Alias mit bestimmten IPs, der Rest Any. Unten in der Regel ist das WAN 2 Gateway IPv4 eingetragen.
Nun dachte ich das fliegt Out of the Box.
Bei meiner Freundin habe ich auch eine Fritzbox Kaskade, wo die pfsense wie bei mir als Exposed Host definiert ist und bis auf die Nintendo Switch läuft das. Die Switch benötigt Outbound Nat.
So dachte ich das mit dem einen Gateway.
Bei 2 Mbit wollte ich da nicht alles drüber prügeln.
Sonst befasse ich mich da die Tage noch mal mit
Dann hatte ich bisher einen Denkfehler
WAN 1, auch Standard Gateway hängt direkt an der Glasfaser am ONT. Das Interface ist somit mit DHCP konfiguriert.
WAN 2 ist eine alte Fritte die Telefon macht.
192.168.101.1
Von dort halt an das Interface von WAN 2, dieses statisch auf 192.168.101.10/24 eingestellt.
Gateway ist auf die 1
Nun dachte ich, man könne ganz banal vom LAN Interface über der Any Any Regel, welche ja auf WAN 1 standardmäßig zeigt, temporär eine zusätzliche Regel definieren.
Source der Alias mit bestimmten IPs, der Rest Any. Unten in der Regel ist das WAN 2 Gateway IPv4 eingetragen.
Nun dachte ich das fliegt Out of the Box.
Bei meiner Freundin habe ich auch eine Fritzbox Kaskade, wo die pfsense wie bei mir als Exposed Host definiert ist und bis auf die Nintendo Switch läuft das. Die Switch benötigt Outbound Nat.
So dachte ich das mit dem einen Gateway.
Bei 2 Mbit wollte ich da nicht alles drüber prügeln.
Sonst befasse ich mich da die Tage noch mal mit
Wie immer: nicht denken sondern nachdenken! 
Du hast ja 2 Default Gateways (Provider) mit diesem Setup. Irgendwie musst du dem Router bzw. der Firewall ja nun sagen WIE sie wann welches Gateway verwenden soll. Wie sollte die Firewall sonst entscheiden welcher Traffic zu welchem Provider soll?? Raten oder Admin Gedanken lesen kann sie ja (noch) nicht!
Nur mit einem Filter Regelwerk wäre das unsinnig und kann logischerweise nicht funktionieren, denn das kann ja keine Forwarding bzw. Routing Entscheidung treffen. Bekanntlich ja auch eine ganz andere Baustelle...
Wenn du nix machst und 2 von der Metrik gleiche Default Gateways hast ohne eine Routing Regel, macht der Router bzw. Firewall ein Round Robin. Heisst er routet eine Session zu Provider 1, die nächste zu Provider 2, die nächste zu Provider 1 usw. usw. Was sollte er auch auch sonst machen ohne eine Anweisung von dir als Administrator?!
Mit einem Forwarding Regelwerk (Policy Routing) kannst du aber nun granular bestimmen WAS du machen willst.
Z.B. kannst du Gateway 1 als primäres Gateway definieren und Gateway 2 nur dann aktivieren wenn Gateway 1 ausgefallen ist. Ein reines Failover Szenario also.
Du kannst balancen, also z.B. 80% Traffic auf den Glasfaseranschluss senden und 20% auf den DSL Anschluss. So nutzt du aktiv beide Links mit einer Lastverteilung für die du ja teuer bezahlst auch mit gegenseitigem Backup.
Du kannst Traffic nach Diensten oder IP Adressen trennen. Z.B. TCP Port 25 Traffic (Email) nur über DSL senden usw. usw.
All das definiert man mit dem Forwarding Regelwerk eines Dual WAN Anschlusses je nachdem WIE man diese beiden Provider Links bedienen will..oder nicht.
Nichts dergleichen hast du aber gemacht sondern laienhaft gedacht das eine simple Filterregel das realisiert, die aber damit gar nichts zu tun hat weil sie natürlich das Forwarding der Firewall gar nicht beeinflusst bzw. bei simplem Round Robin Routing belässt sofern beide Gateway Links identische Metriken haben.
Soviel zum Thema Denken und Nachdenken!
Du hast ja 2 Default Gateways (Provider) mit diesem Setup. Irgendwie musst du dem Router bzw. der Firewall ja nun sagen WIE sie wann welches Gateway verwenden soll. Wie sollte die Firewall sonst entscheiden welcher Traffic zu welchem Provider soll?? Raten oder Admin Gedanken lesen kann sie ja (noch) nicht!
Nur mit einem Filter Regelwerk wäre das unsinnig und kann logischerweise nicht funktionieren, denn das kann ja keine Forwarding bzw. Routing Entscheidung treffen. Bekanntlich ja auch eine ganz andere Baustelle...
Wenn du nix machst und 2 von der Metrik gleiche Default Gateways hast ohne eine Routing Regel, macht der Router bzw. Firewall ein Round Robin. Heisst er routet eine Session zu Provider 1, die nächste zu Provider 2, die nächste zu Provider 1 usw. usw. Was sollte er auch auch sonst machen ohne eine Anweisung von dir als Administrator?!
Mit einem Forwarding Regelwerk (Policy Routing) kannst du aber nun granular bestimmen WAS du machen willst.
Z.B. kannst du Gateway 1 als primäres Gateway definieren und Gateway 2 nur dann aktivieren wenn Gateway 1 ausgefallen ist. Ein reines Failover Szenario also.
Du kannst balancen, also z.B. 80% Traffic auf den Glasfaseranschluss senden und 20% auf den DSL Anschluss. So nutzt du aktiv beide Links mit einer Lastverteilung für die du ja teuer bezahlst auch mit gegenseitigem Backup.
Du kannst Traffic nach Diensten oder IP Adressen trennen. Z.B. TCP Port 25 Traffic (Email) nur über DSL senden usw. usw.
All das definiert man mit dem Forwarding Regelwerk eines Dual WAN Anschlusses je nachdem WIE man diese beiden Provider Links bedienen will..oder nicht.
Nichts dergleichen hast du aber gemacht sondern laienhaft gedacht das eine simple Filterregel das realisiert, die aber damit gar nichts zu tun hat weil sie natürlich das Forwarding der Firewall gar nicht beeinflusst bzw. bei simplem Round Robin Routing belässt sofern beide Gateway Links identische Metriken haben.
Soviel zum Thema Denken und Nachdenken!
Kommt hier immer wieder, hier auch für Firewall-Noops mit Bildchen beschrieben:
OPNSense: Einzelnes Gerät soll über ein bestimmtes Gateway ins Internet
OpenSense mit 2 WAN und 2 LAN, Gateway festlegen
Ist an der "pF"Sense so gut wie identisch wie bei OPNsense, Vorgehensweise immer gleich.
Gruß siddius
OPNSense: Einzelnes Gerät soll über ein bestimmtes Gateway ins Internet
OpenSense mit 2 WAN und 2 LAN, Gateway festlegen
Ist an der "pF"Sense so gut wie identisch wie bei OPNsense, Vorgehensweise immer gleich.
Gruß siddius
1
