VPN über IPv6

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

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

Re: VPN über IPv6

Beitrag von geppi »

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?
Yep, bin ich.

Code: Alles auswählen

ls /Setup/VPN/IKEv2/General/

Name                  DPD-Inact-Timeout  Encapsulation  Destination-Port
======================--------------------------------------------------
DEFAULT               30                 None           0
Ich hab' aus lauter "Verzweiflung" sogar mal testweise einen neuen Parametersatz mit anderem Namen aber den gleichen Parametern erstellt und meiner VPN-Gegenstelle in der Verbindungsliste zugeordnet, in der Hoffnung, dass das LCOS das "keine" bei "Encapsulation" vielleicht berücksichtigt wenn man nicht die "DEFAULT" Parameter nimmt, sondern explizit einen eigenen Satz anlegt. Ergebnis leider negativ.

Wie ich geschrieben habe, das LCOS macht bei einem VPN Tunnel über IPv6 immer UDP-Encapsulation in Richtung des Clients, verdaut interessanter Weise aber selbst die plain vanilla ESP Pakete vom Windows Client. :shock:

Bis jetzt ist mir keine Möglichkeit bekannt die UDP-Encapsulation im Lancom Router bei einem VPN-Tunnel über IPv6 abzustellen.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,

das Problem ist, daß ich genau das ausprobiert habe (also IPv6 als Transport-Protokoll) und das LANCOM die ESP-Pakete nicht in UDP eingepackt hat...

Hat dein Client während der IKE-Verhandlung vielleicht den Port 500 verlasen hat und ist auf Port 4500 gewechselt?
Das kannst du im VPN-IKE-Trace sehen (oder mit einem Wireshark mitschneiden)

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

Re: VPN über IPv6

Beitrag von Dr.Einstein »

Code: Alles auswählen

[VPN-Debug] 2023/03/18 00:03:01,067
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1220 bytes (encrypted)
Gateways: [2003:e.......]:500<--[2a01:598:b1a4:7b.............]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
Payloads: ENCRYPTED_FRAGMENT
QUB-DATA: [2003:e..........]:4500<---[2a01:598:b1...............]:4500 rtg_tag 0 physical-channel WAN(1)
transport: [id: 25, UDP (17) {incoming unicast, fixed source address}, dst: 2a01:598:b............., tag 0 (U), src: 2003:eb:5f0b..............., hop limit: 255, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, (R) iface: INTERNET-DEFAULT (3), next hop: fe80:.........], local port: 500, remote port: 500
+IKE_SA found and assigned
Message verified successfully

[VPN-Status] 2023/03/18 00:03:01,068
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1220 bytes (encrypted)
Gateways: [2003:eb:5..........]:500<--[2a01:598:b1a.............]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
Ikev2 Fragment Number/Total: 1/3

[VPN-Debug] 2023/03/18 00:03:01,069
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1220 bytes (encrypted)
Gateways: [2003:e............]:500<--[2a01:598:b...........]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
Payloads: ENCRYPTED_FRAGMENT
QUB-DATA: [2003:eb:5f0b............]:4500<---[2a01:598:b1..........]:4500 rtg_tag 0 physical-channel WAN(1)
transport: [id: 25, UDP (17) {incoming unicast, fixed source address}, dst: 2a01:598:b1............., tag 0 (U), src: 2003:eb:5............, hop limit: 255, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, (R) iface: INTERNET-DEFAULT (3), next hop: fe80............], local port: 500, remote port: 500
+IKE_SA found and assigned
Message verified successfully

[VPN-Status] 2023/03/18 00:03:01,069
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1220 bytes (encrypted)
Gateways: [2003:eb:5f0..........]:500<--[2a01:598:b...........]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
Ikev2 Fragment Number/Total: 2/3

[VPN-Debug] 2023/03/18 00:03:01,071
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 116 bytes (encrypted)
Gateways: [2003:eb:5f............]:500<--[2a01:59..........]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
Payloads: ENCRYPTED_FRAGMENT
QUB-DATA: [2003:eb:..........]:4500<---[2a01:598:b1a4:7b6..........]:4500 rtg_tag 0 physical-channel WAN(1)
transport: [id: 25, UDP (17) {incoming unicast, fixed source address}, dst: 2a01:598:b1a........., tag 0 (U), src: 2003:eb:5..........., hop limit: 255, DSCP: CS6, ECN: Not-ECT, pmtu: 1492, (R) iface: INTERNET-DEFAULT (3), next hop: fe80::3631....], local port: 500, remote port: 500
+IKE_SA found and assigned
Message verified successfully
IKEv2-Fragment 1/3 decrypted successfully
IKEv2-Fragment 2/3 decrypted successfully
IKEv2-Fragment 3/3 decrypted successfully

[VPN-Status] 2023/03/18 00:03:01,085
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 2359 bytes
Gateways: [2003:eb:5f0b:ee0.........]:500<--[2a01:598:b1a4:7b6....]:500
SPIs: 0x583395696A940FD3776FCED0CBD443C1, Message-ID 1
CHILD_SA ('', '' ) entered to SADB
Switching to local port 4500 and remote port 4500
Received 4 notifications: 
  +INITIAL_CONTACT (STATUS)
  +ESP_TFC_PADDING_NOT_SUPPORTED (STATUS)
  +NON_FIRST_FRAGMENTS_ALSO (STATUS)
  +MOBIKE_SUPPORTED (STATUS)
+Received-ID C=de,CN=vpn-...:FQDN matches the Expected-ID C=de,CN=vpn-...:FQDN
+Peer identified: IPHONE-CERT
+Peer uses AUTH(RSA:SHA1)
+Authentication successful
IKE_SA ('IPHONE-CERT', 'ISAKMP-PEER-IPHONE-CERT' IPSEC_IKE SPIs 0x583395696A940FD3776FCED0CBD443C1) removed from SADB
IKE_SA ('IPHONE-CERT', 'ISAKMP-PEER-IPHONE-CERT' IPSEC_IKE SPIs 0x583395696A940FD3776FCED0CBD443C1) entered to SADB
Request attributes:
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP4_NETMASK()
  INTERNAL_IP4_DHCP()
  INTERNAL_IP4_DNS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP6_DHCP()
  INTERNAL_IP6_DNS()
  INTERNAL_DNS_DOMAIN()
Assigned IPv4 config parameters:
  IP:  192.168.15.164
  DNS: 0.0.0.0, 0.0.0.0
TSi: (  0,     0-65535,         0.0.0.0-255.255.255.255)
TSr: (  0,     0-65535,         0.0.0.0-255.255.255.255)
+CHILD-SA:
  ESP-Proposal-1 Peer-SPI: 0x0E85DAFA (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE
  ESP-Proposal-2 Peer-SPI: 0x0512AA30 (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE
  ESP-Proposal-3 Peer-SPI: 0x00094328 (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE
  ESP-Proposal-4 Peer-SPI: 0x0B587F18 (3 transforms)
    ENCR : AES-CBC-128
    INTEG: HMAC-SHA1
    ESN  : NONE
  ESP-Proposal-5 Peer-SPI: 0x0D42111D (3 transforms)
    ENCR : 3DES
    INTEG: HMAC-SHA1
    ESN  : NONE
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Ich hab' auch mal mein Tracefile eines VPN Verbindungsaufbaus über IPv6 angehängt.

@backslash
Wie sehen denn Deine SAs auf dem Lancom und dem Client aus?
Meine hatte ich ja hier fragen-zum-thema-vpn-f14/vpn-ueber-ipv6 ... ml#p112996 schon mal gepostet.

Mit dem Windows 10 native VPN-Client ist das genauso. Wenn man sich auf dem Windows Client mit 'Get-NetIPsecMainModeSA -All' die Security Association anzeigen lässt, haben sowohl die Zeile mit 'LocalUdpEncapsulationPort' als auch mit 'RemoteUdpEncapsulationPort' keinen Wert eingetragen. Die SA auf dem Lancom aber sehr wohl für 'IKE transport' den Wert 'encapsulation : UDP'.

Wobei, warte mal, weiter unten steht bei 'IPsec transport' der Wert 'encapsulation : IPv6 Hop-by-Hop Option (0)'. Was bedeutet das denn? :G)

Der Wireshark Mitschnitt des Verbindungsaufbaus zeigt jedenfalls, dass der erste IKA_SA_INIT Request und die Response über UDP Port 500 ablaufen. Dann kommt ein auf 4 Pakete verteilter IKE_AUTH Request vom Client über UDP Port 4500 und die über zwei Pakete verteilte Response vom Lancom ebenfalls über UDP Port 4500.

Danach gibt es aber nur noch plain vanilla ESP Pakete vom Client an den Lancom und UDP encapsulated ESP über Port 4500 vom Lancom an den Client wie schon im obern erwähnten Post gezeigt.

-
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: VPN über IPv6

Beitrag von GrandDixence »

Das erste IKE-Telegramm (IKE-SA_INIT) vom IPv6-VPN-Tunnelaubau wird mit Routing-Tag 900 und mit der Zuordnung zur VPN-Gegenstelle "DEFAULT" empfangen. Korrekt wäre aber Routing-Tag 0 und die Zuordnung zur VPN-Gegenstelle "UNKNOWN". Siehe auch:
fragen-zum-thema-vpn-f14/ikev2-vpn-mit- ... ml#p113105

IPv4
----------------------------------------------------------------

Code: Alles auswählen

[VPN-IKE] 2017/07/20 21:31:16,487
[<UNKNOWN>] Received packet:
IKE 2.0 Header:
Source/Port         : 80.187.118.190:19829
Destination/Port    : 80.143.218.108:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : BD 4F C5 92 05 66 ED 42
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT

IPv6
----------------------------------------------------------------

Code: Alles auswählen

[VPN-IKE] 2023/03/25 09:17:17,487  Devicetime: 2023/03/25 09:17:17,480
[DEFAULT] Received packet:
IKE 2.0 Header:
Source/Port         : [2a02:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:500
Destination/Port    : [2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx]:500
Routing-tag         : 900
Com-channel         : 0
| Initiator cookie  : 26 F7 B3 31 35 81 6A B6
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
Bei Dr. Einstein sehe ich auch nur Routing-Tag 0. => Da gibt es offenbar noch eine bisher verschwiegene Vorgeschichte im IPv6- und Routingtabellenbereich...

Zu "Hop-By-Hop Options" siehe Wikipedia, Kapitel "Header-Format":
https://de.wikipedia.org/wiki/IPv6#Header-Format
Zuletzt geändert von GrandDixence am 25 Mär 2023, 12:39, insgesamt 1-mal geändert.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

GrandDixence hat geschrieben: 25 Mär 2023, 12:27 Das IKE-SA_INIT-Telegramm vom IPv6-VPN-Tunnelaubau wird mit Routing-Tag 900 und mit der Zuordnung zur VPN-Gegenstelle "DEFAULT" empfangen. Korrekt wäre aber Routing-Tag 0 und die Zuordnung zur VPN-Gegenstelle "UNKNOWN".
....
Bei Dr. Einstein sehe ich auch nur Routing-Tag 0. => Da gibt es offenbar noch eine bisher verschwiegene Vorgeschichte...
Die Vorgeschichte steht hier: fragen-zum-thema-vpn-f14/vpn-ueber-ipv6 ... ml#p112840

Hat das irgendwelche Auswirkungen auf die UDP Encapsulation der ESP Pakete?
GrandDixence hat geschrieben: 25 Mär 2023, 12:27 Zu "Hop-By-Hop Options" siehe Wikipedia, Kapitel "Header-Format":
https://de.wikipedia.org/wiki/IPv6#Header-Format
Das hat dann wohl auch nichts mit der UDP encapsulation der ESP Pakete zu tun, oder?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,


was soll ich sagen..

Das erste Paket (IKE-SA-INIT init) kommt vom Client an Port 500:

Code: Alles auswählen

[VPN-IKE] 2023/03/25 09:17:17,487  Devicetime: 2023/03/25 09:17:17,480
[DEFAULT] [VPN-IKE] 2023/03/25 09:17:17,487  Devicetime: 2023/03/25 09:17:17,480
[DEFAULT] Received packet:
IKE 2.0 Header:
Source/Port         : [2a02:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:500
Destination/Port    : [2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx]:500
Routing-tag         : 900
Com-channel         : 0
| Initiator cookie  : 26 F7 B3 31 35 81 6A B6
| Responder cookie  : 00 00 00 00 00 00 00 00
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x08   Initiator
darauf antwortet das LANCOM (IKE-SA-INIT Respose) auch an Port 500:

Code: Alles auswählen

[VPN-IKE] 2023/03/25 09:17:17,502  Devicetime: 2023/03/25 09:17:17,493
[DEFAULT][VPN-IKE] 2023/03/25 09:17:17,502  Devicetime: 2023/03/25 09:17:17,493
[DEFAULT] Sending packet:
IKE 2.0 Header:
Source/Port         : [2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx]:500
Destination/Port    : [2a02:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:500
Routing-tag         : 900
Com-channel         : 0
| Initiator cookie  : 26 F7 B3 31 35 81 6A B6
| Responder cookie  : 48 B8 CE BA 6B A7 D3 9F
| Next Payload      : SA
| Version           : 2.0
| Exchange type     : IKE_SA_INIT
| Flags             : 0x20 Response  
irgendwas bringt den Client dann dazu, das nächste Paket an Port 4500 zu schicken:

Code: Alles auswählen

[VPN-IKE] 2023/03/25 09:17:17,596  Devicetime: 2023/03/25 09:17:17,646
[DEFAULT] Received packet:
IKE 2.0 Header:
Source/Port         : [2a02:xxxx:xxx:xxxx:xxxx:xxxx:xxxx:xxxx]:4500
Destination/Port    : [2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx]:4500
Routing-tag         : 900
Com-channel         : 0
| Initiator cookie  : 26 F7 B3 31 35 81 6A B6
| Responder cookie  : 48 B8 CE BA 6B A7 D3 9F
| Next Payload      : ENCRYPTED_FRAGMENT
woraufhin das LANCOM wohl davon ausgeht, daß UDP Encapsulation gemacht werden soll...

Die Frage ist: warum macht dein Client das? Das müßtest du schon auf dem Client tracen...

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

Re: VPN über IPv6

Beitrag von Dr.Einstein »

Findest du es nicht komisch, dass scheinbar alle größeren Anbieter wie iOS, Windows, Google genau dieses Verfahren über v6 machen, danach aber ordentlich ESP verwenden? D.h. es gibt eine proprietäre Implementierung im Lancom, wenn irgendwas über 4500 UDP kommt, dann ignoriere alles, was zum Thema NAT Detection ausgehandelt wurde?

Die RFC für MOBIKE z.B. definiert doch nur, dass der Lancom auf beiden Ports lauschen muss. Von einem Verfahren, wenn 4500 dann UDP Encapsulierung steht da nichts oder habe ich dies übersehen?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi Dr.Einstein

wie ich schon in einem vorherigen Post gesagt habe: das ist nicht meine Baustelle..

ansonsten kann ich nur hierauf verweisen: https://en.wikipedia.org/wiki/NAT_traversal
IPsec virtual private network clients use NAT traversal in order to have Encapsulating Security Payload packets traverse NAT. IPsec uses several protocols in its operation which must be enabled to traverse firewalls and network address translators:
  • nternet Key Exchange (IKE) – User Datagram Protocol (UDP) port 500
  • Encapsulating Security Payload (ESP) – IP protocol number 50
  • Authentication Header (AH) – IP protocol number 51
  • IPsec NAT traversal – UDP port 4500, if and only if NAT traversal is in use
da steht explizit, daß der Port 4500 nur genutzt wird, wenn NAT-T auch aktiv ist, d.h. sobald auf den Port 4500 gewechselt wird, ist auch UDP-Encapsulation angesagt...

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

Re: VPN über IPv6

Beitrag von geppi »

Dr.Einstein hat geschrieben: 27 Mär 2023, 12:11 Findest du es nicht komisch, dass scheinbar alle größeren Anbieter wie iOS, Windows, Google genau dieses Verfahren über v6 machen, danach aber ordentlich ESP verwenden? D.h. es gibt eine proprietäre Implementierung im Lancom, wenn irgendwas über 4500 UDP kommt, dann ignoriere alles, was zum Thema NAT Detection ausgehandelt wurde?
Auch StronSwan als Linux VPN-Client verhält sich so. Mein Tracefile war ja von einem nativen Windows 10 Client. Ich hab's aber gerade nochmal überprüft und der StrongSwan liefert exakt das gleiche Ergebnis.
backslash hat geschrieben: 27 Mär 2023, 13:59 ansonsten kann ich nur hierauf verweisen: https://en.wikipedia.org/wiki/NAT_traversal
IPsec virtual private network clients use NAT traversal in order to have Encapsulating Security Payload packets traverse NAT. IPsec uses several protocols in its operation which must be enabled to traverse firewalls and network address translators:
  • nternet Key Exchange (IKE) – User Datagram Protocol (UDP) port 500
  • Encapsulating Security Payload (ESP) – IP protocol number 50
  • Authentication Header (AH) – IP protocol number 51
  • IPsec NAT traversal – UDP port 4500, if and only if NAT traversal is in use
da steht explizit, daß der Port 4500 nur genutzt wird, wenn NAT-T auch aktiv ist, d.h. sobald auf den Port 4500 gewechselt wird, ist auch UDP-Encapsulation angesagt...
Nun ist ja Wikipedia nicht gerade das definierende Standard-Dokument, aber Standard hin oder her, ich schließe mich Dr. Einstein an. Hier scheint der Lancom jedenfalls ein "Alleinstellungsmerkmal" zu haben. Pragmatisch und Kundenfreundlich fände ich es, wenn wenigstens die Möglichkeit geschaffen würde dieses Verhalten umzustellen.

@ backslash
Könntest Du es vielleicht bitte als RFE eingeben?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,

laut strongswan-doku wechselt stronswan auch ohne NAT-T auf Port 4500, wenn MOBIKE aktiv ist:

https://docs.strongswan.org/docs/5.9/fe ... ersal.html

Damit ist die Lösung: schalte MOBIKE im strongswan ab und des Verhalten ist "korrigiert".

ich bin mir gar nicht sicher, ob das wirklich ein Bug im LANCOM ist, hab es aber mal solchen eingetragen

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

Re: VPN über IPv6

Beitrag von geppi »

Danke!

Bezüglich StrongSwan hatte ich ja schon geschrieben, dass es da einen Workaround gibt. Ich deaktiviere allerdings nicht MOBIKE sondern nutze die Möglichkeit des StrongSwan Client, die UDP encaplsulation zu forcieren. Im Wireshark Trace sieht man auch sehr schön, dass der StrongSwan Client dann ebenso wie der Lancom seine ESP Pakete in UDP an Port 4500 verpackt. Es führt aber vor allen Dingen dazu, dass die SA dann mit UDP encapsulation konfiguriert ist und der Linux Kernel die ankommenden, in UDP verpackten ESP Pakete "verdauen" kann.

Aber für den Windows VPN-Client gibt's halt bis jetzt noch keinen Workaround und wie das bzgl. iOS aussieht kann ich nicht sagen.
Auf jeden Fall wäre es schon hilfreich, wenn man die UDP Kapselung auch auf Lancom Seite ausschalten könnte.
geppi
Beiträge: 149
Registriert: 05 Mär 2009, 18:05

Re: VPN über IPv6

Beitrag von geppi »

Ha, jetzt hab' ich doch noch den Workaround für Windows gefunden.
backslash hat geschrieben: 27 Mär 2023, 15:45 laut strongswan-doku wechselt stronswan auch ohne NAT-T auf Port 4500, wenn MOBIKE aktiv ist:

https://docs.strongswan.org/docs/5.9/fe ... ersal.html

Damit ist die Lösung: schalte MOBIKE im strongswan ab und des Verhalten ist "korrigiert".
Daraufhin hab' ich mich gefragt, wo man für den nativen Windows VPN-Client eigentlich MOBIKE konfiguriert? :G)

Tatsächlich gibt es gut versteckt in den 'Eigenschaften' des jeweiligen VPN-Adapters im Tab 'Sicherheit' den Button 'Erweiterte Einstellungen', wo man eine Checkbox 'Mobilität' findet, die Standardmässig aktiviert ist. Nimmt man den Haken weg "funktioniert's auch mit dem Nachbarn". :D

Wie ist das eigentlich, unterstützt der Lancom MOBIKE?
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: VPN über IPv6

Beitrag von backslash »

Hi geppi,
Wie ist das eigentlich, unterstützt der Lancom MOBIKE?
nicht daß ich wüßte... daher rennt er ja vermutlich in das Problem...
vielleicht weiß Frühstücksdirektor da mehr..

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

Re: VPN über IPv6

Beitrag von Dr.Einstein »

geppi hat geschrieben: 27 Mär 2023, 16:41 Bezüglich StrongSwan hatte ich ja schon geschrieben, dass es da einen Workaround gibt. Ich deaktiviere allerdings nicht MOBIKE sondern nutze die Möglichkeit des StrongSwan Client, die UDP encaplsulation zu forcieren. Im Wireshark Trace sieht man auch sehr schön, dass der StrongSwan Client dann ebenso wie der Lancom seine ESP Pakete in UDP an Port 4500 verpackt. Es führt aber vor allen Dingen dazu, dass die SA dann mit UDP encapsulation konfiguriert ist und der Linux Kernel die ankommenden, in UDP verpackten ESP Pakete "verdauen" kann.

Aber für den Windows VPN-Client gibt's halt bis jetzt noch keinen Workaround und wie das bzgl. iOS aussieht kann ich nicht sagen.
Auf jeden Fall wäre es schon hilfreich, wenn man die UDP Kapselung auch auf Lancom Seite ausschalten könnte.
Dann würden diese Komponenten aber nicht RFC Konform arbeiten:
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.
https://www.rfc-editor.org/rfc/rfc5996

iOS / Android verarbeiten dann wenigstens die RFC korrekt.
Antworten