VPN über IPv6

[geppi]

Ich möchte meinen über IPv4 funktionierenden VPN Zugang am Lancom um IPv6 erweitern.

Mein Ansatz ist die Einträge der Stationen unter 'VPN->IKEv2/IPSec->Verbindungs-Liste' mit den notwendigen Informationen in den Feldern 'IPv6-Regeln', 'IPv6-Adress-Pool' und 'IPv6-Profil' zu ergänzen.

Ich scheitere aber irgendwie schon an der Firewall Regel um überhaupt erstmal den Verbindungsaufbau zuzulassen.

Ich habe in der IPv6-Firewall die inbound Regel 'ALLOW-IPSEC' aktiviert:

Code: Alles auswählen

Name		Aktiv	Priorität	Quell-Tag	Aktionen	Server-Dienste	Quell-Stationen	Kommentar
ALLOW-IPSEC	An	0		0		ACCEPT		IPSEC		ANYHOST		allow IPSec VPN to the device

Diese steht auch ganz oben in der Liste der IPv6-Inbound-Regeln.

Der Befehl 'show ipv6-inbound-flt' liefert gleich zu Beginn:

Code: Alles auswählen

> show ipv6-inbound-flt
Filter 00000001 from Rule ALLOW-IPSEC:
  Protocol: 108
  Src: ::/0 0-0
  Dst: ::/0 0-0
  unconditional:
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000002 from Rule ALLOW-ICMP:
  Protocol: 58
  Src: ::/0 0-0
  Dst: ::/0 0-0
  unconditional:
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000003 from Rule ALLOW-IPSEC:
  Protocol: 51
  Src: ::/0 0-0
  Dst: ::/0 0-0
  unconditional:
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000004 from Rule ALLOW-IPSEC:
  Protocol: 50
  Src: ::/0 0-0
  Dst: ::/0 0-0
  unconditional:
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

Filter 00000005 from Rule ALLOW-IPSEC:
  Protocol: 17
  Src: ::/0 0-0
  Dst: ::/0 4500-4500
  unconditional:
  Limit per conn.: after transmitting or receiving of 0 packets
  actions after exceeding the limit:
      accept

....

Wenn ich versuche vom Client den VPN-Tunnel zu öffnen sehe ich im IPv6-Firewall Trace:

Code: Alles auswählen

[IPv6-Firewall] 2023/03/10 12:19:25,766  Devicetime: 2023/03/10 12:17:04,529 [info] : 
The packet below, received from T-DSL scope global
Internet Protocol Version 6
  Payload length: 912
  Traffic class: 0x00 (DSCP: CS0, ECN: Not-ECT)
  Next header: UDP (17)
  Hop limit: 50
  Source: 2a02:xxxx
  Destination: 2003:xxxx
User Datagram Protocol
  Source port: 46024
  Destination port: 500
  Length: 912
  Checksum: 0x606e
 => dropped by ingress filter
OK (no mirror)

Warum greift meine inbound IPv6-Firewall Regel nicht?

[backslash]

Hi geppi

Warum greift meine inbound IPv6-Firewall Regel nicht?

weil vorher schon das IDS zugeschlagen hat:

Code: Alles auswählen

 => dropped by ingress filter

Das bedeutet, daß das Paket mit der Quell-Adresse 2a02:xxxx nicht über die Leitung T-DSL hätte empfangen werden dürfen.
sprich: die Route zur Adresse 2a02:xxxx zeigt nicht auf die Gegenstelle T-DSL

ein "show ipv6-fib" zeigt dir die komplette Routing-Tabelle..

Gruß
Backslash

[geppi]

OK, danke. Das muss dann wohl an der default-route liegen die auf meine zweite Gegenstelle O2-CABLE zeigt.

Was ich dabei nicht ganz verstehe ist, warum die VPN-Verbindung über IPv4 in meinem setup funktioniert. Denn auch für IPv4 zeigt die default-route auf die O2-CABLE Gegenstelle, bzw. auf O2-DSLITE was aber ja wohl keinen Unterschied machen sollte. Da müsste dann doch eigentlich auch das IDS zuschlagen und die Pakete, die über die T-DSL Gegenstelle reinkommen verwerfen.

Lässt sich das denn irgendwie lösen, die default-route über Gegenstelle-A laufen zu lassen aber VPN-Zugänge über Gegenstelle-B zu reallisieren?
Was muss ich dazu wie taggen? Sind da Einträge unter 'Kommunikation->Gegenst.(Mobilfunk/seriell)->WAN-Tag-Tabelle' notwendig?

[geppi]

Ich glaub' ich hab da was gefunden:

fragen-zur-lancom-systems-routern-und-g ... ml#p112239

Bin ich da "auf der richtigen Spur"?

[geppi]

Ich bin allerdings noch ein bisschen verwirrt für welche Gegenstellen ich welche WAN-Tags setzten muss.

Soweit ich es verstanden habe gebe ich der T-DSL Gegenstelle ein von "0" verschiedenes Tag und definiere in der Routing-Tabelle dafür eine default-route, damit das IDS schon mal zufrieden ist.

Was muss ich dann tun, um dann wiederum von einem, über den aufgebauten VPN Tunnel kommenden Client auf das interne Netz mit Tag "0" zugreifen zu können? Mache ich dazu einen weiteren Eintrag in der WAN-Tag Tabelle für die VPN-Gegenstelle und gebe ihr das TAG "0" oder muss ich das über Firewall Regeln machen die Pakete umtaggen?

[backslash]

Hi geppi,

Was ich dabei nicht ganz verstehe ist, warum die VPN-Verbindung über IPv4 in meinem setup funktioniert. Denn auch für IPv4 zeigt die default-route auf die O2-CABLE Gegenstelle, bzw. auf O2-DSLITE was aber ja wohl keinen Unterschied machen sollte. Da müsste dann doch eigentlich auch das IDS zuschlagen und die Pakete, die über die T-DSL Gegenstelle reinkommen verwerfen

da ich deine Routing-Tabelle nicht kenne, kann ich auch nichts dazu sagen.

Lässt sich das denn irgendwie lösen, die default-route über Gegenstelle-A laufen zu lassen aber VPN-Zugänge über Gegenstelle-B zu reallisieren?

Wichtig ist nur, dass es eine aktive Route gibt, die auf das Interface zeigt. Wenn du also in der IPv4-Routing-Tabelle eine Default-Route hast, die auf T-DSL zeigt, funktioniert es.
Du braucht also nur in der IPv6-Routing-Tabelle auch eine Default-Route, die auf T-DSL zeigt - mit einem Routing-Tag ungleich 0.

Was muss ich dazu wie taggen? Sind da Einträge unter 'Kommunikation->Gegenst.(Mobilfunk/seriell)->WAN-Tag-Tabelle' notwendig?

nein, dazu mußt du nichts taggen - über die Routen sagst du der Firewall, daß sie Pakete mit beliebigen Absenderadressen auch über diese Leitung akzeptieren soll (es ist am Ende etwas komplizierter, aber prinzipiell kannst du es so sehen)

BTW: die WAN-Tag-Tabelle ist nur für IPv4 gültig. Für IPv6 müßtest du das Tag beim jeweiligen WAN-Profil (IPv6 -> Allgemein -> WAN-Profile) hinterlegen. Aber es ist ja nicht notwendig.

ch glaub' ich hab da was gefunden:

fragen-zur-lancom-systems-routern-und-g ... ml#p112239

Bin ich da "auf der richtigen Spur"?

nein, denn da geht es um administrative Distanzen - hier hast du damit überhaupt nichts zu tun... Außerdem sollst/willst du das IDS nicht abschalten...

Was muss ich dann tun, um dann wiederum von einem, über den aufgebauten VPN Tunnel kommenden Client auf das interne Netz mit Tag "0" zugreifen zu können?

nichts, denn wenn das Paket aus dem Tunnel "herauskommt" dann bekommt es das Tag, das du dem VPN-Interface zugewiesen hast - und wenn du dem keins zugewiesen hast, ist das gleichbedeutend mit 0...
Sprich: Es hat schin das Tag 0...


Gruß
Backslash

[geppi]

Das war ja einfacher als ich dachte. Mir war nicht klar, dass einfach eine Route für irgend ein "dummy-tag" reicht. Das erklärt auch warum es mit IPv4 funktioniert hat. Ich habe ein anderes VLAN, inklusive eigenem Tag, mit einer default-route auf das T-DSL interface. Dadurch hat das IDS bei meinem IPv4 setup nicht zugeschlagen.

Soweit so gut. Ich kann den VPN Tunnel jetzt sowohl über IPv4 als auch über IPv6 aufbauen. Je nachdem, ob ich die Präferenz im Client auf IPv4 oder IPv6 setze, sehe ich sowohl im VPN Trace als auch mit 'show vpn sadb' bei 'src:' und 'dst' IPv4- oder IPv6-Adressen.

Was ich leider nicht hin bekomme ist, sowohl IPv4-Traffic als auch IPv6-Traffic über den Tunnel zu leiten.
Als Beispiel nehme ich mal das Setup bei dem der Client einen VPN-Tunnel über IPv4 aufbaut mit einem Tunnel über IPv6 sieht es aber genauso aus.

Zuerst das Setup bei dem nur IPv4 für die Gegenstelle konfiguriere ist.

Mit folgendem Eintrag im Lancom für die VPN-Gegenstelle:

Code: Alles auswählen

/Setup/VPN/IKEv2
> ls Peers

Peer                  Active   SH-Time     Remote-Gateway                                                    Rtg-tag     Encryption            Authentication        General               Lifetimes             IKE-CFG     IPv4-CFG-Pool     IPv6-CFG-Pool     CFG-Client-Profile  Split-DNS-Profile  Auto-IP-Profile   Rule-creation  IPv4-Rules                                                       IPv6-Rules                                                       Routing                          RADIUS-Authorization             RADIUS-Accounting                IPv6              HSVPN             Comment
======================-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DEFAULT               Yes      0                                                                             0           MY_ENCR          	DEFAULT              DEFAULT               BSI_TR-02102-3        Off                                                                                                      manually                                                                                                                                                                                                                                                                                Default settings for peers that haven't been identified (yet)
MY_VPN                Yes      0                                                                             0           MY_ENCR           	MY_AUTH              DEFAULT               BSI_TR-02102-3        Server      MY_VPN_POOL   	MY_VPN6_POOL                                                           	  manually       RAS-WITH-CONFIG-PAYLOAD                                          RAS-WITH-CONFIG-PAYLOAD                                                                                                                                                                                 VPN connection for my_client

und den dazugehöhrigen Einstellungen:

Code: Alles auswählen

/Setup/VPN/IKEv2/IKE-CFG
> ls IPv4

Name              Start-Address-Pool  End-Address-Pool    Primary-DNS      Secondary-DNS
==================------------------------------------------------------------------------
MY_VPN_POOL       10.1.200.100        10.1.200.199        10.1.0.1

> ls IPv6

Name              PD-Source         Start-Address-Pool                       End-Address-Pool                         Primary-DNS                              Secondary-DNS
==================------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
MY_VPN6_POOL      O2-CABLE          0:0:0:1::1                               0:0:0:1::9

sowie:

Code: Alles auswählen

/Setup/VPN/Networks
> ls IPv4-Rules

Name                             Local-Networks                                                                                                                   Remote-Networks
=================================----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RAS-WITH-CONFIG-PAYLOAD          0.0.0.0/0                                                                                                                        0.0.0.0/32
RAS-WITH-NETWORK-SELECTION       0.0.0.0/0                                                                                                                        0.0.0.0/0

> ls IPv6-Rules

Name                             Local-Networks                                                                                                                   Remote-Networks
=================================----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
RAS-WITH-CONFIG-PAYLOAD          ::/0                                                                                                                             ::/128
RAS-WITH-NETWORK-SELECTION       ::/0                                                                                                                             ::/0

bekomme ich auf dem Client eine IPv4-Adresse und ein entsprechendes Routing, so dass der gesamte IPv4-Traffic über den Tunnel geleitet wird:

Code: Alles auswählen

ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.37/24 brd 192.168.122.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 3385sec preferred_lft 3385sec
    inet 10.1.200.107/32 scope global wlp3s0
       valid_lft forever preferred_lft forever
    inet6 2a02:3035:xx:xx:xx:xx:xx:xx/64 scope global temporary dynamic 
       valid_lft 3388sec preferred_lft 3388sec
    inet6 2a02:3035:xx:xx:xx:xx:xx:xx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3388sec preferred_lft 3388sec
    inet6 fe80::xx:xx:xx:xx:xx:xx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.1.200.107/32 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::xx:xx:xx:xx:xx:xx/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Der IPv6-Traffic läuft auf dem Client natürlich weiterhin ausserhalb des Tunnels.
Auf dem Lancom sieht die Security Association wie folgt aus:

Code: Alles auswählen

> show vpn sadb

SA-REPORT

SA: Peer MY_VPN, IKE_SA ikev2 responder
Flags 0x0010000101010010   Server   Authenticated   Ready
   Routing-tag 0, Com-channel 23
   Dead Peer Detection 31s   authentication methods: local DIGITAL SIGNATURE:sha256WithRSAEncryption (14)  remote DIGITAL SIGNATURE:sha384WithRSAEncryption (14)
   Encryption AES-CBC-256   Integrity AUTH-HMAC-SHA-512   IKE-DH-Group 14
   initiator spi: 0x68BFC8077EC20E62
   responder spi: 0x417AD77D53F70BB8
   life secs 86400 rekeying_in 77646 secs life_cnt_sec 86286 secs kb 2000000 byte_cnt_o 2811 byte_cnt_i 0
   initiator id: xxxx
   src: 93.217.xx.xx dst: 2.247.xx.xx
   Config Server:
     Assigned IPv4 Address         : 10.1.200.107
     Assigned IPv4 DNS Servers     : 10.1.0.1


SA: Peer MY_VPN, Rule IPSEC-0-MY_VPN-PR0-L0-R0 CHILD_SA ikev2 responder
Flags 0x0000000100000000   Ready
   Routing-tag 0, Com-channel 23
   life secs 14400 rekeying_in 12846 secs life_cnt_sec 14286 secs kb 2000000 byte_cnt_o 46136 byte_cnt_i 20143
   initiator id: <no ipsec id>, responder id: <no ipsec id>,
   src: 93.217.230.8 dst: 2.247.242.39
   0.0.0.0/0 <-> 10.1.200.107/32
   proposal 1 protocol IPSEC_ESP   Authenticated-Encryption AES-GCM-16-256   PFS-DH-Group None
     spi[outgoing]   0xc632c226
     spi[incoming]   0xa195b501

und es wird auch die notwendige Route gesetzt:

Code: Alles auswählen

> show ipv4-fib
IPv4 Unicast FIB

 Rtg-Tag 0

  Prefix             Next-Hop        Interface                 ID         Masquerading Redistribution Type (Distance)
  --------------------------------------------------------------------------------------------------------------------------
  ....
  10.1.200.107/32    0.0.0.0         MY_VPN               	17         no           Redistribute   VPN (15)
  ....

Wenn ich aber im Eintrag für die VPN-Gegenstelle ein 'IPv6-Profile' setze:

Code: Alles auswählen

/Setup/VPN/IKEv2
> ls Peers

Peer                  Active   SH-Time     Remote-Gateway                                                    Rtg-tag     Encryption            Authentication        General               Lifetimes             IKE-CFG     IPv4-CFG-Pool     IPv6-CFG-Pool     CFG-Client-Profile  Split-DNS-Profile  Auto-IP-Profile   Rule-creation  IPv4-Rules                                                       IPv6-Rules                                                       Routing                          RADIUS-Authorization             RADIUS-Accounting                IPv6              HSVPN             Comment
======================-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
DEFAULT               Yes      0                                                                             0           MY_ENCR          	DEFAULT              DEFAULT               BSI_TR-02102-3        Off                                                                                                      manually                                                                                                                                                                                                                                                                                Default settings for peers that haven't been identified (yet)
MY_VPN                Yes      0                                                                             0           MY_ENCR           	MY_AUTH              DEFAULT               BSI_TR-02102-3        Server      MY_VPN_POOL   	MY_VPN6_POOL                                                           	  manually       RAS-WITH-CONFIG-PAYLOAD                                          RAS-WITH-CONFIG-PAYLOAD                                                                            									O2-CABLE 			  VPN connection for my_client

bekommt der Client zwar eine IPv6-Adresse deren Routing über den Tunnel läuft, aber keine IPv4-Adresse mehr :

Code: Alles auswählen

ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.37/24 brd 192.168.122.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 3521sec preferred_lft 3521sec
    inet6 2a02:3102:xx:1::7/128 scope global nodad 
       valid_lft forever preferred_lft forever
    inet6 2a02:3035:xx:xx:xx:xx:xx:xx/64 scope global temporary dynamic 
       valid_lft 3526sec preferred_lft 3526sec
    inet6 2a02:3035:xx:xx:xx:xx:xx:xx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3526sec preferred_lft 3526sec
    inet6 fe80::xx:xx:xx:xx:xx:xx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet6 2a02:3102:xx:1::7/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::xx:xx:xx:xx:xx:xx/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Die Security Association sieht jetzt folgendermassen aus:

Code: Alles auswählen

> show vpn sadb

SA-REPORT

SA: Peer MY_VPN, IKE_SA ikev2 responder
Flags 0x0010000101010010   Server   Authenticated   Ready
   Routing-tag 0, Com-channel 23
   Dead Peer Detection 31s   authentication methods: local DIGITAL SIGNATURE:sha256WithRSAEncryption (14)  remote DIGITAL SIGNATURE:sha384WithRSAEncryption (14)
   Encryption AES-CBC-256   Integrity AUTH-HMAC-SHA-512   IKE-DH-Group 14
   initiator spi: 0xD9B218C3DDFD1A5D
   responder spi: 0x4D3A11A9617C2F21
   life secs 86400 rekeying_in 76358 secs life_cnt_sec 84998 secs kb 2000000 byte_cnt_o 14200 byte_cnt_i 0
   initiator id: xxxx
   src: 93.217.xx.xx dst: 2.247.xx.xx
   Config Server:
     Assigned IPv4 Address         : 10.1.200.107
     Assigned IPv4 DNS Servers     : 10.1.0.1
     Assigned IPv6 Address         : 2a02:3102:xx:1::7/128


SA: Peer MY_VPN, Rule IPSEC-1-MY_VPN-PR0-L0-R0 CHILD_SA ikev2 responder
Flags 0x0000000100000000   Ready
   Routing-tag 0, Com-channel 23
   life secs 14400 rekeying_in 11558 secs life_cnt_sec 12998 secs kb 2000000 byte_cnt_o 14812 byte_cnt_i 15884
   initiator id: <no ipsec id>, responder id: <no ipsec id>,
   src: 93.217.xx.xx dst: 2.247.xx.xx
   ::/0 <-> 2a02:3102:xx:1::7/128
   proposal 1 protocol IPSEC_ESP   Authenticated-Encryption AES-GCM-16-256   PFS-DH-Group None
     spi[outgoing]   0xc9dcc14c
     spi[incoming]   0x2a6e4be4

Es wird aber keine IPv4 VPN-Route mehr gesetzt sondern lediglich die IPv6 VPN-Route:

Code: Alles auswählen

> show ipv6-fib
IPv6 Unicast FIB

 Rtg-Tag 0

  Prefix                                                                Next-Hop                                Interface                 ID         Redistribution Type (Distance)
  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  ....
  2a02:3102:xx:1::7/128                                                 ::                                      MY_VPN                    14         Redistribute   VPN (15)
  ....
  fe80::/10%MY_VPN                                                      ::                                      MY_VPN                    14         Redistribute   Connected WAN (2)
  fe80::2a0:57ff:xxxx:xxxx/128%MY_VPN                                   ::                                      #Loopback                 1          Redistribute   Local WAN (0)
  ....

Was mache ich falsch?

[Frühstücksdirektor]

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.

[geppi]

Danke für die Info.

Es wäre hilfreich wenn diese Einschränkung auch im Reference Manual erwähnt würde.
Bitte nehmt das doch rein. Es hätte mir viel Arbeit erspart, weil ich erstmal von einem Fehler auf Layer-8 ausgegangen bin.

Das heisst dann aber auch, dass bei Auswahl von IPv4 der gesamte IPv6-Traffic nicht über den Tunnel läuft, was man ja unter Umständen nicht haben will, oder? Ist da denn was in Planung?

Leider ist mir jetzt aber auch noch aufgefallen, dass ich bei einem Tunnel, der über IPv6 aufgebaut ist, keine funktionierende Kommunikation über IPv4 im Tunnel zwischen einem Client und dem Lancom bekomme. Gilt die Aussage bezüglich des nicht möglichen Dual Stack Betriebs im CFG-Mode Server nur für die Kommunikation im Tunnel oder muss die IP-Protokoll Version des Tunnels und der Kommunikation im Tunnel gleich sein?

Ich frag mal lieber bevor ich hier wieder tonnenweise Logs poste.

Das Seltsame ist, dass ich sowohl mit OpenSwan auf einem Linux Client, als auch mit dem Windows 10 VPN Client eine funktionierende Kommunikation per IPv4-Protokoll hinbekomme, wenn der Tunnel über IPv4 aufgebaut ist. Wenn der Tunnel allerdings über IPv6 läuft funktioniert die Kommunikation im Tunnel mit IPv4 nicht.
Interessant ist, dass ich im VPN-Packet Trace auf dem Lancom die hereinkommenden Pakete vom Client sehe und auch die Antwortpakete, die über die richtige Gegenstelle zurückgeschickt werden. Mit Wireshark sehe ich auf dem Client auch die IP-Pakete mit ESP Payload und zwar sowohl die, die er an den Lancom schickt, als auch die Antwortpakete die er vom Lancom erhält. Aber aus irgendeinem Grund kommen die Antworten wohl nicht bis in einen der oberen Layer, um ausgewertet zu werden. Soweit ich sehen kann stimmen die Routen auf dem Client aber und auch die IPsec policies im Linux Kernel scheinen zu passen. Bei Windows kenn' ich mich nicht so gut aus um da in die IPsec internals schauen zu können. Aber wie gesagt, es funktioniert weder mit dem Linux noch mit dem Windows Client, was bei mir jetzt doch die Vermutung weckt, dass es auch diesmal nicht am Layer-8 liegt.

[backslash]

Hi Frühstücksdirektor

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.

das wäre mir ehrlich gesagt neu, denn offenbar hat das LANCOM bei geppi ja beide zugewiesenen IP-Adressen verhandelt:

Code: Alles auswählen

SA: Peer MY_VPN, IKE_SA ikev2 responder
Flags 0x0010000101010010   Server   Authenticated   Ready
   Routing-tag 0, Com-channel 23
   Dead Peer Detection 31s   authentication methods: local DIGITAL SIGNATURE:sha256WithRSAEncryption (14)  remote DIGITAL SIGNATURE:sha384WithRSAEncryption (14)
   Encryption AES-CBC-256   Integrity AUTH-HMAC-SHA-512   IKE-DH-Group 14
   initiator spi: 0xD9B218C3DDFD1A5D
   responder spi: 0x4D3A11A9617C2F21
   life secs 86400 rekeying_in 76358 secs life_cnt_sec 84998 secs kb 2000000 byte_cnt_o 14200 byte_cnt_i 0
   initiator id: xxxx
   src: 93.217.xx.xx dst: 2.247.xx.xx
   Config Server:
     Assigned IPv4 Address         : 10.1.200.107
     Assigned IPv4 DNS Servers     : 10.1.0.1
     Assigned IPv6 Address         : 2a02:3102:xx:1::7/128

aber dann ist wohl irgendwas schiefgegangen, denn es wird nur die SA für die IPv6-Regeln ausgehandelt:

Code: Alles auswählen

SA: Peer MY_VPN, Rule IPSEC-1-MY_VPN-PR0-L0-R0 CHILD_SA ikev2 responder
Flags 0x0000000100000000   Ready
   Routing-tag 0, Com-channel 23
   life secs 14400 rekeying_in 11558 secs life_cnt_sec 12998 secs kb 2000000 byte_cnt_o 14812 byte_cnt_i 15884
   initiator id: <no ipsec id>, responder id: <no ipsec id>,
   src: 93.217.xx.xx dst: 2.247.xx.xx
   ::/0 <-> 2a02:3102:xx:1::7/128
   proposal 1 protocol IPSEC_ESP   Authenticated-Encryption AES-GCM-16-256   PFS-DH-Group None
     spi[outgoing]   0xc9dcc14c
     spi[incoming]   0x2a6e4be4

@geppi
kann es sein, daß der von die verwendete Client ein Problem mit Dual-Stack hat?
Der Client sollte eigentlich alls SAs verhandeln - hier scheint er aber nur eine SA zu verhandeln.
Das müßte man aber im VPN-Status-Trace besser sehen können

Auch interressant ist der Punkt daß OpenSwan nur IPv4 nutzen können soll, wenn auch die Kommunikation ausserhalb der Tunnels IPv4 ist. Das kann ich mir eigentlich auch nicht vorstellen, denn was im Tunnel läuft hängt ja nur davon ab, welche SAs ausgehandelt wurden und nicht was als Transportprotokoll genutzt wird.

Ich würde da eher von einem Konfigurationsfehler ausgehen

Gruß
Backslash

[geppi]

kann es sein, daß der von die verwendete Client ein Problem mit Dual-Stack hat?

Ist mir bis jetzt zumindest nicht aufgefallen. Meinst Du mit "Client" jetzt den Rechner+OS selbst oder die VPN-Client Software?
Was den Rechner angeht, so ist das ein und die selbe physikalische Maschine, einmal unter Ubuntu 22.04 und einmal unter Windows 10 21H2.
Mit beiden OS kann ich sowohl über IPv4 als auch IPv6 kommunizieren. Da sind mir bezüglich des Dual Stack Betriebs bis jetzt keine Probleme aufgefallen.

Was die VPN-Client Software angeht muss ich mich korrigieren, unter Ubuntu 22.04 benutze ich StrongSwan und nicht wie oben geschrieben OpenSwan.
Aber sowohl mit Strongswan als auch mit dem Windows 10 eigenen VPN-Client habe ich die beschriebenen Probleme mit Dual Stack. Ob das an den VPN-Clients liegt, an meiner Konfiguration oder am Lancom würde ich ja gerne herausfinden.

Es scheinen aber auch andere das Problem mit IPv4-Traffic in einem IPv6-Tunnel zu haben. In diesem Post z.B.:
fragen-zum-thema-vpn-f14/win10-vpn-clie ... 19659.html

"Vorort" hat es dann zunächst nicht funktioniert. Der Client hat "Verbunden" gemeldet und auch per CFG seine Daten erhalten, aber es floss kein Traffic. Mein Verdacht ging auf IPv4-in-IPv6-Kapselung. Also habe ich geschwind in C:\Windows\System32\drivers\etc\hosts die IPv4 für den VPN-Router-FQDN hinterlegt. Dann lief es.

Das sieht mir doch sehr nach meinem zweiten Problem aus.

Der Client sollte eigentlich alls SAs verhandeln - hier scheint er aber nur eine SA zu verhandeln.
Das müßte man aber im VPN-Status-Trace besser sehen können

Ich liefere gerne noch weitere Traces um die Probleme einzugrenzen. Allerdings wüsste ich schon gerne vorher ob sich die Mühe lohnt und das Problem nicht auf einer fehlenden Funktionalität fusst. Daher würde ich es begrüßen wenn von Lancom Seite eine definitive Aussage zum ersten Problem, bezüglich des Dual Stack Betriebs im Tunnel käme. Du hattest ja in Zweifel gezogen, dass die Funktionalität grundsätzlich fehlt, oder?

Bezüglich des zweiten Problems weiss ich ehrlich gesagt nicht so recht wo ich hinlangen soll um es weiter einzugrenzen. Wie gesagt sehe ich sowohl Request als auch Reply ESP Pakete am Client Interface. Wenn's ein Konfigurationsproblem ist scheine ich gemäß oben zitiertem Post ja zumindest nicht der einzige zu sein der das hat und eine Lösung habe ich bisher nirgends gesehen. Wäre ja schon mal interessant zu wissen ob es auch positiv Beispiele gibt.

[backslash]

Hi geppi

Meinst Du mit "Client" jetzt den Rechner+OS selbst oder die VPN-Client Software?

mit Client ist natürlich die Software gemeint...

Du hattest ja in Zweifel gezogen, dass die Funktionalität grundsätzlich fehlt, oder?

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

Gruß
Backslash

[geppi]

OK, danke nochmal für die Klarstellung. Ist wie gesagt ein bisschen ärgerlich, dass das nicht im Manual steht,vor allem weil man aus dem Rest der Dokumentation wohl eher schliesst, dass es schon funktionieren sollte. Sonst hättest Du die Aussage von Frühstücksdirektor ja wohl auch nicht in Zweifel gezogen.

Aber gut zu wissen, dass es wohl für die 10.80 geplant ist. Ich hoffe mein 1781VA bekommt die noch.
Vor allem weil ja wie gesagt der ganze IPv6-Traffic am Tunnel vorbeigeht wenn man darin IPv4 fährt.

Bleibt das Problem, das wohl auch OnkelThomas hatte, nämlich die nicht zustande kommende Kommunikation bei IPv4 in einem IPv6 Tunnel.
Sollte das denn mit Sicherheit funktionieren und mit welchem Client?

Wie gesagt bin ich auch für Anregungen dankbar wo ich noch debuggen könnte.
Die Tatsache, dass die Routen sowohl im Lancom als auch auf dem Client alle stehen und dass der Lancom Ping und DNS Requests bekommt und auch beantwortet, diese Replies auch als IP-Pakete mit ESP Payload auf dem Client Interface ankommen, hinterlässt mich ein wenig ratlos wo ich weiter schauen soll.

[backslash]

Hi geppi,

Bleibt das Problem, das wohl auch OnkelThomas hatte, nämlich die nicht zustande kommende Kommunikation bei IPv4 in einem IPv6 Tunnel.
Sollte das denn mit Sicherheit funktionieren und mit welchem Client?

ich lehne mich jetzt nicht mehr ganz so weit aus dem Fenster, wie beim Dual-Stack-Config-Mode-Server...
Ich kann nur sagen, daß das mit zwei LANCOMs gegenseinander in einer LAN-LAN-Kopplung funktioniert (da auch mit Dual-Stack im Tunnel - daher hat mich das mit dem Config-Mode auch gewundert)...

Wie gesagt bin ich auch für Anregungen dankbar wo ich noch debuggen könnte.
Die Tatsache, dass die Routen sowohl im Lancom als auch auf dem Client alle stehen und dass der Lancom Ping und DNS Requests bekommt und auch beantwortet, diese Replies auch als IP-Pakete mit ESP Payload auf dem Client Interface ankommen, hinterlässt mich ein wenig ratlos wo ich weiter schauen soll.

Wenn das LANCOM die Antworten in ESP pakete packt und an den Client sendet und der die nicht auspackt, dann sollte man erstmal am Client nachschauen, warum er die Paket nicht mag - so der Client denn passende Tracemöglichkeiten bietet - ansonsten wird es schwierig...

Gruß
Backslash

[geppi]

Hallo backslash,

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.

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.

Naja, ich schau mal ob ich unter Linux brauchbare Informationen rauskitzeln kann, warum die Reply ESP-Pakete nicht weiterkommen.

Gruß
geppi