PFSense Portforwarding MultiWAN in DMZ
Moin,
bei einem Kunden gibt es eine pfsense welche bestimmte eingehende SSL-Verbindung auf verschiedene EDI-Server in der DMZ mit IP-Filtern routet.
Das Internet besteht hier leider nur aus einer handvoll vDSL-Verbindungen mit 16-25 MBit mit normalen vDSL-Routern. Was anderes wird hier vermutlich so gegen 2079 verfügbarbar werden.
Die Art der Verbindung gibt der Lieferant vor und ist nicht verhandelbar.
Der Lieferant verwendet DSN-Einträge des Kunden mit einer TTL von 60 Sekunden.
Ich kann also relativ schnell von einem Anschluss zu einem anderen wechseln.
Die vDSL-Router leiten alle Ports an die PFSense und je nach Port und Absender IP gibt es in der PFSense einfache Weiterleitungsregeln.
Jetzt gibt es in der PFSense WAN1, WAN2 bis WAN12.
Wenn man eine Portweiterleitung hinzufügt muss man zwingend das Interface, z.B. WAN7 auswählen.
Bei einem Ausfall muss man die betreffenden Weiterleitungen in der PFSense anpassen.
Gibt es eine Möglichkeite eine Portweiterleitung für alle WANs einzurichten?
Die Lösung wird von 2 Personen vor Ort betreut die sich damit auskennen.
Eine Lösung mit einem Server im WAN und Tunnel in die PFSense etc ist nicht gewünscht weil es zu komplex sei.
Die aktuelle Lösung ist einfach nachzuvollziehen.
Stefan
bei einem Kunden gibt es eine pfsense welche bestimmte eingehende SSL-Verbindung auf verschiedene EDI-Server in der DMZ mit IP-Filtern routet.
Das Internet besteht hier leider nur aus einer handvoll vDSL-Verbindungen mit 16-25 MBit mit normalen vDSL-Routern. Was anderes wird hier vermutlich so gegen 2079 verfügbarbar werden.
Die Art der Verbindung gibt der Lieferant vor und ist nicht verhandelbar.
Der Lieferant verwendet DSN-Einträge des Kunden mit einer TTL von 60 Sekunden.
Ich kann also relativ schnell von einem Anschluss zu einem anderen wechseln.
Die vDSL-Router leiten alle Ports an die PFSense und je nach Port und Absender IP gibt es in der PFSense einfache Weiterleitungsregeln.
Jetzt gibt es in der PFSense WAN1, WAN2 bis WAN12.
Wenn man eine Portweiterleitung hinzufügt muss man zwingend das Interface, z.B. WAN7 auswählen.
Bei einem Ausfall muss man die betreffenden Weiterleitungen in der PFSense anpassen.
Gibt es eine Möglichkeite eine Portweiterleitung für alle WANs einzurichten?
Die Lösung wird von 2 Personen vor Ort betreut die sich damit auskennen.
Eine Lösung mit einem Server im WAN und Tunnel in die PFSense etc ist nicht gewünscht weil es zu komplex sei.
Die aktuelle Lösung ist einfach nachzuvollziehen.
Stefan
Please also mark the comments that contributed to the solution of the article
Content-ID: 73091734300
Url: https://administrator.de/contentid/73091734300
Printed on: October 8, 2024 at 00:10 o'clock
32 Comments
Latest comment
SSL was?
Vielleicht ein Reverse Proxy?
Vielleicht ein Reverse Proxy?
Moin,
mir fällt gerade keine andere Option ein als sowas für jedes Interface separat anzulegen.
Das ist da leider eine Schwäche bei der PfSense.
Bei einer Fortinet wäre das allerdings simpel möglich. Dort lässt sich als Source Interface einfach "any" oder ne Zone definieren.
Sollte auch nicht so schwer zu erklären sein.
Gruß
Spirit
mir fällt gerade keine andere Option ein als sowas für jedes Interface separat anzulegen.
Das ist da leider eine Schwäche bei der PfSense.
Bei einer Fortinet wäre das allerdings simpel möglich. Dort lässt sich als Source Interface einfach "any" oder ne Zone definieren.
Sollte auch nicht so schwer zu erklären sein.
Gruß
Spirit
Keine Header, nur IP:Port und IP:Port? Oder wie sehen die Verbindungen aus?
aber 12 WAN x 20 Verbindungen sind 240 Weiterleitungen. Das ist nicht unbedingt übersichtlich
Ich befürchte bei so vielen Leitungen und so vielen Ports du wirst nicht mehr viel Auswahl haben um es übersichtlich zu gestalten.Kann pfSense mehrere Dienste zu einer Gruppe zusammenfügen? Dann brauchst du nur eine Regel (pro WAN) in der alle Dienste / Ports in der Gruppe sind - vorausgesetzt sie gehen alle an den selben internen Zielserver.
Zitat von @aqui:
Kann pfSense mehrere Dienste zu einer Gruppe zusammenfügen?
"Aliases" ist das Zauberwort. Bei den Ports geht das allerdings auch nicht. Genauso wenig wie bei den Interface Konfigurationen. (Bezogen aufs Portforwarding)
Das ist leider ein Manko.
Bei den Ports geht das allerdings auch nicht.
Das ist so aber nicht ganz richtig. Natürlich kann man eine Reihe von TCP oder UDP Ports unter einem Port Alias zusammenfassen. Was dann aber vermutlich nicht geht ist diesen Alias dann in einer Port Forwarding Regel zu verwenden weil diese Port Aliases wohl nur im Regelwerk nutzbar sind?!Zitat von @aqui:
Bei den Ports geht das allerdings auch nicht.
Das ist so aber nicht ganz richtig. Natürlich kann man eine Reihe von TCP oder UDP Ports unter einem Port Alias zusammenfassen. Was dann aber vermutlich nicht geht ist diesen Alias dann in einer Port Forwarding Regel zu verwenden weil diese Port Aliases wohl nur im Regelwerk nutzbar sind?!Darauf wollte ich hiermit hinaus: "(Bezogen aufs Portforwarding)"
In der Maske ist das leider nicht möglich und die Einträge müssen eindeutig sein.
Was theoretisch gehen könnte, wäre irgend was über eine Virtual IP zu bauen. Das ist gerade allerdings Gedankenspinnerei. Die Adresse ließe sich dort jedenfalls bei den Interface Konfigurationen eintragen. Unter Ports bleibt wohl weiter nichts anderes überig als eine klare Definition bzw. Range.
Moin,
Gruß,
Dani
Wenn man eine Portweiterleitung hinzufügt muss man zwingend das Interface, z.B. WAN7 auswählen.
Bei einem Ausfall muss man die betreffenden Weiterleitungen in der PFSense anpassen.
wäre die Nutzung eines DNS Load Balancer wie Azure Traffic Manager denkbar? Richtest für jedes Interface das Portforwarding ein und ATM steuert automatisch auf welcher Leitung die Daten eingehen werden.Bei einem Ausfall muss man die betreffenden Weiterleitungen in der PFSense anpassen.
Gruß,
Dani
Wozu überhaupt doppeltes NAT?? Route doch einfach direkt vom Perimeter aus auf die Station durch statt auf der pfSense nochmal zu DST-NATen. Man setzt dann nur pro Interface ein Routing-Tag per Filter-Regel und eine GW Rule die auf den Tag aufbaut, damit der Traffic wieder über das richtige Interface zurück läuft.
Das mit einer einzelnen Regel klappt auf einer pFSense nicht, denn diese muss ja wissen auf welchem Pfad sie das Paket zurückschicken muss und das klappt nur wenn reply-to richtig gesetzt ist damit Pakete die eingehen auch wieder über das selbe Interface die Sense verlassen.
Die Pakete kommen ja mit einer öffentlichen IP bei der Sense an und nicht mit einer privaten der vorgeschalteten Router, ergo braucht es auf der Sense Tags die die Sessions mit dem passenden Routing-Tag versehen, denn ansonsten würde sie ja ihr primary Default-GW nutzen um das Paket wieder raus zu schicken, und wenn das nicht das Interface war wo es rein gekommen ist knallt es natürlich.
Gruß Katrin
Das mit einer einzelnen Regel klappt auf einer pFSense nicht, denn diese muss ja wissen auf welchem Pfad sie das Paket zurückschicken muss und das klappt nur wenn reply-to richtig gesetzt ist damit Pakete die eingehen auch wieder über das selbe Interface die Sense verlassen.
Die Pakete kommen ja mit einer öffentlichen IP bei der Sense an und nicht mit einer privaten der vorgeschalteten Router, ergo braucht es auf der Sense Tags die die Sessions mit dem passenden Routing-Tag versehen, denn ansonsten würde sie ja ihr primary Default-GW nutzen um das Paket wieder raus zu schicken, und wenn das nicht das Interface war wo es rein gekommen ist knallt es natürlich.
Gruß Katrin
Naja irgendwo musst du sie ja haben wenn du NAT am Perimeter hast.
P.s. es gibt ja auch Skripte die einem das stumpfsinnige Tippeln abnehmen 😉
P.s. es gibt ja auch Skripte die einem das stumpfsinnige Tippeln abnehmen 😉
Alternativ könnte man auch einen Nginx hinstellen oder auf der pfSense installieren und auf diesen von allen FBoxen die Portrange weiterleiten. Auf dem ngnix steht dann die genau Zuordnung der einzelnen Ports, so gibt es die 10 Weiterleitung der FBoxen, und nur einmal die Zuordnung auf dem nginx für die Stationen .
Zitat von @StefanKittel:
Nein. Wie Oben beschrieben ist dies kein http(s)-Traffic sondern SSL-TCP-Data-Streams ohne bekanntes Protokol.
Nginx kann natürlich auch non HTTPS Traffic über TCP/UDP relayen, mache ich hier ja auch! Nein. Wie Oben beschrieben ist dies kein http(s)-Traffic sondern SSL-TCP-Data-Streams ohne bekanntes Protokol.
Beispiel um SSH an einem Nginx von Port 2222 auf 22 nach intern weiterzuleiten
stream {
upstream ssh_group {
server 10.5.1.4:22 max_fails=3 fail_timeout=10s;
}
server {
listen 2222;
listen [::]:2222;
proxy_pass ssh_group;
proxy_connect_timeout 1s;
}
}
Module ngx_stream_core_module
Klappt hier wie Schmitz Katz auch mit anderen unbekannten (eigenen) Protokollen erfolgreich getestet.