Pfsense mit mehreren WAN´s /öffentlichen Ip´s - wie ausgehende "route" definieren
-
Hallo zusammen
ich habe eine Frage zum Port Forwarding.
In einem System mit 1 WAN und 1 öffentlichen Ip nutzen alle Clients/Server auf Lan das eine Gateway um "raus" zu kommen - soweit so gut.
Wenn ich nun ein System mit mehreren WAN Interfaces und unterschiedlichen öffentlichen IP´s habe und z.b: ein Port Forwarding für WEB (80/443) von der IP auf WAN2 auf Client 192.168.0.20 mache dann klappt das soweit auch.
Der Client wiederum nutzt aber das Standard Gateway von LAN das wäre dann WAN1 um ausgehende zu kommunizieren.
Wie erreiche ich denn dass der Client der das Port Forwarding von WAN2 bekommt auch über WAN2 "raus" geht ?
-
@gtrdriver
Alles, was nicht über das Standardgateway raus gehen soll, kannst du nur über Policy Routing machen.
D.h. eine Firewall-Regel für die ausgehende Verbindung definieren bzw. eine bereits vorhandene editieren und und in den Advanced Options das gewünschte Gateway auswählen, über das die Verbindung ins Internet gehen soll.Fallstrick dabei:
Eine Policy Routing Regel (eine mit Gateway) sendet allen Traffic, auf den sie zutrifft, zu dem gesetzten Gateway. Damit ist mit einer solchen Regel kein Zugriff auf interne IPs möglich.
D.h. du musst dafür Sorge tragen, dass die Regel ausschließlich für Traffic mit Zieladressen im Internet zutrifft, oder alternativ eine zusätzliche Regel, die ausschließlich auf interne Zieladressen zutrifft darüber setzen.
Am besten geht das mit einem RFC 1918 Alias, also der sämtliche private IP-Adressräume einschließt. -
@gtrdriver said in Pfsense mit mehreren WAN´s /öffentlichen Ip´s - wie ausgehende "route" definieren:
Wie erreiche ich denn dass der Client der das Port Forwarding von WAN2 bekommt auch über WAN2 "raus" geht ?
Das muss an der Stelle gar nicht erreicht werden, wenn damit gemeint ist, wie man den Antwort Traffic auf WAN2 bekommt. Wenn es um WAN2 generell geht - also Client X soll immer via WAN2 raus, dann geht das genau wie @viragomann schreibt nur mit PBRs.
Wenn das WAN2 Interface aber sauber als WAN eingerichtet wurde (e.g. im Interface Setting von WAN2 ist ein Upstream GW hinterlegt wie bei WAN1 aber NICHT bei LAN Interfaces!), dann sorgt pfSense selbst dafür, dass Traffic der via WAN2 reinkommt an Client X geht und wieder über WAN2 beantwortet wird. Das klappt völlig autonom, weil in den pf Regeln entsprechende Einstellungen genau das bewirken.
Cheers
-
Hallo zusammen
danke für die Anregungen - ich habe das im 1. Reply beschriebene angewandt und das läuft nun problemlos.
Das von dir beschriebene Szenario trifft aber nur dann zu wenn Wan 2 auf ein anderes LAn (z.b: lan2) gemappt wird oder sehe ich das falsch ?
Per default kann es ja in einem Lan nur 1 standard GW geben - richtig ?
-
@gtrdriver said in Pfsense mit mehreren WAN´s /öffentlichen Ip´s - wie ausgehende "route" definieren:
Per default kann es ja in einem Lan nur 1 standard GW geben - richtig ?
In meiner Antwort gings nicht um das Default GW
@gtrdriver said in Pfsense mit mehreren WAN´s /öffentlichen Ip´s - wie ausgehende "route" definieren:
Das von dir beschriebene Szenario trifft aber nur dann zu wenn Wan 2 auf ein anderes LAn (z.b: lan2) gemappt wird oder sehe ich das falsch ?
Nein, es geht darum dass
a) WAN interfaces korrekt konfiguriert werden müssen (aka Upstream Gateway im Interface hinterlegt, LAN Interfaces bekommen hier NIE ein Gateway konfiguriert)
b) Dass pfSense dann selbständig auf allen WAN-style Interfaces sich darum kümmert, dass Traffic der auf WAN-X REINkommt auch dort wieder RAUS geht wo er hergekommen ist, um Probleme mit asymmetrischem Routing zu vermeiden.Da muss nichts konfiguriert werden, da kümmert sich die Sense selbst mit entsprechenden reply-to keywords drum.
Cheers
-
Danke für die Ausführungen - wieder was gelernt - probiere ich aus.
-
jetzt muss ich hier aber nochmals ansetzten denn so ganz habe ich Punkt B nicht verstanden....
Dass Traffic der auf WAN B rein kommt auch wieder über WAN B rausgeht ist soweit verstanden...
Aber was ist mit Traffic der "nur raus geht" - also der Client im LAN möchte ohne dass er angerufen werde raus telefonieren - dann weiß er doch aber (sofern er in einem LAN hängt an dem mehrere externe IP´s hängen) nicht über welches er raus gehen soll
Sorry - für die evtl dumme frage - aber hier müsste ich doch entweder das LAN trennen (mittels VLAN z.b:) und LAN2 nur an VLANx hängen an dem dann LAN2 hängt - dann ist klar dass der Client NUR über dieses GW raus geht - ansonsten würde er doch immer das Standard GW nutzen.
-
Na das legst du doch fest, ob beide WANs gleichberechtigt sind und round robin für outbound verwendet werden, dann aber bitte stelle die stickiness sauber ein, so das eine Sitzung zu einer Seite immer konstant auf dem jeweiligem WAN fest hängt.
System / Advanced / Miscalleneous / Load Balancing
Denn sonst fliegen dir ständig die Sitzungen bei Portaln/Banke usw. um die Ohren, ich meine damit mit jedem Klick bist du wieder in der Neuanmeldung!
Active/Backup ist halt das einfachste, bei Active/Active wird es halt komplexer und du musst schon genau wissen was das alles für Seiteneffekte mit sich bringt.
Mehrere WANs zu haben ist ja nett, aber damit das wirklich komplett Sinn ergibt sind auch viele Bedingungen zu erfüllen.
Verschiedene Wegeführungen, verschiedene Knotenpunkte auf denen die Verbindung dann aufliegt.
Sprich einmal DSL über Tkom und dann Cabel über Voda sind ein guter Ansatz.
Aber in deiner Straße laufen die nicht selten zusammen im gleichen Tiefbauabschnitt und wenn da einer reinhackt ist beides dunkel.Ansonsten kannst du auch hier für einzelne Clients mit PBR arbeiten und diesem Client über eine Floating out Regel ein festes GW mit geben.
Dann ist der Client aber ohne Inet wenn das jeweilige WAN ausfällt, da gibts dann nix mit Failover, weil du das ja hart festgesetzt hast.
Ist zum teil gewünscht, dann ok aber bitte dann nicht wundern warum hier immer wieder Ausfälle der Intverbindung bei Client x auftreten.Eine Statefull Firewall führt ja eine State Tabelle und da steht drin, IP x mit Port y geht zu Ziel z mit Port b raus.
Dann ist damit die Antwort von IP z und dem Port b erlaubt, wenn diese auf die WAN IP der pfSense gerichtet ist, geift hier die Statfullness Rückregel und es wird statt der WAN Ip der pfSense dann die IP x eingesetzt und das ganze weitergeleitet.Ist diese Bedingung nicht erfüllt, weil statt WAN 1 jetzt die IP von WAN 2 drin stehen würde in der Antwort, gibts hier keinen Eintrag in der State Tabel von WAN 2 und damit drop, das wars mit den Daten.
Daher 1 Regel bei einer Firewall, Hin und Rückweg müssen immer über die gleichen HOPs gehen, also symmetrisch sein.Daher setzt man für eine Firewall auch immer ein Transfernetz ein, will man mehrere Netze hinter einem internen Routing Device wie einem Core Switch verteilen.
Sonst hast du hier wieder ganz schnell Asym. Routing und musst mit no ip icmp redirect usw. das ganze hart unterbinden.
Wenn deine L3 Kisten dass dann nicht können bist halt gekniffen.Also baut man so einen asym. Scheiß gar nicht erst auf, dann muss man
a) keine Fehler suchen
b) ein ruhiges Leben als Netzwerk / FW Admin
c) sich an die wie man macht man es richtig Direktive gehalten!
d) Niemand hängt nen Zettel dran "Kannst so machen, wird halt Kacke!" -
@gtrdriver said in Pfsense mit mehreren WAN´s /öffentlichen Ip´s - wie ausgehende "route" definieren:
Aber was ist mit Traffic der "nur raus geht" - also der Client im LAN möchte ohne dass er angerufen werde raus telefonieren - dann weiß er doch aber (sofern er in einem LAN hängt an dem mehrere externe IP´s hängen) nicht über welches er raus gehen soll
Telefonie ist zusätzlich nochmal ein ganz anderes Thema weil hier sehr oft andere Punkte noch mit reinspielen:
- VoIP ist sehr oft Line-gebunden weil bspw. Telekom keine VoIP Anfragen via anderer Leitung annimmt, sondern nur aus dem gleichen Netz
- VoIP nicht einfach "so raustelefoniert", sondern es eine SIP Anmeldung gibt und dann logisch auch der Anruf über die gleiche Line wie der Login laufen muss
etc .etc.
Das ist ein extrem unpraktisches Beispiel, denn gerade bei SIP/VoIP gibt es oft kein Möglichkeit da ein Failover zu bauen aus den Restriktionen und Eigenheiten des Protokolls.
Wenns um Surfen o.ä. geht also die Verbindung von innen aufgebaut wird und es keine policy-based rules gibt, die irgendetwas anderes sagen, wird die Verbindung immer über das Default GW aufgebaut. Man kann aber als Default GW auch ein Failover GW (KEIN! Loadbalancing GW) hinterlegen, dann wird ein Fall wie "Line 1 down" eben problemlos abgefangen ohne dass man PBR rulesets bauen muss.
Wenn man ein (V)LAN spezifisch auf ein LAN mappen will, dann packt man hier beim entsprechenden LAN die Regeln mit definiertem Gateway rein und schon läuft auch ausgehend alles über bspw. WAN2. Wenn man das wirklich hart trennen möchte, passt man entsprechend die outbound NAT auf manuell an, damit dann gar keine Verbindung über WAN1 läuft.
Das ist aber alles eine Definitionsfrage, was genau wie laufen soll.
Cheers
