KEv2 Payload UDP Destination Port Probleme

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
beki
Moderator
Moderator
Beiträge: 109
Registriert: 16 Jan 2017, 13:09
Wohnort: DKB/BY/DE

KEv2 Payload UDP Destination Port Probleme

Beitrag von beki »

Hallo zusammen,

habe heute eine Überraschung erlebt: Mein VPN Tunnel über UDP-TCP Relay über TCP-Forwarding im SSH-Tunnel funktioniert nicht mehr. Aber so kompliziert müssen wir es nicht diskutieren, der Grund liegt in einem geänderten Verhalten des LCOS VPN:

Nach Update auf 10.20RC2 (von 10.12) schickt das LANCOM VPN-Payload Antworten auf Port 4500 an den Client zurück, statt wie in 10.12 an den Absenderport des UDP Telegramms:

LCOS 10.12:

Code: Alles auswählen

[PACKET][2018-08-27 10:51:19:095680] TCP       127.0.0.1:50002 <--       127.0.0.1:60274
[PACKET][2018-08-27 10:51:19:096063] UDP         0.0.0.0:45454 -->     192.168.15.3:4500
[PACKET][2018-08-27 10:51:19:135971] UDP         0.0.0.0:45454 <--     192.168.15.3:4500
[PACKET][2018-08-27 10:51:19:136220] TCP       127.0.0.1:50002 -->       127.0.0.1:60274
Es kommt ein TCP Datenhaufen aus dem SSH Tunnel, daraus wird ein UDP Paket geschnürt, das an Port 4500 des LANCOM VPN Gateways (192.168.15.3) geht. Die Antwort erfolg an Port 45454 des UDP-TCP-Relays.

LCOS 10.20:

Code: Alles auswählen

[PACKET][2018-08-27 10:33:58:605199] TCP       127.0.0.1:50002 <--       127.0.0.1:35898
[PACKET][2018-08-27 10:33:58:605716] UDP         0.0.0.0:45454 -->    192.168.22.11:4500
Das Relay sieht die Antwort des LANCOMs nicht. Aus dem Trace am LANCOM geht hervor, dass es seine Antwort fest an Port 4500 verschickt, obwohl das ursprüngliche Telegramm von Port 45454 kam:

Code: Alles auswählen

[VPN-Packet] 2018/08/27 11:04:31,401
encrypted: 192.168.22.11->192.168.22.10  136  UDP port 4500->4500
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 136
ID                  : 63268
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 55770 (OK)
Src Address         : 192.168.22.11
Dest Address        : 192.168.22.10
-->UDP Header
Src Port            : 4500
Dest Port           : 4500
[...]
Soweit verstanden. Das UDP-TCP Relay kann auch auf Port 4500 hören, das kein Problem weil der Host, auf dem das Relay läuft, keinen IPSec Server betreibt. Die Frage ist: Bricht das in anderen Szenarien das VPN? Wenn der Client in UDP eingekapselte VPN Payload Pakete an 4500 erwartet, dann wird er selbst auch Port 4500 als Absendeport seiner Pakete wählen. Die ursprüngliche Variante erscheint mir robuster.

Dann habe ich das neue Feld "Destination Port" auf 4510 eingestellt:

Code: Alles auswählen

08/27/2018 11:12:06 schlimmchen on torvalds in /Setup/VPN/IKEv2/General
> l

Name                  DPD-Inact-Timeout  Encapsulation  Destination-Port
======================--------------------------------------------------
DEFAULT               30                 None           0               
PHONE                 30                 UDP            4510
Nun sehe ich, dass die Antworten des Gateways dennoch an Port 4500 gehen. Die Zurodnung des General-Profils "PHONE" an den Peer "PHONE" is natürlich erfolgt. VPN aus und wieder einschalten hilft auch nicht.

Es gibt schon ein Addendum zur 10.20 (ftp://ftp.lancom.de/Documentation/Refer ... dum_DE.pdf). Darin lese ich:
In Verbindung mit Ziel-Port kann ein beliebiger Ziel-Port konfiguriert werden. Der Aufbau des IKEv2-Tunnels wird bei UDP mit Port 4500 bzw. mit dem in Ziel-Port eingestellten Port durchgeführt.
Ich verwende Zertifikate zur Authentifizierung, und der Peer wird dementsprechend früh als "PHONE" erkannt. Warum dann die Einstellung "Destination-Port" keine Rolle zu spielen scheint, ist mir daher schleierhaft.

Das sieht mir nach einem Bug aus. Kann das jemand bestätigen?

Gruß
Antworten