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.
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?
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?
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.
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.
