VPN über IPv6

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi
wird denn sowas bei Lancom im Engineering nicht getestet?
Ich würde ja zumindest erwarten, dass man dort ausser einer direkten LAN-LAN Kopplung mit 2 Lancoms den CFG-Mode Server mit dem von Lancom propagierten Advanced VPN-Client testet und eine Aussage treffen kann, ob IPv4-Traffic in einem IPv6-VPN Tunnel funktioniert.
da das VPN nicht meine Baustelle ist, kann ich dir nicht sagen, was getestet wird und was nicht
Ehrlich gesagt fände ich es auch nicht zuviel verlangt, wenn man Interoperabilitätstests mit dem Windows 10/11 eigenen VPN-Client machen würde. Ich verstehe ja, dass das nicht mit jedem VPN-Client machbar ist, aber wie hoch ist der Marktanteil von Windows 10/11 Laptops? Ich glaube da adressiert man schon mal einen guten Teil der potenziellen CFG-Mode Server Nutzer.
soweit ich weiss, ist der Windows-Eigene Stack sehr beschränkt und ich wage daher fast zu bezweifeln, daß der überhaupt CFG-Mode kann... Microsoft propagiert lieber ihr eigenes proprietätres L2TP-over-IKEv2-Transport-Mode. Da braucht man keinen CFG-Mode...

aber wie gesagt: das ist nicht meine Baustelle

Gruß
Backslash
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Hallo backslash,

also was ich meinte ist natürlich Windows als VPN-Client eines Lancom im CFG-Mode Server. Und das kann der Windows-Eigene Stack ja sicher, denn sonst bekäme ich ja auch keine funktionierende, zertifikatbasierte VPN-Verbindung mit IPv4 über einen IPv4-VPN Tunnel zum laufen.

Verstehe schon, dass Du nicht für alle Features der Lancoms den Hut auf haben kannst. Das wäre schon ein bisschen übermenschlich. Aber vielleicht liest ja der ein oder andere aus dem Lancom Engineering hier im Forum mit - oder wenigstens die Produktmanager, zu deren Aufgabe ich das auf jeden Fall zählen würde - und kann zur Frage der prinzipiellen Funktionsfähigkeit von IPv4 in einem IPv6-VPN Tunnel eine Aussage treffen.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

So, mit dem Linux StrongSwan VPN-Client bekomme ich jetzt auch IPv4-Traffic über einen IPv6-Tunnel mit dem Lancom zum laufen.

Mir ist im Wireshark Capture auf dem Client:

Code: Alles auswählen

Frame 5: 150 bytes on wire (1200 bits), 150 bytes captured (1200 bits) on interface wlp3s0, id 0
Ethernet II, Src: Linux, Dst: Lancom
Internet Protocol Version 6, Src: 2a02:x:x:x:x:x:x:x, Dst: 2003:x:x:x:x:x:x:x
Encapsulating Security Payload
    ESP SPI: 0xda7b75f1 (3665524209)
    ESP Sequence: 81


Frame 6: 138 bytes on wire (1104 bits), 138 bytes captured (1104 bits) on interface wlp3s0, id 0
Ethernet II, Src: Lancom, Dst: Linux
Internet Protocol Version 6, Src: 2003:x:x:x:x:x:x:x, Dst: 2a02:x:x:x:x:x:x:x
User Datagram Protocol, Src Port: 4500, Dst Port: 48883
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    ESP SPI: 0xcfb4b111 (3484725521)
    ESP Sequence: 76
aufgefallen, dass die Pakete vom StrongSwan VPN-Client an den Lancom plain vanilla ESP, die vom Lancom an den VPN-Client aber UDP encapsulated IPsec Pakete sind. :shock:

Die ausgehandelte SA auf dem Lancom ist:

Code: Alles auswählen

> show vpn sadb-long

SA-REPORT

IKEv2 IKE SA: peer MY_VPN responder
  IKE transport:
    transport ID                  : 600497
    local                         : [2003:x:x:x:x:x:x:x]:4500
    remote                        : [2a02:x:x:x:x:x:x:x]:48883
    interface                     : T-DSL (switch port 0)
    routing-tag                   : 900
    PMTU                          : 1492
    encapsulation                 : UDP
    com-channel                   : 23 MTU-Offset 85
  IPsec transport:
    IP transport ID               : 600498
    encapsulation                 : IPv6 Hop-by-Hop Option (0)
  flags                         : 0x0010000101010010
                                  original-responder, initial-contact, authenticated, finalized, fragmentation-supported
  dead peer detection           : 31s
    Last liveness sign before   : 0s 0us
    Next DPD in                 : 1s
  NAT-T                         : Not detected. Peer supports NAT-T (draft mode)
  authentication:
    local                         : DIGITAL SIGNATURE:sha256WithRSAEncryption (14)
    remote                        : DIGITAL SIGNATURE:sha384WithRSAEncryption (14)
  identities:
    initiator                     : xxxx
    responder                     : xxxx
  lifetimes:
    time limit (hard limit)       : 86400 secs
    rekeying in (soft limit)      : 77670 secs
    hard time limit reached in    : 86310 secs
    volume limit (hard limit)     : 2000000 kbyte
    rekeying in (soft limit)      : 1800000 kbyte
    used volume                   : 2 kbyte
  Encryption                    : AES-CBC-256
  Integrity                     : AUTH-HMAC-SHA-512
  IKE-DH-Group                  : 14
  PRF                           : PRF-HMAC-SHA-512
  SPIs:
    initiator                     : 2089FA6AA24D1AE8
    responder                     : 353BB6B0D2F734EC
  config server:
     Assigned IPv4 Address         : 10.1.200.107
     Assigned IPv4 DNS Servers     : 10.1.0.1

IKEv2 CHILD SA: peer MY_VPN, rule IPSEC-0-MY_VPN-PR0-L0-R0 responder
  IKE transport:
    transport ID                  : 600497
    local                         : [2003:x:x:x:x:x:x:x]:4500
    remote                        : [2a02:x:x:x:x:x:x:x]:48883
    interface                     : T-DSL (switch port 0)
    routing-tag                   : 900
    PMTU                          : 1492
    encapsulation                 : UDP
    com-channel                   : 23 MTU-Offset 85
  IPsec transport:
    IP transport ID               : 600498
    encapsulation                 : IPv6 Hop-by-Hop Option (0)
  flags                         : 0x0000000100000000
                                  original-responder, finalized
  IKE rule traffic selector     : 0.0.0.0/0 ANY ANY <-> 10.1.200.107 ANY ANY
  IPsec SA traffic selector     : 0.0.0.0/0 <-> 10.1.200.107/32
  lifetimes:
    time limit (hard limit)       : 14400 secs
    rekeying in (soft limit)      : 12870 secs
    hard time limit reached in    : 14310 secs
    volume limit (hard limit)     : 2000000 kbyte
    rekeying in (soft limit)      : 1800000 kbyte
    used volume                   : 12 kbyte
  Authenticated-Encryption      : AES-GCM-16-256
  PFS-DH-Group                  : None
  ESN                           : None
  SPIs:
    incoming                      : DA7B75F1
    outgoing                      : CFB4B111
Da steht also 'encapsulation : UDP'.

Während die SA auf dem Linux Client so aussieht:

Code: Alles auswählen

ip -s xfrm state
src 2a02:x:x:x:x:x:x:x dst 2003:x:x:x:x:x:x:x
	proto esp spi 0xda7b75f1(3665524209) reqid 1(0x00000001) mode tunnel
	replay-window 0 seq 0x00000000 flag af-unspec (0x00100000)
	aead rfc4106(gcm(aes)) 0x.... (288 bits) 128
	lastused 2023-03-17 17:58:09
	anti-replay context: seq 0x0, oseq 0x42, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF)(bytes), hard (INF)(bytes)
	  limit: soft (INF)(packets), hard (INF)(packets)
	  expire add: soft 10016(sec), hard 10800(sec)
	  expire use: soft 0(sec), hard 0(sec)
	lifetime current:
	  4986(bytes), 66(packets)
	  add 2023-03-17 17:56:28 use 2023-03-17 17:56:28
	stats:
	  replay-window 0 replay 0 failed 0
src 2003:x:x:x:x:x:x:x dst 2a02:x:x:x:x:x:x:x
	proto esp spi 0xcfb4b111(3484725521) reqid 1(0x00000001) mode tunnel
	replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
	aead rfc4106(gcm(aes)) 0x.... (288 bits) 128
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF)(bytes), hard (INF)(bytes)
	  limit: soft (INF)(packets), hard (INF)(packets)
	  expire add: soft 9979(sec), hard 10800(sec)
	  expire use: soft 0(sec), hard 0(sec)
	lifetime current:
	  0(bytes), 0(packets)
	  add 2023-03-17 17:56:28 use -
	stats:
	  replay-window 0 replay 0 failed 0
Da ist von encapsulation keine Rede.

Dementsprechend schickt der StrongSwan VPN-Client plain vanilla ESP Pakete an den Lancom. Der Linux Kernel verarbeitet anders herum aber keine UDP gekapselten ESP Pakete vom Lancom, da dies in seiner SA nicht vorgesehen ist. Sollte er das trotzdem tun? :G)

Der Lancom hingegen akzeptiert und verarbeitet offenbar auch die ESP Pakete ohne Kapselung vom StrongSwan VPN-Client, obwohl seine SA encapsulation vorsieht. Ist das OK? :G)

Warum stellen hier Client und Server überhaupt erfolgreich eine VPN-Verbindung her, wenn sie sich in ihren SAs bezüglich der encapsulation nicht einig sind? :?

Zum Glück kann man in der Konfiguration des StrongSwan VPN-Client die encapsulation forcieren.
Dann sieht die SA auf dem Linux Client wie folgt aus:

Code: Alles auswählen

ip -s xfrm state
src 2a02:x:x:x:x:x:x:x dst 2003:x:x:x:x:x:x:x
	proto esp spi 0xc91e5dda(3374210522) reqid 1(0x00000001) mode tunnel
	replay-window 0 seq 0x00000000 flag af-unspec (0x00100000)
	aead rfc4106(gcm(aes)) 0x.... (288 bits) 128
	encap type espinudp sport 46106 dport 4500 addr ::
	lastused 2023-03-17 19:29:26
	anti-replay context: seq 0x0, oseq 0x1f, bitmap 0x00000000
	lifetime config:
	  limit: soft (INF)(bytes), hard (INF)(bytes)
	  limit: soft (INF)(packets), hard (INF)(packets)
	  expire add: soft 10074(sec), hard 10800(sec)
	  expire use: soft 0(sec), hard 0(sec)
	lifetime current:
	  2748(bytes), 31(packets)
	  add 2023-03-17 19:29:05 use 2023-03-17 19:29:06
	stats:
	  replay-window 0 replay 0 failed 0
src 2003:x:x:x:x:x:x:x dst 2a02:x:x:x:x:x:x:x
	proto esp spi 0xc47b287e(3296405630) reqid 1(0x00000001) mode tunnel
	replay-window 32 seq 0x00000000 flag af-unspec (0x00100000)
	aead rfc4106(gcm(aes)) 0x.... (288 bits) 128
	encap type espinudp sport 4500 dport 46106 addr ::
	lastused 2023-03-17 19:29:24
	anti-replay context: seq 0xf, oseq 0x0, bitmap 0x00007fff
	lifetime config:
	  limit: soft (INF)(bytes), hard (INF)(bytes)
	  limit: soft (INF)(packets), hard (INF)(packets)
	  expire add: soft 10072(sec), hard 10800(sec)
	  expire use: soft 0(sec), hard 0(sec)
	lifetime current:
	  2181(bytes), 15(packets)
	  add 2023-03-17 19:29:05 use 2023-03-17 19:29:06
	stats:
	  replay-window 0 replay 0 failed 0
Die SA hat jetzt also 'encap type espinudp', die ESP Pakete an den Lancom werden schön in UDP verpackt und alles ist paletti. :D

Leider hab' ich bis jetzt noch keine Möglichkeit gefunden dem nativen Windows VPN-Client mitzuteilen die UDP encapsulation zu forcieren.
Das Problem ist also bisher nur für Linux, nicht aber auf der Windows Seite gelöst.

Weiss vielleicht jemand ob es da in Windows irgendeinen Registry Key, magic PowerShell Befehl oder sonst was gibt?

Ansonsten wäre es sehr hilfreich, wenn man die UDP encapsulation bei IPv6 unabhängig von IPv4 auch abschalten könnte.
Oder gibt es die Möglichkeit vielleicht irgendwie schon?

Warum es sinnvoll sein kann bei IPv6 überhaupt NAT zu fahren steht ja schon in diesem Beitrag fragen-zum-thema-vpn-f14/nat-trotz-ipv6-t19230.html.
Das ist aber kein Grund dafür es nicht abschalten zu können. :(
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

Frühstücksdirektor hat geschrieben: 14 Mär 2023, 15:21 Der LANCOM unterstützt in der aktuellen Firmware den Betrieb als CFG-Mode Server nicht im Dual Stack Betrieb. Derzeit geht nur Single Stack, d.h. entweder IPv4 ODER IPv6 als CFG-Moder Server. Das gilt nur für den CFG-Mode.
Sorry wenn ich dein Thread kurz entführe, interessiert mich aber und passt teilweise:

Unterstützt der Lancom Dualstack im CFG-Client Modus? Oder gelten die gleichen Einschränkungen wie im Serverbetrieb?
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

geppi hat geschrieben: 17 Mär 2023, 19:56 Der Lancom hingegen akzeptiert und verarbeitet offenbar auch die ESP Pakete ohne Kapselung vom StrongSwan VPN-Client, obwohl seine SA encapsulation vorsieht. Ist das OK? :G)
Ich wollte das jetzt auch einmal sehen. Mein iPhone gegen den Lancom Router via v6. Und siehe da, gleiches Szenario wie bei dir, iPhone>Lancom ESP, Lancom>iPhone 4500 UDP.

Ich denke, der Lancom hat einen Bug:

Code: Alles auswählen

Looking for payload NOTIFY(DETECTION_SOURCE_IP) (41)...Found 1 payload.
  +Computing SHA1(0xFC8FE66792[..]:500)
  +Computing SHA1(0xFC8FE66792[..]
  +Computed: 0xD63623E33[..]
  +Received: 0xD63623E33[..]
  +Equal => NAT-T is disabled

Looking for payload NOTIFY(DETECTION_DESTINATION_IP) (41)...Found 1 payload.
  +Computing SHA1(0xFC8FE667[..]:500)
  +Computing SHA1(0xFC8FE667[..])
  +Computed: 0x21F153B3[..]
  +Received: 0x21F153B3[..]
  +Equal => NAT-T is disabled

Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled
Und ganz am Ende des Traces steht:

Code: Alles auswählen

NAT-T enabled. We are not behind a nat, the remote side is not behind a nat
Man wird echt betriebsblind, wenn man nach Stundenlanger Arbeit ein solches Szenario zum Laufen bekommt mittels Debugging und dann direkt alles fallen lässt, sobald Pakete übertragen werden.

Das witzige ist, selbst wenn man NAT-T am Lancom deaktiviert, so verwendet der Router weiterhin NAT-T. Ich schätze, set /Setup/VPN/NAT-T-Operating no greift nur für IKEv1. Im Menu-Referenzhandbuch steht allerdings keine Einschränkung auf eine Version.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: VPN über IPv6

Beitrag von tstimper »

Dr.Einstein hat geschrieben: 18 Mär 2023, 00:18
Ich denke, der Lancom hat einen Bug:
....

Und ganz am Ende des Traces steht:

Code: Alles auswählen

NAT-T enabled. We are not behind a nat, the remote side is not behind a nat
Man wird echt betriebsblind, wenn man nach Stundenlanger Arbeit ein solches Szenario zum Laufen bekommt mittels Debugging und dann direkt alles fallen lässt, sobald Pakete übertragen werden.

Das witzige ist, selbst wenn man NAT-T am Lancom deaktiviert, so verwendet der Router weiterhin NAT-T. Ich schätze, set /Setup/VPN/NAT-T-Operating no greift nur für IKEv1. Im Menu-Referenzhandbuch steht allerdings keine Einschränkung auf eine Version.
Hast Du mal getestet, ob das Setting set /Setup/VPN/NAT-T-Operating no nach einen Router Reboot auch für IKEv2 greift?
Oder ob z.B. das Trennen der WAN Verbindung zum Wirksamwerden des Settings führt?
Oder ob Disable / Enable von IPv6 hilft?

Also irgendwas, was den IPv6 Stack neu initialisiert und die Soll Config neu einliest?

Offensichtlich wirkt sich set /Setup/VPN/NAT-T-Operating no bei IKEv2 zusammen mit IPv6 nicht auf den IST Zustand aus.

Oder ist das etwa bei IKEv2 und IPv4 auch so oder ist es da gleich wirksam?

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Wenn ich es richtig verstehe, würde sich dieses Setting aber, so es denn irgendwie auch für IKEv2 funktionieren würde, generell auf alle VPN-Verbindungen auswirken. Bei IPv4 wird aber in den allermeisten Fällen NAT-T gebraucht. Dann hätte man zwar einen funktionierenden IPv6-Tunnel aber mit IPv4 würde is nicht mehr funktionieren.

Man müsste NAT-T schon dediziert für IPv6 abstellen können, wo es abgesehen von MOBIKE auch nicht gebraucht wird.

Allerdings gäbe es das Problem auch gar nicht, wenn sich Server und Client darauf einigen könnten was jetzt gefahren wird.
Mich wundert, dass das beim Aufbau der SAs kein zwingender Bestandteil ist. Oder ist es das? Dann wäre es auch ein Bug.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

tstimper hat geschrieben: 18 Mär 2023, 09:55 Hast Du mal getestet, ob das Setting set /Setup/VPN/NAT-T-Operating no nach einen Router Reboot auch für IKEv2 greift?
Kaltstart, kein Unterschied.
geppi hat geschrieben: 18 Mär 2023, 11:20 Wenn ich es richtig verstehe, würde sich dieses Setting aber, so es denn irgendwie auch für IKEv2 funktionieren würde, generell auf alle VPN-Verbindungen auswirken. Bei IPv4 wird aber in den allermeisten Fällen NAT-T gebraucht. Dann hätte man zwar einen funktionierenden IPv6-Tunnel aber mit IPv4 würde is nicht mehr funktionieren.
Schon klar. War ja nur ein Test von mir, ob man das irgendwie erzwingen kann. Entweder ist der Schalter mittlerweile nur Deko geworden oder ergreift nur für IKEv1. Ich kann mich noch an Zeiten erinnern, wo NAT-T im Default deaktiviert war und beim Support stapelweise Case aufgemacht wurden wegen VPN-Problemen. Und eine Einstellung pro Tunnel würde auch nicht genügen. Immerhin sorgt Dual Stack dafür, dass bei Verfügbarkeit der Tunnel über v6 aufgebaut wird. Aber in vielen Hotels zB gibt's nur WANv4, d.h. der Tunnel würde dann über v4 aufgebaut werden. Ich schätze, hier liegt wirklich ein Bug im VPN Stack vor.
Zuletzt geändert von Dr.Einstein am 18 Mär 2023, 12:56, insgesamt 1-mal geändert.
tstimper
Beiträge: 956
Registriert: 04 Jun 2021, 15:23
Wohnort: Chemnitz
Kontaktdaten:

Re: VPN über IPv6

Beitrag von tstimper »

Dr.Einstein hat geschrieben: 18 Mär 2023, 11:31
tstimper hat geschrieben: 18 Mär 2023, 09:55 Hast Du mal getestet, ob das Setting set /Setup/VPN/NAT-T-Operating no nach einen Router Reboot auch für IKEv2 greift?
Kaltstart, kein Unterschied.
geppi hat geschrieben: 18 Mär 2023, 11:20 Wenn ich es richtig verstehe, würde sich dieses Setting aber, so es denn irgendwie auch für IKEv2 funktionieren würde, generell auf alle VPN-Verbindungen auswirken. Bei IPv4 wird aber in den allermeisten Fällen NAT-T gebraucht. Dann hätte man zwar einen funktionierenden IPv6-Tunnel aber mit IPv4 würde is nicht mehr funktionieren.
Dr.Einstein hat geschrieben: 18 Mär 2023, 11:31 Ich schätze, hier leigt wirklich ein Bug im VPN Stack vor.
backslash hat geschrieben: 15 Mär 2023, 13:38 ja, aber mir wurde mitlerweile mitgeteilt, daß der Dual-Stack Config-Mode tatsächlich erst mit einer 10.80 funktionieren wird - hätte ich persönlich nicht mit gerechnet...
Wir brauchen wirklich verlässliche Infos über nutzbare Funktionen und bekannte Bugs.

Viele Grüße

ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: VPN über IPv6

Beitrag von GrandDixence »

Als Vorbereitung auf die Unterstützung von MOBIKE sollte sowieso jeder VPN-Client mit Einwahlverbindung (RAS) standardmässig NAT-Traversal verwenden (also UDP Encapsulation über Serverport UDP 4500). Egal ob mit oder ohne NAT-Komponente im Netzwerkpfad vom VPN-Client zu VPN-Server. Siehe dazu Seite 3 unter:
https://www.heise.de/security/artikel/E ... 70056.html

RFC7296 informiert gerne über die korrekte Anwendung von NAT-Traversal im VPN-Client und VPN-Server. Siehe Kapitel 2.23.
https://www.rfc-editor.org/rfc/rfc7296

Hier ein Müsterchen:
An initiator can use port 4500 for both IKE and ESP, regardless of
whether or not there is a NAT, even at the beginning of IKE. When
either side is using port 4500, sending ESP with UDP encapsulation is
not required, but understanding received UDP-encapsulated ESP packets
is required. UDP encapsulation MUST NOT be done on port 500. If
Network Address Translation Traversal (NAT-T) is supported (that is,
if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
all devices MUST be able to receive and process both UDP-encapsulated
ESP and non-UDP-encapsulated ESP packets at any time. Either side
can decide whether or not to use UDP encapsulation for ESP
irrespective of the choice made by the other side. However, if a NAT
is detected, both devices MUST use UDP encapsulation for ESP.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

GrandDixence hat geschrieben: 20 Mär 2023, 13:58 Als Vorbereitung auf die Unterstützung von MOBIKE sollte sowieso jeder VPN-Client mit Einwahlverbindung (RAS) standardmässig NAT-Traversal verwenden (also UDP Encapsulation über Serverport UDP 4500).
Kannst du das bitte erläutern? RFC 4555 widerspricht deiner Aussage.
In some MOBIKE scenarios, the network may contain NATs or stateful packet filters (for brevity, the rest of this document simply describes NATs). The NAT Traversal feature specified in [IKEv2] allows IKEv2 to work through NATs in many cases, and MOBIKE can leverage this functionality: when the addresses used for IPsec SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as needed.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: VPN über IPv6

Beitrag von GrandDixence »

Ja, gemäss RFC 4555 ist für MobIKE nur der Einsatz des Serverport UDP 4500 vorgeschrieben. "UDP Encapsulation" ist nicht zwingend erforderlich für NAT-freie Netzwerkpfade. Man lernt nie aus...
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Es wäre schon wünschenswert von Lancom Seite eine Stellungnahme zur geschilderten Problematik zu bekommen.

Der VPN Verbindungsaufbau sieht ja bei einem IPv6-Tunnel u.a. meist so aus:

Code: Alles auswählen

[VPN-Status]....
....
Received 3 notifications: 
  +IKEV2_FRAGMENTATION_SUPPORTED (STATUS)
  +NAT_DETECTION_SOURCE_IP(0xCA8AC06B027516214439577FC3AFEDB1A7FB2C0F) (STATUS)
  +NAT_DETECTION_DESTINATION_IP(0x0D54ABBAE59F6D5D1D0CD60B88860962D7F8E110) (STATUS)
Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled
....
Trotzdem wird immer ESP über UDP encapsulation gefahren.

Wird es bitte eine Möglichkeit geben das abzustellen? :M

Wenn nicht, wenn also partout immer UDP encapsulation gefahren werden soll, würde es doch zumindest nichts schaden dem Gegenüber vorzugaukeln, das man sich hinter einer NAT befindet, indem man einen modifizierten ''NAT_DETECTION_SOURCE_IP Wert sendet, damit dort auf jeden Fall auch UDP encapsulation aktiviert wird.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,

das kann ich nicht nachvollziehen...
Bist du sicher, daß du in deiner Konfig in den für die Verbindung (VPN -> IKEv2/IPSec -> Verbindungs-Liste) genutzen "Verbindungs-Parametern" (VPN -> IKEv2/IPSec -> Verbindungs-Parameter) die "Encapsulation" auf "keine" stehen hast?


Gruß
Backslash
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VPN über IPv6

Beitrag von Dr.Einstein »

backslash hat geschrieben: 24 Mär 2023, 12:54 Bist du sicher, daß du in deiner Konfig in den für die Verbindung (VPN -> IKEv2/IPSec -> Verbindungs-Liste) genutzen "Verbindungs-Parametern" (VPN -> IKEv2/IPSec -> Verbindungs-Parameter) die "Encapsulation" auf "keine" stehen hast?
Bin zwar nicht geppi, aber bei meiner iPhone Verbindung ist Encapsulation auf "Keine", wobei die LanConfig Hilfe hier fälschlicherweise auf "none" verweist.
Antworten