131941
Mar 31, 2020, updated at 10:46:24 (UTC)
1114
10
0
VPN Site2Site NAT auf andere IP
Moin zusammen,
wir haben folgende Situation, ein Lieferant hat eine IKEv2 Site2Site Verbindung zu uns.
Der Lieferant möchte aber mit einem unserer Server über eine andere IP kommunizieren, als die, die unser Server hat. Es sollen also nicht einfach beide Netze miteinander vernetzt werden.
Unser Server hat die 192.168.10.1
Der Lieferant möchte aber, bei sich die IP: 192.168.50.99 ansprechen und durch den VPN Tunnel soll diese IP aufgelöst werden und auf die unseres Server verweisen: 192.168.10.1
Sprich, er pingt die 192.168.50.99 an und seine Anfrage landet bei unserem Server auf der 192.168.10.1
Grund dafür, unser Lieferant kann die IP unseres Netzes nicht nutzen, da es bei denen schon anderweitig vergeben ist.
Wir haben eine Whatchguard Firewall und ich habe jetzt schon in den P2 Settings mit DNAT und 1:1 Nat rumgespielt, aber leider komme ich nicht zu dem gewünschten Ergebnis.
Über 1:1 NAT kommt gar kein Tunnel Aufbau zu Stande, über DNAT kommt das Paket nicht an.
Firewall Einstellungen würde ich sagen stimmen soweit, zumindest wird jeglicher VPN Traffic zugelassen.
Würde mich über ein wenig Input freuen.
So sieht es bei uns aus:
Viele Grüße
wir haben folgende Situation, ein Lieferant hat eine IKEv2 Site2Site Verbindung zu uns.
Der Lieferant möchte aber mit einem unserer Server über eine andere IP kommunizieren, als die, die unser Server hat. Es sollen also nicht einfach beide Netze miteinander vernetzt werden.
Unser Server hat die 192.168.10.1
Der Lieferant möchte aber, bei sich die IP: 192.168.50.99 ansprechen und durch den VPN Tunnel soll diese IP aufgelöst werden und auf die unseres Server verweisen: 192.168.10.1
Sprich, er pingt die 192.168.50.99 an und seine Anfrage landet bei unserem Server auf der 192.168.10.1
Grund dafür, unser Lieferant kann die IP unseres Netzes nicht nutzen, da es bei denen schon anderweitig vergeben ist.
Wir haben eine Whatchguard Firewall und ich habe jetzt schon in den P2 Settings mit DNAT und 1:1 Nat rumgespielt, aber leider komme ich nicht zu dem gewünschten Ergebnis.
Über 1:1 NAT kommt gar kein Tunnel Aufbau zu Stande, über DNAT kommt das Paket nicht an.
Firewall Einstellungen würde ich sagen stimmen soweit, zumindest wird jeglicher VPN Traffic zugelassen.
Würde mich über ein wenig Input freuen.
So sieht es bei uns aus:
Viele Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 562017
Url: https://administrator.de/contentid/562017
Printed on: April 20, 2024 at 10:04 o'clock
10 Comments
Latest comment
Zitat von @131941:
Moin zusammen,
Hi,Moin zusammen,
wir haben folgende Situation, ein Lieferant hat eine IKEv2 Site2Site Verbindung zu uns.
Der Lieferant möchte aber mit einem unserer Server über eine andere IP kommunizieren, als die, die unser Server hat. Es sollen also nicht einfach beide Netze miteinander vernetzt werden.
Unser Server hat die 192.168.10.1
Der Lieferant möchte aber, bei sich die IP: 192.168.50.99
Der Lieferant möchte aber mit einem unserer Server über eine andere IP kommunizieren, als die, die unser Server hat. Es sollen also nicht einfach beide Netze miteinander vernetzt werden.
Unser Server hat die 192.168.10.1
Der Lieferant möchte aber, bei sich die IP: 192.168.50.99
Das Bild passt hinten und vorne nicht zu deiner Beschreibung, bitte nochmal prüfen.
Ansonsten gibt man in Phase 2 eigentlich nur das Remote-Subnet an, auf der Gegenseite ebenso, dann steht die Verbindung...
Was stimmt an meinem Bild nicht?
Mein lokales Netz ist eigentlich 192.168.10.0/24
Der Lieferant möchte aber, bei sich 192.168.50.99/32 ansprechen.
Er tut also so, als wäre 192.168.50.99 mein lokales Netz.
Da es das aber nicht ist, brauche ich eine Übersetzung von 192.168.50.99, die mein Lieferant nutzt, auf meinen Server auf die 192.168.10.1
Mein lokales Netz ist eigentlich 192.168.10.0/24
Der Lieferant möchte aber, bei sich 192.168.50.99/32 ansprechen.
Er tut also so, als wäre 192.168.50.99 mein lokales Netz.
Da es das aber nicht ist, brauche ich eine Übersetzung von 192.168.50.99, die mein Lieferant nutzt, auf meinen Server auf die 192.168.10.1
Der Lieferant möchte aber, bei sich 192.168.50.99/32 ansprechen. Er tut also so, als wäre 192.168.50.99 mein lokales Netz.
Das ist aber auch (vermutlich) dein Denkfehler...?!Die Frage ist WO das 1:1 NAT gemacht wird ? Auf der Seite des Lieferanten oder bei dir ? Das ist unklar...
Wenn der Lieferant das macht landet ja schon eine .50er IP im Tunnel. Wenn du ist eine 10er IP im Tunnel. Die P2s müssen das dann sowohl auf seiner Seite als auch bei dir zwingend berücksichtigen !
Passiert das NAT auf deiner Seite muss der Lieferant und auch du 2mal P2s eintragen für das 10er und 50er Netz.
Das NAT passiert dann bei dir.
In sofern hilft der Screenshot in der Tat recht wenig, denn man hat keinerlei Infos wer nun wo das NAT macht.
Zusätzlich ist essentiell zu wissen welcher Prozess zuerst von den beteiligten Routern/Firewall Hardwares auf Lieferant und lokaler Seite abgearbeitet wird. Erst NAT und dann VPN Encapsulation oder umgedreht ?
Das hat einen entscheidenden Einfluss auf die Konfig. Auch ob die HW generell NAT in Tunnel Interfaces supportet.
Gerade Letzteres wird vermutlich bei IPsec und dem (geraten) bei dir verwendeten Tunnel Mode auf Allerwelts Firewalls nicht der Fall sein.
Du müsstest hier besser im Transparent Mode arbeiten und am besten dann einen GRE Tunnel etablieren wie es z.B. HIER beschrieben ist.
GRE Tunnel Interfaces supporten exakt die gleichen Funktionen wie normale Routing Interfaces inkl. natürlich NAT.
Ohne das du die Hardware Features hier also wasserdicht klärst (ggf. Hersteller oder Service Partner) bleibt das eine Forschungsbaustelle !
Es ist dann erheblich einfacher für 5 Euro eine 2te Netzwerk Karte in den Server zu stecken, dem eine .50er IP zu vergeben und das Netz mit über den IPsec Tunnel zu routen. Spart Zeit und befreit dich vom Experimentieren am lebenden Objekt.
Zum Grundproblem einer nicht besonders intelligenten VPN IP Adressierung wollen wir jetzt mal lieber nichts sagen. Dazu solltest du das_hier besser lesen und verstehen. Das ist das eigentliche Problem. Wäre das richtig gelöst hätte es diesen Thread gar nicht erst gegeben !
Ok, ich versuche es noch einmal anders zu formulieren:
Unser Netz: 192.168.10.0/24
Fremdnetz: 192.168.199.0/?
Unser Server: 192.168.10.1
Der VPN Tunnel ist mit den IPs wie in dem Screenshot verbunden.
Also nicht die kompletten Netze, sondern lediglich diese zwei IPs
Nun möchte der Lieferant einen Ping auf die 192.168.50.99 schicken und dieses Datenpaket soll dann an die 192.168.10.1 durch unsere FW übersetz werden.
NAT passiert nur auf unsere Seite.
Ich stelle mir das also so vor, liebe Firewal, alles, was durch den VPN Tunnel an die 192.168.50.99 geht, bitte schicke dieses, an die 192.168.10.1
Und ich fand, dass was ich dort in P2 einstellen kann, sieht soweit schon ganz gut aus, aber irgendwie will das nicht...
Unser Netz: 192.168.10.0/24
Fremdnetz: 192.168.199.0/?
Unser Server: 192.168.10.1
Der VPN Tunnel ist mit den IPs wie in dem Screenshot verbunden.
Also nicht die kompletten Netze, sondern lediglich diese zwei IPs
Nun möchte der Lieferant einen Ping auf die 192.168.50.99 schicken und dieses Datenpaket soll dann an die 192.168.10.1 durch unsere FW übersetz werden.
NAT passiert nur auf unsere Seite.
Ich stelle mir das also so vor, liebe Firewal, alles, was durch den VPN Tunnel an die 192.168.50.99 geht, bitte schicke dieses, an die 192.168.10.1
Und ich fand, dass was ich dort in P2 einstellen kann, sieht soweit schon ganz gut aus, aber irgendwie will das nicht...
Hat der Lieferant die entsprechenden korrespondierenden P2s konfiguriert ? Source: .199.20 Destination: .50.99 und kommt der Tunnel mit diesen P2s hoch ?
Das weiß ich leider gerade nicht, kläre ich aber.
Ich gehe aber davon aus, denn der Tunnel kommt ja hoch.
Im Log sehe ich auch, dass der Ping in den Tunnel reingeht
Log meiner Firewall:
Allow 192.168.199.20 192.168.50.99 icmp VPN01 0-WAN Allowed 84 63 (BOVPN-Allow.in-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.10.1"
Sind denn meine P2s soweit korrekt, so wie ich mir das denke?
Ich gehe aber davon aus, denn der Tunnel kommt ja hoch.
Im Log sehe ich auch, dass der Ping in den Tunnel reingeht
Log meiner Firewall:
Allow 192.168.199.20 192.168.50.99 icmp VPN01 0-WAN Allowed 84 63 (BOVPN-Allow.in-00) proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="192.168.10.1"
Sind denn meine P2s soweit korrekt, so wie ich mir das denke?
Das weiß ich leider gerade nicht, kläre ich aber.
Vertrauen ist gut Kontrolle ist besser ! 
Sind denn meine P2s soweit korrekt, so wie ich mir das denke?
Was deine Seite anbetrifft ja ! Genauso wichtig ist aber auch die des Gegenübers. Bei unterschiedlichen P2s kommt der Tunnel nicht hoch.
Der Tunnel ist ja oben 
Wie deutest Du das Log?
Müsste doch gehen, oder nicht?
Hier passiert ja das NAT: src_ip_nat="192.168.10.1"
Aber warum src?
Müsste das nicht eher Destination sein, oder was heißt src
Wie deutest Du das Log?
Müsste doch gehen, oder nicht?
Hier passiert ja das NAT: src_ip_nat="192.168.10.1"
Aber warum src?
Müsste das nicht eher Destination sein, oder was heißt src
Na ja ist die Frage aus welcher Richtung es das NAT sieht. Du machst ja ein 1:1 NAT. Sprich aus Source: 192.168.10.1 wird nach dem NAT Source: 192.168.50.99
Und beim Rückweg wird aus Source: 192.168.50.99 dann wieder Source: 192.168.10.1
Alles eine Frage der Perspektive.
Aber die Log Message sagt das sich da irgendwas tut in puncto NAT.
Hilfreich wäre aber wenn du dir das am NAT Outbound Interface mal mit einem Wireshark ansiehst ob das auch wirklich das tut was es soll. Oder mit der internen Packet Capture Funktion in der Firewall was die meisten ja auch haben und die Sache vereinfacht.
Und beim Rückweg wird aus Source: 192.168.50.99 dann wieder Source: 192.168.10.1
Alles eine Frage der Perspektive.
Aber die Log Message sagt das sich da irgendwas tut in puncto NAT.
Hilfreich wäre aber wenn du dir das am NAT Outbound Interface mal mit einem Wireshark ansiehst ob das auch wirklich das tut was es soll. Oder mit der internen Packet Capture Funktion in der Firewall was die meisten ja auch haben und die Sache vereinfacht.
Hi, so ein Problem musste ich auch mal lösen.
Dabei sah das Ganze so aus:
LAN_SeiteA = 192.168.10.0/24
LAN_SeiteB = 192.168.20.0/24
Seite A wollte nicht das 192.168.20.0/24 ansprechen,
um mit dem LAN_SeiteB zu kommunizieren (weil dieses ebenfalls auf SeiteA in Benutzung war),
sondern eben ein anderes Netz.
Da habe ich dann als Transfer-Netz für den IPsec-Tunnel einfach das 192.168.200.0/24er-Netz gewählt,
weil es noch nirgends in Verwendung war.
Auf Seite A wird dann in der Tunnel-Konfiguration das Netz der Gegenseite mit 192.168.200.0/24 angegeben
und auf Seite B wird das 192.168.200.0/24er-Netz entsprechend als lokales Netz angegeben.
Als nächstes braucht man dann noch auf Seite B insgesamt 2 1:1-NAT-Regeln.
Die 1. 1:1-NAT-Regel macht ein Destination-NAT für den Traffic mit Quelle = 192.168.10.0/24 und Ziel = 192.168.200.0/24
auf das "echte" Netz von SeiteB, nämlich auf das Netz 192.168.20.0/24.
Die 2. 1:1-NAT-Regel macht dann ein Source-NAT, wobei das Quell-Netz 192.168.20.0/24
auf das Netz 192.168.200.0/24 gesourcnattet wird, damit die Antwortpakete in Richtung 192.168.10.0/24
ebenfalls durch den Tunnel übertragen werden.
Siehe dazu auch folgende Seite, wo sowas ähnliches mit 2 "Sophos UTM"-Firewalls gemacht wurde:
https://community.sophos.com/kb/en-us/115579
In dem "Sophos UTM"-Szenario war es sogar so,
dass auf beiden Seiten das gleiche lokale Netz in Verwendung war,
weshalb auf beiden Seiten mit jeweils 2 1:1-NAT-Regeln gearbeitet werden musste.
Aber für das Verständnis und die praktische Umsetzung könnte es dir für deinen Fall ja weiterhelfen,
denke ich.
Dabei sah das Ganze so aus:
LAN_SeiteA = 192.168.10.0/24
LAN_SeiteB = 192.168.20.0/24
Seite A wollte nicht das 192.168.20.0/24 ansprechen,
um mit dem LAN_SeiteB zu kommunizieren (weil dieses ebenfalls auf SeiteA in Benutzung war),
sondern eben ein anderes Netz.
Da habe ich dann als Transfer-Netz für den IPsec-Tunnel einfach das 192.168.200.0/24er-Netz gewählt,
weil es noch nirgends in Verwendung war.
Auf Seite A wird dann in der Tunnel-Konfiguration das Netz der Gegenseite mit 192.168.200.0/24 angegeben
und auf Seite B wird das 192.168.200.0/24er-Netz entsprechend als lokales Netz angegeben.
Als nächstes braucht man dann noch auf Seite B insgesamt 2 1:1-NAT-Regeln.
Die 1. 1:1-NAT-Regel macht ein Destination-NAT für den Traffic mit Quelle = 192.168.10.0/24 und Ziel = 192.168.200.0/24
auf das "echte" Netz von SeiteB, nämlich auf das Netz 192.168.20.0/24.
Die 2. 1:1-NAT-Regel macht dann ein Source-NAT, wobei das Quell-Netz 192.168.20.0/24
auf das Netz 192.168.200.0/24 gesourcnattet wird, damit die Antwortpakete in Richtung 192.168.10.0/24
ebenfalls durch den Tunnel übertragen werden.
Siehe dazu auch folgende Seite, wo sowas ähnliches mit 2 "Sophos UTM"-Firewalls gemacht wurde:
https://community.sophos.com/kb/en-us/115579
In dem "Sophos UTM"-Szenario war es sogar so,
dass auf beiden Seiten das gleiche lokale Netz in Verwendung war,
weshalb auf beiden Seiten mit jeweils 2 1:1-NAT-Regeln gearbeitet werden musste.
Aber für das Verständnis und die praktische Umsetzung könnte es dir für deinen Fall ja weiterhelfen,
denke ich.
