7
OPNsense IPSec NAT Problem
Hallo,
ich bin aktuell am verzweifeln mit meiner VPN IPSec Konfiguration.
Ich bekomme einfach keinen Ping auf die Gegenseite hin, der Ping auf meinen Server (RDS) läuft nur gelegentlich....
Meine Hoffnung ist das mir hier jemand etwas Licht ins Dunkel bringen kann und mal meine Konfiguration zu checken ob ich einen groben Denkfehler drinnen habe.
Der IPSec Tunnel lässt sich auf jeden Fall schon mal aufbauen, deshalb denke ich das Phase 1 und Phase 2 soweit korrekt sein sollten.
Die Herausforderung dabei ist das mein eigentliches Netz beim Lieferanten schon belegt ist.
Eigentlich benötigen wir "nur" RDP Verbindungen vom Lieferanten auf unseren RDS und Druckjobs von uns zum Lieferanten.
Aktuell ist das Netzwerk so aufgebaut:
Auf unserer OPNSense habe ich die Einstellungen vorgenommen wie in diesem Artikel beschrieben:
https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
Ich habe unter SPD in der Phase2 meine "richtige" LAN IP eingetragen 192.168.11.0/24
Unter One to One NAT habe ich folgendes konfiguriert:
Aber ich bekomme einfach keinen Ping auf die Drucker an der Gegenseite.
Kann mir jemand sagen was ich an meiner Konfiguration falsch gemacht habe?
Aktuell bin ich schon zwei Wochen am Verzweifeln und bekomme es einfach nicht hin.
Meine Vermutung ist das ich beim NAT etwas grundlegendes Falsch mache.
Ich wäre für jede Antwort dankbar.
Vielen Dank.
Beste Grüße
Somebody
ich bin aktuell am verzweifeln mit meiner VPN IPSec Konfiguration.
Ich bekomme einfach keinen Ping auf die Gegenseite hin, der Ping auf meinen Server (RDS) läuft nur gelegentlich....
Meine Hoffnung ist das mir hier jemand etwas Licht ins Dunkel bringen kann und mal meine Konfiguration zu checken ob ich einen groben Denkfehler drinnen habe.
Der IPSec Tunnel lässt sich auf jeden Fall schon mal aufbauen, deshalb denke ich das Phase 1 und Phase 2 soweit korrekt sein sollten.
Die Herausforderung dabei ist das mein eigentliches Netz beim Lieferanten schon belegt ist.
Eigentlich benötigen wir "nur" RDP Verbindungen vom Lieferanten auf unseren RDS und Druckjobs von uns zum Lieferanten.
Aktuell ist das Netzwerk so aufgebaut:
+------------------------+ +---------------------------+ +-------------------------------+
| Standort Lieferant | | Interner Drucker | | Tatsächliche Drucker IP |
| |-----------------| |-------------| |
| 22.22.22.22 | | 10.10.10.11/22 | | 199.144.231.25/22 |
+------------------------+ +---------------------------+ +-------------------------------+
| |
| | +-----------------------------+
| | | Clients via RDP auf RDS |
| +----------------------------------------------------------------| |
| | XXX.XXX.XXX.XXX |
| +-----------------------------+
|
|
+--------------------------+ +----------------------------+
| Firmenstandort | | Fake Netzwerk |
| |----------------| |
| WAN 44.44.44.44 | | 192.168.55.0/24 |
+--------------------------+ +----------------------------+
|
|
|
|
|
|
+----------------------------+
- | Remote Desktop Server |
| |
| 192.168.11.55 |
| |
+----------------------------+ Auf unserer OPNSense habe ich die Einstellungen vorgenommen wie in diesem Artikel beschrieben:
https://wiki.opnsense.org/manual/how-tos/ipsec-s2s-binat.html
Ich habe unter SPD in der Phase2 meine "richtige" LAN IP eingetragen 192.168.11.0/24
Unter One to One NAT habe ich folgendes konfiguriert:
Aber ich bekomme einfach keinen Ping auf die Drucker an der Gegenseite.
Kann mir jemand sagen was ich an meiner Konfiguration falsch gemacht habe?
Aktuell bin ich schon zwei Wochen am Verzweifeln und bekomme es einfach nicht hin.
Meine Vermutung ist das ich beim NAT etwas grundlegendes Falsch mache.
Ich wäre für jede Antwort dankbar.
Vielen Dank.
Beste Grüße
Somebody
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: 397064
Url: https://administrator.de/forum/opnsense-ipsec-nat-problem-397064.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
ich bin aktuell am verzweifeln mit meiner VPN IPSec Konfiguration.
Warum ??Hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten (Mobile User)
oder auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a (Site to Site)
findest du doch Lösungen die du nur noch abtippen musst ?!
Wenn der Tunnel soweit sauber hochkommt, dann stimmen zu 98% deine Firewall Regeln nicht. Checke das !
Besonders hilft oft ein Blick in das Firewall Log was da geblockt wird.
Ping ist das ICMP Protokoll was du freigeben musst sowohl auf dem IPsec Tunnel Interface als auch den beteiligten LAN Interfaces beider Seiten. Hast du das beachtet.
Sinn macht es erstmal in den Firewall Regeln auf diesen Adaptern gesamt die IP Netze freizugeben, dann filterst du nicht Protokoll spezifisch, was das Troubleshootimng erheblich erleichtert.
Beim NAT kann man nichts falsch machen, das macht die pfSense automatisch und da muss man nix fummeln.
Im Tunnel macht man natürlich kein NAT ! Was aber eh Default ist !
Wie gesagt...der Fehler liegt mit 98%ider Wahrscheinlichkeit in falschen Firewall Regeln !
Nur nochmal als Erinnerung. Für die Regeln gelten folgende feste Grundregeln:
- Traffic wird nur inbound (eingehend) gefiltert. Also alles was IN das Interface reinkommt von außen.
- "First match wins" !! Der erste positive Hit in einer Regel bewirkt das nachfolgende Regeln NICHT mehr abgearbeitet werden. Beachte das ! Reihenfolge zählt hier also im Regelwerk !
1
Hallo aqui,
vielen Dank für deine Antwort und deinen verlinkten Artikeln, die hast du wirklich sehr sauber verfasst.
So wie ich bisher alles verstanden habe benötige ich NAT weil ich ja quasi ein "Zwischen Netz" habe.
Also mein Originales Netz hat die 192.168.11.0 dieses Netz ist aber bei unserem Lieferanten gegenüber schon belegt, weshalb er den VPN Tunnel auf ein anderes Netz gelegt hat 192.168.55.0
Jetzt muss ich doch meinem Router sagen das die Pakete welche von meinem "Original Netz (192.168.11.0)" auf das Netzwerk unseres Lieferanten (199.144.231.25/22) geschickt werden über das "Fake Netz (192.168.55.0)" geschickt werden, damit diese bei ihm richtig ankommen und er diese wieder entsprechend zu seinen Druckern weiter schicken kann.
Und dazu benötige ich doch dann NAT?
Die Firewall Rules habe ich wie folg eingestellt:
Also quasi ALL ALL ALL
Ich überprüfe jetzt nochmal Anhand deiner Links meine config, vielleicht fällt mir ja noch etwas auf.
Deiner Ansicht nach dürfte ich überhaupt keine manuellen NAT Einstellungen benötigen?
Tausend Dank nochmal für die nächsten Denkanstöße!
Beste Grüße
Somebody
vielen Dank für deine Antwort und deinen verlinkten Artikeln, die hast du wirklich sehr sauber verfasst.
So wie ich bisher alles verstanden habe benötige ich NAT weil ich ja quasi ein "Zwischen Netz" habe.
Also mein Originales Netz hat die 192.168.11.0 dieses Netz ist aber bei unserem Lieferanten gegenüber schon belegt, weshalb er den VPN Tunnel auf ein anderes Netz gelegt hat 192.168.55.0
Jetzt muss ich doch meinem Router sagen das die Pakete welche von meinem "Original Netz (192.168.11.0)" auf das Netzwerk unseres Lieferanten (199.144.231.25/22) geschickt werden über das "Fake Netz (192.168.55.0)" geschickt werden, damit diese bei ihm richtig ankommen und er diese wieder entsprechend zu seinen Druckern weiter schicken kann.
Und dazu benötige ich doch dann NAT?
Die Firewall Rules habe ich wie folg eingestellt:
Also quasi ALL ALL ALL
Ich überprüfe jetzt nochmal Anhand deiner Links meine config, vielleicht fällt mir ja noch etwas auf.
Deiner Ansicht nach dürfte ich überhaupt keine manuellen NAT Einstellungen benötigen?
Tausend Dank nochmal für die nächsten Denkanstöße!
Beste Grüße
Somebody
So wie ich bisher alles verstanden habe benötige ich NAT
Das kommt auf die Sichtweise an !NAT zum Internat ja ! Klar, denn da werden RFC 1918 IPs nicht geroutet
NAT im VPN Tunnel NEIN !
Sprich aller Traffic der in den VPN Tunnel geht darf NICHT geNATet werden. Logisch, denn sonst schaffst du dir in deinen internen Netzen eine Einbahnstrasse durch die NAT Firewall.
Aber letztlich brauchst du dich darum nicht zu kümmern, denn die pfSense macht grundsärtzlich kein NAT im VPN Tunnel. Es sei denn man konfiguriert das explizit, was aber kein normaler Netzwerker macht.
Oha....sorry, sehe gerade gleiche IP Netze auf beiden Seiten
Also mein Originales Netz hat die 192.168.11.0 dieses Netz ist aber bei unserem Lieferanten gegenüber schon belegt,
Das ist großer Schei... Ein IP Adress Designfehler ! Siehe dazu auch hier:
VPNs einrichten mit PPTP
Wenn irgend möglich solltest du dein Netz oder das gegenüber liegende auf eine andere IP Adresse umstellen.
Das wird dir die VPN Konfig erheblich erleichtern. Ohne das musst du ein Source und Destination NAT machen zwangsweise was die VPN Konfig unnötig verkompliziert und fast unmanagebar macht.
Ein IP Adressumstellung, sofern machbar, ist da das weitaus kleinere Übel.
Geht das partout nicht, dann hast du Recht, dann must du zwangsweise NATen im Tunnel was gruselig ist.
Und zwar sowohl Source als auch Destination NAT !!
1
Hallo aqui,
vielen Dank für deine Antwort.
Ich habe jetzt Testweise mal meinen PC auf die "Fake IP" gestellt, also 192.168.55.55 und habe alle NAT Regeln wieder deaktiviert.
In diesem Szenario sollte ich ja die gegenstelle pingen können oder?
Leider klappt selbst so der Ping nicht auf den Drucker im anderem Netzwerk, heißt das jetzt das da an der Gegenseite noch etwas falsch konfiguriet ist oder denkst du das ich noch etwas übersehen habe?
Phase 1 und 2 sind nach wie vor verbunden und unter Inbound / Outbound Traffic sehe ich auch das Traffic über den Tunnel läuft.
Unter der Traffic Analyse sehe ich wenn ich meinen Ping auf den Drucker starte (Traffic geht nach oben) also wandern die Pakete auch in den Tunnel.
Kennst du vielleicht noch andere Hilfsmittel für eine detailliertere Analyse?
Vielleicht hast du ja auch noch einen Ansatz für mich wie ich bei dem Problem noch weiter kommen könnte. Den Lieferanten habe ich bereits angeschrieben das er nochmal checken soll das ICMP auf den Drucker auch tatsächlich erlaubt ist.
Vielen Dank schon mal
Somebody
vielen Dank für deine Antwort.
Ich habe jetzt Testweise mal meinen PC auf die "Fake IP" gestellt, also 192.168.55.55 und habe alle NAT Regeln wieder deaktiviert.
In diesem Szenario sollte ich ja die gegenstelle pingen können oder?
Leider klappt selbst so der Ping nicht auf den Drucker im anderem Netzwerk, heißt das jetzt das da an der Gegenseite noch etwas falsch konfiguriet ist oder denkst du das ich noch etwas übersehen habe?
Phase 1 und 2 sind nach wie vor verbunden und unter Inbound / Outbound Traffic sehe ich auch das Traffic über den Tunnel läuft.
Unter der Traffic Analyse sehe ich wenn ich meinen Ping auf den Drucker starte (Traffic geht nach oben) also wandern die Pakete auch in den Tunnel.
Kennst du vielleicht noch andere Hilfsmittel für eine detailliertere Analyse?
Vielleicht hast du ja auch noch einen Ansatz für mich wie ich bei dem Problem noch weiter kommen könnte. Den Lieferanten habe ich bereits angeschrieben das er nochmal checken soll das ICMP auf den Drucker auch tatsächlich erlaubt ist.
Vielen Dank schon mal
Somebody
In diesem Szenario sollte ich ja die gegenstelle pingen können oder?
Ja, aber dann solltest du auch eine saubere VPN Konfig aufsetzen und das gesamte NAT entfernen.Leider klappt selbst so der Ping nicht auf den Drucker im anderem Netzwerk
Kannst du denn das lokale LAN Interface der FW in dem sich der Drucker befindet bzw. dessen IP pingen.Wenn das geht, dann ist der übliche Fehler das für den Drucker vergessen wurde eine Gateway IP einzurichten !
Der klassische Fehler bei Druckern in segmentierten Netzen, dann können die natürlich andere IP Netze niemals erreichen ohne Gateway.
Diese IP sollte natürlich dann auch auf deine VPN FW zeigen. Oder...sollte das ein anderer Router sein, dieser dann eine statische Route auf das VPN Gateway eingetragen haben.
Traceroute (tracert bei Winblows) ist hier dann wieder dein bester Freund um die Routing Hops sichtbar zu machen !
Kennst du vielleicht noch andere Hilfsmittel für eine detailliertere Analyse?
Na klar... Der Klassiker ! Ganz einfach:Statt des Druckers mal einen Laptop mit Wireshark der die gleiche IP hat wie der Drucker ins Netzwerk klemmen
(Drucker natürlich abziehen)Dann siehst du die eingehenden Ping Pakete (ICMP Echo Request) und wenn der Test Laptop dann seinerseits eine Gateway eingerichtet hat dann siehst du auch seine Antwort auf den Ping (ICMP Echo Reply).
Das zeigt dann das alles sauber rennt, das VPN funktioniert und der Drucker eine fehlende Gateway IP hat !
Drucker Netzwerk Interfaces supporten in der Regel immer ICMP (Pings) sogar bei den allerbilligsten Teilen vom Blödmarkt.
Nur...das Gateway muss natürlich auch stimmen
1
Hallo aqui,
vielen Dank für deine Tipps.
Ich habe es jetzt endlich hinbekommen.
Falls jemand so am verzweifeln ist wie ich, möchte ich hier noch kurz die Lösung zu meinen Problem schildern:
Also erstes Problem war, das trotz mehrfachem Nachfragen kein ICMP auf der Gegenseite konfiguriert bzw. erlaubt war.... #feelsbad
Gut nach dem dieses SICHER konfiguriert war konnte ich mit meinen Tests fortfahren.
Meine BINAT Einstellungen habe ich wie folgt konfiguriert:
Um bei meinem Beispiel zu bleiben:
Request läuft über: WAN 44.44.44.44
Sollte aber über: (192.168.11.55 Remote Desktop Server) ->192.168.55.55
Meine aktuelle One-to-One NAT Regel sieht wie folgt aus:
Interface: IPSec
Type: BINAT
External network: 192.168.55.0/24
Source: 192.168.11.0/24
Destination: 199.144.231.0/22
Danach hatte der Ping hin gehauen und die Gegenseite konnte sich via RDP auf meinen Terminalserver verbinden.
Nur leider habe ich immer noch nicht die Drucker erreicht. Ping ging gelegentlich, ist aber immer wieder abgebrochen.
Als ich mit dem Firewall Admin der Gegenseite telefoniert hatte sind wir durch die Logs gegangen. Wir haben erkannt das meine Firewall mit der WAN IP den Request stellt, die Firewall aber logischerweise meine interne LAN IP erwartet und deshalb meine Anfragen dropt.
Jetzt habe ich nochmal etwas in den Settings gesucht und bin letzten Endes drauf gekommen das ich zusätzlich Outbound NAT konfigurieren muss.
Folgende Settings unter Outbound NAT waren dann der Schlüssel zum Erfolg:
Interface: WAN
Source: 192.168.11.55
Port: any
Destination: 199.144.231.25
Port: any
Translation: 192.168.55.55/32
Ich habe in meinem Fall jetzt jeden Drucker einzeln hinzugefügt, waren nur 5, da ich mir mit den unterschiedlichen Subnetzen unsicher war ob es die Firewall sauber hin bekommt.
Jetzt läuft es auf jeden Fall und ich bin über glücklich.
Vielen Dank nochmal für die Unterstützung aqui.
Beste Grüße
Somebody
vielen Dank für deine Tipps.
Ich habe es jetzt endlich hinbekommen.
Falls jemand so am verzweifeln ist wie ich, möchte ich hier noch kurz die Lösung zu meinen Problem schildern:
Also erstes Problem war, das trotz mehrfachem Nachfragen kein ICMP auf der Gegenseite konfiguriert bzw. erlaubt war.... #feelsbad
Gut nach dem dieses SICHER konfiguriert war konnte ich mit meinen Tests fortfahren.
Meine BINAT Einstellungen habe ich wie folgt konfiguriert:
Um bei meinem Beispiel zu bleiben:
Request läuft über: WAN 44.44.44.44
Sollte aber über: (192.168.11.55 Remote Desktop Server) ->192.168.55.55
Meine aktuelle One-to-One NAT Regel sieht wie folgt aus:
Interface: IPSec
Type: BINAT
External network: 192.168.55.0/24
Source: 192.168.11.0/24
Destination: 199.144.231.0/22
Danach hatte der Ping hin gehauen und die Gegenseite konnte sich via RDP auf meinen Terminalserver verbinden.
Nur leider habe ich immer noch nicht die Drucker erreicht. Ping ging gelegentlich, ist aber immer wieder abgebrochen.
Als ich mit dem Firewall Admin der Gegenseite telefoniert hatte sind wir durch die Logs gegangen. Wir haben erkannt das meine Firewall mit der WAN IP den Request stellt, die Firewall aber logischerweise meine interne LAN IP erwartet und deshalb meine Anfragen dropt.
Jetzt habe ich nochmal etwas in den Settings gesucht und bin letzten Endes drauf gekommen das ich zusätzlich Outbound NAT konfigurieren muss.
Folgende Settings unter Outbound NAT waren dann der Schlüssel zum Erfolg:
Interface: WAN
Source: 192.168.11.55
Port: any
Destination: 199.144.231.25
Port: any
Translation: 192.168.55.55/32
Ich habe in meinem Fall jetzt jeden Drucker einzeln hinzugefügt, waren nur 5, da ich mir mit den unterschiedlichen Subnetzen unsicher war ob es die Firewall sauber hin bekommt.
Jetzt läuft es auf jeden Fall und ich bin über glücklich.
Vielen Dank nochmal für die Unterstützung aqui.
Beste Grüße
Somebody
Glückwunsch ! 
Obwohl der Grund ein lax und fehlerhaft designtes VPN IP Adress Konzept ist. Man kann nur jeden Leser ermutigen sowas VORHER zu bedenken und entsprechend exotischere IP Adressierungen für die lokalen LANs zu verwenden damit man solche Anpassungen nicht später machen muss um das wieder hinzubiegen.
Case closed !
möchte ich hier noch kurz die Lösung zu meinen Problem schildern:
Dank für dein Feedback. Das hilft ganz sicher auch Anderen mit gleicher Problematik hier !Obwohl der Grund ein lax und fehlerhaft designtes VPN IP Adress Konzept ist. Man kann nur jeden Leser ermutigen sowas VORHER zu bedenken und entsprechend exotischere IP Adressierungen für die lokalen LANs zu verwenden damit man solche Anpassungen nicht später machen muss um das wieder hinzubiegen.
Case closed !
1
