VPN von Lancom zu Windows Server

[dMatschek]

Ich habe hier ein Szenario mit einem Lancom (R884VA), der die VPN Verbindungen der mobilen Clients via Forwarding von Port 500/4500 auf einen Windows Server 2019 durchreicht. Zzt. L2TP, Aktualisierung auf IKEv2 und VPN Alway on is angedacht. Nun kommt die Anforderung hinzu, dass eine Außenstelle als Site2Site angebunden wird. Am liebsten wäre mir da eine Lancom zu Lancom Verbindung, losgelöst von dem laufenden Windows VPN. Ich finde aber keine Möglichkeit die Ports für eine Site2Site im Lancom anders einzustellen, um die Port Konflikte zu umgehen – gibt es da was?
Alternativ bliebe wohl nur, dass der Lancom der Außenstelle sich in das vorhandene Windows VPN einwählt. Eine Beschreibung der dann nötigen Verbindungs-Parameter habe ich nicht entdecken können (Ein kurzes Trial and Error im Lab hab ich nach einer Stunde aufgegeben).
Wer kann passendes Gedanken-Gut mit mir teilen?

Gruß,
dMatschek

[Dr.Einstein]

Hast du einmal die Einstellungen unter VPN / IKEv2 / Verbindungs-Parameter -> Ziel-Port probiert, alternativ SSL Encapsulierung? Habe damit noch nie testen müssen aber kannst es ja mal probieren.

Alternativ auf beiden Lancoms IPv6 anwerfen und den VPN über v6 terminieren. Innerhalb des Tunnels kann ja weiterhin v4 laufen.

[dMatschek]

Hi Dr. Einstein,

Die Idee hier über IPv6 was zu machen klingt charmant, ich denke das setze ich um!

Den Verbindungs-Parameter hab ich testweise auf Port 10123 geändert, frage mich da aber wo der andere Port (brauche doch original 500+4500?) sein Setting hat?
Das Ergebnis ist ein Verbindungsversuch der in der IKE Negoiation in einer Resending-Schleife stecken bleibt, wenn ich das richtig rauslese

Code: Alles auswählen

VPN: WAN state changed to WanProtocol for XXX (x.x.x.x) IKEv2[BT] fff...
[XXX] Sending packet: (hier steht nun der Zielport 10123 drin)...
Establishing connection(s): IPSEC-0-XXX-PR0-L0-R0: IKE_SA not found...
Received Connection-Request for XXX (ikev2)...
[XXXX] Resending packet
Non-ESP-Marker Prepended: Resending an IKE_SA_INIT-REQUEST...
Message scheduled for retransmission (2) in 6 seconds...

Die letzten 3 Zeilen wiederholen sich dann bis zum Abbruch.

Ob da die Bytes noch falsch abbiegen Richtung Windows Server oder ich doch einen anderen Fehler habe kann ich nicht sicher sagen.

Bei einem Umstellen auf SSL Encaps. läuft der Aufbauversuch in einen IKEv2 timeout: no response.

VG,
dMatschek

[Dr.Einstein]

Den Verbindungs-Parameter hab ich testweise auf Port 10123 geändert, frage mich da aber wo der andere Port (brauche doch original 500+4500?) sein Setting hat?

Lancom verwendet in vielen Menüpunkten den Wert 0 als Default. Dahinter verbirgt sich dann meist was ganz anderes. Die Onlinehilfe sagt zu dem Punkt:

Code: Alles auswählen

Hier können Sie den Zielport der IKEv2-Verbindung definieren, der abhängig von der Einstellung in Encapsulation genommen wird. Bei einer von 500 abweichenden Einstellung wird automatisch eine UDP-Encapsulation durchgeführt.
Mögliche Werte:
max. 5 Zeichen aus [0-9]
Default-Wert:0

Du hast aber schon auch die andere Seite entsprechend identisch jeweils angepasst? Aber wie gesagt, ich habe selbst damit noch nie etwas gebaut. Kann sein, dass Lancom das nur in eine Richtung vorsieht, und er selbst gar nicht VPN Server auf Port xyz sein kann.

[dMatschek]

Ja, auch auf der Zielseite ist es angepasst. Ich fürchte jedoch ebenso wie Du, dass der Port nur ein Aufbau-, kein Server-Parameter ist. Wenn ich einen Trace auf der Zielseite mache, kommt da nix an im VPN Filter. Im Wireshark hingegen sehe ich ein ankommendes Paket auf Port 10123.

Und dann lese ich, dass der Provider auch kein IPv6 unterstützt. Argh!

[Dr.Einstein]

So als Idee, da mir einfach unbekannt ist, wie man den IKEv2 Serverport von 500 auf xyz umändert.

- PPTP Tunnel zwischen den Standorten anlegen (in der Hoffnung du nutzt PPTP nicht auch noch für Windows Kiste)
- Über den PPTP Tunnel dann den IPSec aufbauen

Die Performance werden jetzt nicht 1 Gbit/s sein, aber wenns dir reicht, dass z.B. 20 Mbit/s drüber rödeln, dann könnte das was für dich sein.

Ist schon etwas länger her, dass ich das mal gemacht habe, aber folgende Schritte waren es grob:

- Kommunikation / Gegenstellen / PPTP / PPTP-Liste
-- PPTP Eintrag anlegen mit der WAN-IP-Adresse von gegenüber, Haltezeit "Zentrale" 0, Haltezeit in der "Außenlokation" 9999
- Kommunikation / Protokolle / PPP-Liste
-- PPP Eintrag anlegen. Gegenstelle und Benutzername jeweils über Kreuz, also Gegenstellenname wie bei PPTP zB STANDORT1, dann wäre der Benutzername STANDORT2.
- IPv4 / Allgemein / Loopback-Adresse
-- Eintrag hinzufügen, komplett neues Routing Tag anlegen wie 200, IP-Adresse aus einem komplett anderen Bereich nutzen wie 172.16.250.1 bzw 172.16.250.2
- IP-Router / Routing / IPv4-Routing Tabelle
-- Neuen Routing Eintrag anlegen mit der Loopback-Adresse von gegenüber, also 172.16.250.2/32, Verweis auf die PPTP-Verbindung, Routing Tag 200 vom Beispiel oben.

Wenn der PPTP steht (LanMonitor zB), dann kannst du zwischen 172.16.250.1 <->172.16.250.2 deinen IPSec aufbauen. Beachte, dass du bei der IKEv2 Verbindung auf das Routing Tag 200 verweisen musst.

[dMatschek]

Danke für die Ausführungen Dr. Einstein. Bevor ich mich an Deine Idee mit dem PPTP Tunnel rantrauen musste, habe ich eine IKEv2 über Port 443 zum Laufen bekommen.

- Die aufbauende Seite hat in den Verbindungsparametern bei Encapsulation SSL ein getragen, Port ist nicht nötig bzw. 0 und defaultet auf 443.
- Auf den annehmenden Seite muss nichts in den Verbindungsparametern geändert werden, sondern unter VPN / Allgemein / IPSec-over-HTTPs annehmen anhaken

Beim 2. Punkt war mein Fehler. Ich hatte die 443 eingehend versucht explizit über die Verbindungsparameter zu konfigurieren, nicht implizit durch die IPSec-over-HTTPs Option.