
90948
23.05.2012, aktualisiert um 15:49:24 Uhr
Probleme beim Outbound NAT Routing mit pfSense
Hallo,
erstmal zu meiner Konfiguration:
Ich verwende pfSense in der Version 2.0.1 auf einem Router mit insgesamt 3 Netzwerkkarten.
1. NIC (Office) sind die Clients angeschlossen
2. NIC (PLS) wird in ein 2. Subnetz geroutet
3. NIC (WAN) ist der Internet-Anschluss
Wenn ich jetzt Automatic Outbound NAT aktiviere funktioniert das Routing in das 2. Subnetz nicht mehr. Ich nehme an weil pfSense nur ein Outbound zur WAN-Schnittstelle automatisch erstellt. Nun habe ich manuelle Outbound NAT's erstellt mit denen ich einfach alles in alles Route.
Outbound-Regeln:
Interface Source Destination NAT Static Port
Office any * * NO
PLS any * * NO
WAN any * * NO
WAN any 162.170.200.99 * YES 500
PLS 162.170.200.99 * * YES 500
Jetzt zu meinem Problem:
Wir haben von externen Zugang der mittels isakmp-Protokoll. Dieses kommt von der WAN-Schnittstelle und wird zu einem Cisco-Router (162.170.200.99) weitergeleitet. Dementsprechendes Port-Forwarding und Firewall-Regeln wurden zwar gesetzt, aber der IPSEC-passthrough funktioniert nicht da der Cisco dann eine Verbindung mit der pfSense aufbauen will.
Ich hab auch mal eine Regel aufgestellt die den Port 500 weiterleitet und diesen als Statisch deklariert (letzten 2 Outbound-Regeln). Hat jedoch nicht funktioniert. Stell ich den Outbound wieder auf automatisch funktioniert der externe Zugang.
Ich weiß dass ich was falsch mache nur was
Danke schon mal für jede Hilfe
erstmal zu meiner Konfiguration:
Ich verwende pfSense in der Version 2.0.1 auf einem Router mit insgesamt 3 Netzwerkkarten.
1. NIC (Office) sind die Clients angeschlossen
2. NIC (PLS) wird in ein 2. Subnetz geroutet
3. NIC (WAN) ist der Internet-Anschluss
Wenn ich jetzt Automatic Outbound NAT aktiviere funktioniert das Routing in das 2. Subnetz nicht mehr. Ich nehme an weil pfSense nur ein Outbound zur WAN-Schnittstelle automatisch erstellt. Nun habe ich manuelle Outbound NAT's erstellt mit denen ich einfach alles in alles Route.
Outbound-Regeln:
Interface Source Destination NAT Static Port
Office any * * NO
PLS any * * NO
WAN any * * NO
WAN any 162.170.200.99 * YES 500
PLS 162.170.200.99 * * YES 500
Jetzt zu meinem Problem:
Wir haben von externen Zugang der mittels isakmp-Protokoll. Dieses kommt von der WAN-Schnittstelle und wird zu einem Cisco-Router (162.170.200.99) weitergeleitet. Dementsprechendes Port-Forwarding und Firewall-Regeln wurden zwar gesetzt, aber der IPSEC-passthrough funktioniert nicht da der Cisco dann eine Verbindung mit der pfSense aufbauen will.
Ich hab auch mal eine Regel aufgestellt die den Port 500 weiterleitet und diesen als Statisch deklariert (letzten 2 Outbound-Regeln). Hat jedoch nicht funktioniert. Stell ich den Outbound wieder auf automatisch funktioniert der externe Zugang.
Ich weiß dass ich was falsch mache nur was
Danke schon mal für jede Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 185340
Url: https://administrator.de/forum/probleme-beim-outbound-nat-routing-mit-pfsense-185340.html
Ausgedruckt am: 26.04.2025 um 18:04 Uhr
10 Kommentare
Neuester Kommentar
WAS willst du denn genau erreichen ?? Das das "PLS" Segment mit dem LAN kommunizieren kann ??
Normalerweise geht das nicht weil die FW per default alles verbietet (keine FW Regel) auf dem PLS Interface !
Du musst also ein ALLOW Regel anlegen die den Traffic nach any (Internet) und LAN Interface erlaugt !
Dann klappt das auch !!
Normalerweise geht das nicht weil die FW per default alles verbietet (keine FW Regel) auf dem PLS Interface !
Du musst also ein ALLOW Regel anlegen die den Traffic nach any (Internet) und LAN Interface erlaugt !
Dann klappt das auch !!
OK, das bringt ein klein wenig Licht ins Dunkel....
1.) Office soll ins PLS kommunizieren dürfen..., Office soll ins Internet kommunizieren dürfen
OK dann kannst du in den Firewall Regeln am "Office" Interface Source=Office Subnet, Port=any auf Destination=any , Port=any erlauben ! Office Clients kommen so ins Internet und auch ins PLS Netz.
2.) "PLS" darf dann vermutlich NUR mit dem Office kommunizieren, oder ?? Leider teilst du das in deinen Regel Beschreibungen mal wieder nicht mit
Wenn dem so ist dann muss am "PLS" Interface in den Firewall Regeln stehen: Source=PLS Subnet, Port=any auf Destination=Office Subnet , Port=any erlauben !
Mehr NICHT !
Damit kommen dann PLS Clients NICHT ins Internet was vermutlich so gewollt ist ?!
Fazit: Dir fehlen dann die korrekten Firewall regeln am PLS Interface. Da du einen Firewall bedienst gilt dort immer also oberster Firewall Grundsatz: "Es ist ALLES verboten was nicht ausdrücklich erlaubt ist !"
Das weiss jeder netzwerk Anfänger !
Wie gesagt es fehlen weiterhin die exakten Beschreibungen deiner Zugriffs Regeln für alle Segmente....
Völlig wirr ist deine Beschreibung wer wohin IPsec VPN Zugriff haben soll !
Es ist natürlich völliger Blödsinn das ein IPsec (ISAKMP ist Teil von IPsec !) Tunnel Endpunkt von sich aus was weiterreicht wie du oben beschreibst. Da hast du wohl den Sinn und die Technik von IPsec VPN garnicht oder nur halb verstanden.
Normalerweise gilt auf der was du in den Firewall Regeln zugelassen hast.
Hast du Zugangsregeln auf Port und Protokollbasis gemacht, dann musst du auch ESP Protokoll und IKE/ISAKMP UDP 500 zulassen um IPsec Clients hinter der Firewall eine Verbindung zu erlauben.
Wenn du Protocoll=any gesetzt hast wird es eh geforwardet.
Bedenke auch: Firewall Regeln gelten NUR für eingehenden Traffic und es gilt "First Match wins !"
Hier helfen also nur deine detailierten Regeln von dem Segment wo deine Clients sind. Dort hast du mit Sicherheit gravierende Fehler gemacht diesbezüglich !
Was du bei IPsec noch bedenken musst:
Wenn du einen transparenten Router vor dem WAN Interface mit öffentlichen IPs hast musst du lediglich am WAN Port der pfSense sicherstellen das du dort im NAT die IPsec Ports auf das Client Segment forwardest, da die sonst die NAT Firewall der pfSense nicht überwinden können !!
Das Firewall Log der pfSense ist hier wie immer dein Freund beim Troubleshooting.
Da die pfSense selber IPsec kann macht es ggf. Sinn die pfSense das IPsec VPN aufbauen zu lassen statt der Clients sofern das eine feste LAN zu LAN Kopplung ist !
Wäre ja sinnvoller hängt aber von der VPN Anwendung ab und kann man ohne Infos hier nur raten...
1.) Office soll ins PLS kommunizieren dürfen..., Office soll ins Internet kommunizieren dürfen
OK dann kannst du in den Firewall Regeln am "Office" Interface Source=Office Subnet, Port=any auf Destination=any , Port=any erlauben ! Office Clients kommen so ins Internet und auch ins PLS Netz.
2.) "PLS" darf dann vermutlich NUR mit dem Office kommunizieren, oder ?? Leider teilst du das in deinen Regel Beschreibungen mal wieder nicht mit
Wenn dem so ist dann muss am "PLS" Interface in den Firewall Regeln stehen: Source=PLS Subnet, Port=any auf Destination=Office Subnet , Port=any erlauben !
Mehr NICHT !
Damit kommen dann PLS Clients NICHT ins Internet was vermutlich so gewollt ist ?!
Fazit: Dir fehlen dann die korrekten Firewall regeln am PLS Interface. Da du einen Firewall bedienst gilt dort immer also oberster Firewall Grundsatz: "Es ist ALLES verboten was nicht ausdrücklich erlaubt ist !"
Das weiss jeder netzwerk Anfänger !
Wie gesagt es fehlen weiterhin die exakten Beschreibungen deiner Zugriffs Regeln für alle Segmente....
Völlig wirr ist deine Beschreibung wer wohin IPsec VPN Zugriff haben soll !
Es ist natürlich völliger Blödsinn das ein IPsec (ISAKMP ist Teil von IPsec !) Tunnel Endpunkt von sich aus was weiterreicht wie du oben beschreibst. Da hast du wohl den Sinn und die Technik von IPsec VPN garnicht oder nur halb verstanden.
Normalerweise gilt auf der was du in den Firewall Regeln zugelassen hast.
Hast du Zugangsregeln auf Port und Protokollbasis gemacht, dann musst du auch ESP Protokoll und IKE/ISAKMP UDP 500 zulassen um IPsec Clients hinter der Firewall eine Verbindung zu erlauben.
Wenn du Protocoll=any gesetzt hast wird es eh geforwardet.
Bedenke auch: Firewall Regeln gelten NUR für eingehenden Traffic und es gilt "First Match wins !"
Hier helfen also nur deine detailierten Regeln von dem Segment wo deine Clients sind. Dort hast du mit Sicherheit gravierende Fehler gemacht diesbezüglich !
Was du bei IPsec noch bedenken musst:
Wenn du einen transparenten Router vor dem WAN Interface mit öffentlichen IPs hast musst du lediglich am WAN Port der pfSense sicherstellen das du dort im NAT die IPsec Ports auf das Client Segment forwardest, da die sonst die NAT Firewall der pfSense nicht überwinden können !!
Das Firewall Log der pfSense ist hier wie immer dein Freund beim Troubleshooting.
Da die pfSense selber IPsec kann macht es ggf. Sinn die pfSense das IPsec VPN aufbauen zu lassen statt der Clients sofern das eine feste LAN zu LAN Kopplung ist !
Wäre ja sinnvoller hängt aber von der VPN Anwendung ab und kann man ohne Infos hier nur raten...
Was soll denn der Unsinn das sich ein VPN Client aus dem lokalen pfSense LAN per VPN Netz auf den Cisco am pfSense WAN Port verbindet ??
Dafür braucht man doch gar kein VPN sondern kann das mit normalem Routing so machen ??!
Oder muss der Datentraffic am pfSense WAN Port verschlüsselt sein ?
Es ist auch normal das am Cisco ESP und ISAKMP mit der pfSense WAN IP auftauschen, denn die pfSense macht NAT wie jeder Feld- Wald- und Wiesen DSL Router auch.
Er antwortet auch darauf und die pfSense leitet das dann an den Client weiter. Deshalb auch das zwingend Port Forwarding für ESP und UDP 500 (IKE). Zusätzlich sollte man immer noch UDP 4500 aktivieren (NAT Traversal)
Das ist ein IPsec Standardszenario was so auch mit jedem belibigen DSL NAT Router funktioniert.
Die pfSense funktioniert da nicht anders solange KEIN IPsec auf ihr selber aktiviert ist !
Ääähhh, ok sehe gerade das Bild. Vergiss das obige mit dem Routing....
Gut der Cisco ist in einem lokalen LAN Segment also NICHT am WAN Port, ist dem so ?
Dann musst du natürlich am PLS Port UDP 500, UDP 4500 und ESP sprich IPsec forwarden nach any. Ebenso muss ein statisches NAT Forwarding der pfSense IP auf die Cisco IP gemacht werden mit den relevanten IPsec Ports. Wer Wartungsrechner von außen "sieht" ja nur die pfSense WAN IP. Die Cisco IP kann er logischerweise nicht sehen durch die NAT Firewall.
...und es hat nicht funktioniert.
Mmmhh, was sagen denn die Firewall Logs dazu und hast du mal mitgesniffert WAS denn nicht durchkommt ?!
...dann reichen sogar die UDP-Ports aus um eine Verbindung aufzubauen.
Klar, ist logisch, denn Cisco macht per Default IPsec NAT Traversal und der kommt auch ohne das NAT Port Forwarding aus sofern auf dem WAN Port eingehende UDP 500 und UDP 4500 sowie ESP erlaubt sind !
Übrigens:
"Destination-Port 500-4500" ist Blödsinn und auch kontraproduktiv im Hinblick auf die Sicherheit, denn dann machst du ein Riesengroßes Loch in der Firewall auf denn du öffnest alle Ports von 500 bis 4500. Sinnloss und überflüssig. Es reicht 500 und 4500 aufzumachen, das erreicht man mit dem Klick auf + und fügt einen Regel nur mit dem anderen Port hinzu.
Was soll auch "NAT Port 4000" sein ?? So einen Port gibt es in der gesamten VPN Protokollfamilie nirgendwo ?!
Wenn wäre er ja auch in deiner falschen Range oben von 500 bis 4500 so oder so inkludiert !
Cisco nutzt in älteren NAT-T Implementationen stat 4500 auch UDP 10000. Ggf. solltest du das testweise mal öffnen oder sniffern.
https://supportforums.cisco.com/docs/DOC-4119
Mmmhh, was sagen denn die Firewall Logs dazu und hast du mal mitgesniffert WAS denn nicht durchkommt ?!
...dann reichen sogar die UDP-Ports aus um eine Verbindung aufzubauen.
Klar, ist logisch, denn Cisco macht per Default IPsec NAT Traversal und der kommt auch ohne das NAT Port Forwarding aus sofern auf dem WAN Port eingehende UDP 500 und UDP 4500 sowie ESP erlaubt sind !
Übrigens:
"Destination-Port 500-4500" ist Blödsinn und auch kontraproduktiv im Hinblick auf die Sicherheit, denn dann machst du ein Riesengroßes Loch in der Firewall auf denn du öffnest alle Ports von 500 bis 4500. Sinnloss und überflüssig. Es reicht 500 und 4500 aufzumachen, das erreicht man mit dem Klick auf + und fügt einen Regel nur mit dem anderen Port hinzu.
Was soll auch "NAT Port 4000" sein ?? So einen Port gibt es in der gesamten VPN Protokollfamilie nirgendwo ?!
Wenn wäre er ja auch in deiner falschen Range oben von 500 bis 4500 so oder so inkludiert !
Cisco nutzt in älteren NAT-T Implementationen stat 4500 auch UDP 10000. Ggf. solltest du das testweise mal öffnen oder sniffern.
https://supportforums.cisco.com/docs/DOC-4119
Das wäre dann falsch ! In der Destination IP Adresse der ESP und IKE Pakete die vom Cisco zurückgehen muss die IP Adresse des remoten Rechners stehen !
Hier darf niemals die IP Adresse der pfSense als Ziel IP stehen. Das würde ja bedeuten das die pfSense selber aktiv als VPN Server auf die IPsec Paketet antwortet.
Stelle also absolut sicher das IPsec deaktiviert ist in der FW !!
Was sagen denn die eingehenden IPsec Pakete vom remoten Rechner die beim Cisco ankommen ?
Zeigen die als Absender IP die des remoten Systems ?
Der Cisco muss doch auch mit dieser IP als Ziel IP antworten. Alles andere wäre völlig undenkbar !
Hier darf niemals die IP Adresse der pfSense als Ziel IP stehen. Das würde ja bedeuten das die pfSense selber aktiv als VPN Server auf die IPsec Paketet antwortet.
Stelle also absolut sicher das IPsec deaktiviert ist in der FW !!
Was sagen denn die eingehenden IPsec Pakete vom remoten Rechner die beim Cisco ankommen ?
Zeigen die als Absender IP die des remoten Systems ?
Der Cisco muss doch auch mit dieser IP als Ziel IP antworten. Alles andere wäre völlig undenkbar !