11
Bintec IPSec mit IKEv2 und NAT im Tunnel
Moin zusammen,
mein Gerät: Bintec RS353jwv version V.10.2.12.100 IPv6, IPSec from 2022/08/25
Ich muss in einem VPN-Tunnel meine lokalen Adressen natten. Problem ist, dass die SA weiterhin mit der Original-Adresse (10.234.x.x) aufgebaut wird:
Ich habe eine NAT-Konfiguration für den IPSec-Peer aktiviert, passend dazu kommt folgende Logmeldung:
Das kann allerdings wegen der falschen SA oben nicht funktionieren. Muss ich das NAT "weiter oben" aktivieren und falls ja, wo? Mein PC und der lokale Router sind in demselben IP-Netz (10.234.x.x). Ich habe es bereits mit "Schnittstelle 'beliebig'" probiert. Auf dem Ethernet-Interface ist NAT nicht aktiv, ist das hierfür erforderlich?
Danke für Tipps. Gruß, Christian
mein Gerät: Bintec RS353jwv version V.10.2.12.100 IPv6, IPSec from 2022/08/25
Ich muss in einem VPN-Tunnel meine lokalen Adressen natten. Problem ist, dass die SA weiterhin mit der Original-Adresse (10.234.x.x) aufgebaut wird:
IPSEC: CHILD_SA: peer 23 (Name) traf 0 bundle -206 (I): created 10.234.x.x/24:0 < any > 10.102.x.x/32:0 rekeyed 0Ich habe eine NAT-Konfiguration für den IPSec-Peer aktiviert, passend dazu kommt folgende Logmeldung:
INET: NAT: new outgoing session on ifc 38100023 prot 6 10.234.x.x:63235/10.201.x.x:61314 -> 10.102.x.x:80Das kann allerdings wegen der falschen SA oben nicht funktionieren. Muss ich das NAT "weiter oben" aktivieren und falls ja, wo? Mein PC und der lokale Router sind in demselben IP-Netz (10.234.x.x). Ich habe es bereits mit "Schnittstelle 'beliebig'" probiert. Auf dem Ethernet-Interface ist NAT nicht aktiv, ist das hierfür erforderlich?
Danke für Tipps. Gruß, Christian
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: 3939990360
Url: https://administrator.de/forum/bintec-ipsec-mit-ikev2-und-nat-im-tunnel-3939990360.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
11 Kommentare
Neuester Kommentar
Moin,
hat den die Gegenseite auch die NAT IP-Adresse in die VPN Konfiguration eingetragen?!
Unabhängig davon hast du dich an den Artikel gehalten: bintec Router-Serien und be.IP-Serie - Hinweise zu NAT (Network Address Translation) im IPSec-Tunnel mit N:N-Übersetzung der Quell-IP-Adressen
Gruß,
Dani
hat den die Gegenseite auch die NAT IP-Adresse in die VPN Konfiguration eingetragen?!
Unabhängig davon hast du dich an den Artikel gehalten: bintec Router-Serien und be.IP-Serie - Hinweise zu NAT (Network Address Translation) im IPSec-Tunnel mit N:N-Übersetzung der Quell-IP-Adressen
Gruß,
Dani
Tip: Stelle besser die IP Netze um. Beidseitiges NAT ist Pest und Cholera in einem und nicht wirklich managebar. Ist auch fraglich ob ein einfacher Consumer Router wie der Bintec das kann.
Kollege @Dani hat es ja oben schon gesagt du musst das beidseitig einrichten.
Kollege @Dani hat es ja oben schon gesagt du musst das beidseitig einrichten.
Moin,
Die NAT-IPs sind auf beiden Seiten eingetragen.
Vielen Dank für den Hinweis auf den Artikel, daran hatte ich mich bereits weitestgehend gehalten, es fehlte die zusätzliche IP an der LAN-Schnittstelle. Wobei ich mich frage, was die bringen soll, sie hat keine Auswirkung auf den Tunnelaufbau. Alles andere habe ich exakt wie beschrieben eingetragen.
Wenn ich direkt auf dem Router ein Ping mit der Source-IP mache, wird der Tunnel einwandfrei aufgebaut (egal, ob diese IP auch im LAN-Interface konfiguriert ist oder nicht). Ping-Antworten kommen und anschließender Web-Traffic funktioniert.
Bei einem Verbindungsversuch bspw. durch http-Traffic ist hingegen in der Child-SA weiterhin die Original-IP aus dem Netz 10.234.x.x enthalten, erst anschließend wird genattet:
Frage ist also, wie ich den Bintec dazu bekomme, für die SA sofort die genattete IP zu verwenden.
Zitat von @Dani:
hat den die Gegenseite auch die NAT IP-Adresse in die VPN Konfiguration eingetragen?!
hat den die Gegenseite auch die NAT IP-Adresse in die VPN Konfiguration eingetragen?!
Die NAT-IPs sind auf beiden Seiten eingetragen.
Zitat von @Dani:
Unabhängig davon hast du dich an den Artikel gehalten: bintec Router-Serien und be.IP-Serie - Hinweise zu NAT (Network Address Translation) im IPSec-Tunnel mit N:N-Übersetzung der Quell-IP-Adressen
Unabhängig davon hast du dich an den Artikel gehalten: bintec Router-Serien und be.IP-Serie - Hinweise zu NAT (Network Address Translation) im IPSec-Tunnel mit N:N-Übersetzung der Quell-IP-Adressen
Vielen Dank für den Hinweis auf den Artikel, daran hatte ich mich bereits weitestgehend gehalten, es fehlte die zusätzliche IP an der LAN-Schnittstelle. Wobei ich mich frage, was die bringen soll, sie hat keine Auswirkung auf den Tunnelaufbau. Alles andere habe ich exakt wie beschrieben eingetragen.
Wenn ich direkt auf dem Router ein Ping mit der Source-IP mache, wird der Tunnel einwandfrei aufgebaut (egal, ob diese IP auch im LAN-Interface konfiguriert ist oder nicht). Ping-Antworten kommen und anschließender Web-Traffic funktioniert.
ping -s 10.201.x.x 10.102.x.x
IPSEC: CHILD_SA: peer 23 (Name) traf 0 bundle -232 (I): created 10.201.x.x/32:0 < any > 10.102.x.x/32:0 rekeyed 0
INET: NAT: new outgoing session on ifc 38100023 prot 1 10.201.x.x:13/10.201.x.x:50684 -> 10.102.x.x:0Bei einem Verbindungsversuch bspw. durch http-Traffic ist hingegen in der Child-SA weiterhin die Original-IP aus dem Netz 10.234.x.x enthalten, erst anschließend wird genattet:
IPSEC: CHILD_SA: peer 23 (Name) traf 0 bundle -231 (I): created 10.234.x.x/24:0 < any > 10.102.x.x/32:0 rekeyed 0
INET: NAT: new outgoing session on ifc 38100023 prot 6 10.234.x.x:52082/10.201.x.x:64721 -> 10.102.x.x:80Frage ist also, wie ich den Bintec dazu bekomme, für die SA sofort die genattete IP zu verwenden.
Zitat von @aqui:
Tip: Stelle besser die IP Netze um. Beidseitiges NAT ist Pest und Cholera in einem und nicht wirklich managebar.
Tip: Stelle besser die IP Netze um. Beidseitiges NAT ist Pest und Cholera in einem und nicht wirklich managebar.
IP-Wechsel ist leider keine Option. Ich muss Verbindungen zu vielen Partnern sehr unterschiedlicher Größenordnungen herstellen und dabei kommt es früher oder später zu irgendwelchen IP-Überschneidungen. Ich wäre auch heilfroh, wenn ich auf NAT verzichten könnte.
BTW, zu einer anderen Gegenstellte (die allerdings noch IKEv1 verwendet), klappt das mit dem NAT einwandfrei. Eventuell ein Bug in der NAT-Implementierung für IKEv2?
Zitat von @chluebke:
BTW, zu einer anderen Gegenstellte (die allerdings noch IKEv1 verwendet), klappt das mit dem NAT einwandfrei. Eventuell ein Bug in der NAT-Implementierung für IKEv2?
NAT hat erst mal rein gar nichts mit IPSec zu tun (außer beim Verbindungsaufbau der 4500UDP statt 500UDP bei erkanntem NAT Traversal der IPSec Endpunkte). NAT ist eine Funktion in der POSTROUTING/PREROUTING CHAIN der Firewall. Bei MASQUERADING findet dies in der POSTROUTING-Chain statt. Durch festlegen von Quell und Zielnetzen legt man fest ob bei Paketen/Verbindungen die Quell-Adressen umgeschrieben werden die über den Tunnel laufen.BTW, zu einer anderen Gegenstellte (die allerdings noch IKEv1 verwendet), klappt das mit dem NAT einwandfrei. Eventuell ein Bug in der NAT-Implementierung für IKEv2?
Moin,
Gruß,
Dani
Eventuell ein Bug in der NAT-Implementierung für IKEv2?
dafür wirst du den technischen Support von Bintec fragen müssen...Gruß,
Dani
In IKEv2 gibt es wie auch in IKEv1 per se kein NAT! Außer der automatischen NAT Traversal Detection über UDP 4500 des Tunnels selber. Das gilt aber wie Kollege @3803037559 schon sagt ausschliesslich NUR für den Tunnel bzw. Tunnelaufbau selber. Es ist de facto kein NAT der Produktivdaten im Tunnel. Das supportet Bintec als Consumersystem vermutlich gar nicht. Müsste man aber dann den Support fragen.
Zitat von @Dani:
Moin,
Moin,
Eventuell ein Bug in der NAT-Implementierung für IKEv2?
dafür wirst du den technischen Support von Bintec fragen müssen...Das habe ich mittlerweile gemacht. Bin gespannt, was dabei rauskommt...
Gruß, Christian
Hallo Christian,
wir stehen aktuell vor exakt dem gleichen Problem. Hat sich Bintec denn bei dir zurückgemeldet und habt ihr in der Zwischenzeit eine Lösung gefunden?
wir stehen aktuell vor exakt dem gleichen Problem. Hat sich Bintec denn bei dir zurückgemeldet und habt ihr in der Zwischenzeit eine Lösung gefunden?
Moin,
nein, Bintec hat sich nicht gemeldet. Ich hatte noch Kontakt zu einem Bintec-Supportprofi, der hat mir bestätigt, dass die Geräte dieses Feature nicht beherrschen - und Besserung ist nicht in Aussicht. Wir haben daher einen Umstieg zu einem Fortigate 40F gemacht, damit klappt das einwandfrei.
nein, Bintec hat sich nicht gemeldet. Ich hatte noch Kontakt zu einem Bintec-Supportprofi, der hat mir bestätigt, dass die Geräte dieses Feature nicht beherrschen - und Besserung ist nicht in Aussicht. Wir haben daher einen Umstieg zu einem Fortigate 40F gemacht, damit klappt das einwandfrei.
