R883VAW (10.50.178) VPN - dynamisches Gateway kein Aufbau möglich

[vinet]

hallo liebe Lancom Comunity

ich beobachte evtl. einen Fehler in der Firmware der sich auf die Angabe eines Gateways im Ipsec IKEv2 VPN bezieht.


der VPN Tunnel steht von Router1 -> WAN 5G -> WAN DSL -> Router2 (Firmware 10.72)

VPN Tunnel baut auf von Router1 -> DSL -> DSL -> Router3 (10.50) - hier sei noch gesagt der Tunnel baut nur auf wenn die IP der Gegenstelle im VPN hinterlegt ist. Beim leer lassen oder der 0.0.0.0 kommt immer VPN ID Fehler

VPN baut nicht auf Router1 -> WAN 5G -> DSL -> Router3 (10.50)

[PappaBaer]

Moin,

ich verstehe hier nur Bahnhof. Wer ist bei Dir Initiator und wer Responder? Der Initiator muss natürlich die Gateway-Adresse des Responders eingetragen haben. Der Responder braucht die vom Initiator nicht. Haltezeit bei Initiator 9999 und beim Responder 0.

Grüße,
Torsten

[vinet]

okay ich versuch nochmal ein anderen Ansatz:

der Initiator ist ein R883VAW Firmware 10.50 über ein 5G Mobilfunkmodem

der Responder ist ebenfalls ein R883VAW Firmware 10.50 über eine DSL Anbindung (Im VPN IKev2 ist das Gateway mit 0.0.0.0 hinterlegt)

Nun bekomme ich im trace beim Responder immer Fehler ausgeworfen da er eine VPN ID möchte.


Wenn ich die Verbindung über DSL zu DSL mit festen WAN IPs mache baut der Tunnel sofort auf. Allerdings bekomme ich ebenfalls ein Fehler falls ich beim Responder die 0.0.0.0 als Gateway einstelle.

[PappaBaer]

Moin,

die Haltezeiten hast Du entsprechend eingetragen?

Grüße,
Torsten

[5624]

Hast du der IKEv2-Verbindung eine entsprechende Authentifizierung mitgegeben?

Wenn du zwei feste IP-Adressen hast, reicht dieses aus. Da trägt man dann einfach den PSK ein, ohne irgendeine zusätzliche Identität und es funktioniert (bei IKEv1 war dies der Main Mode mit PSK).

Da bei dir aber eine Seite dynamisch ist, wird eine Identität benötigt, mit der sich der Router zu erkennen gibt. Diese muss gegenläufig konfiguriert werden. Also der Initiator meldet sich mit seiner lokalen Identität, und der Responder erwartet die selbe Kennung als entfernte Identität. Und das ganze dann auch nochmal andersrum (Responder lokale Identität = Initiator entfernte Identität).

[GrandDixence]

Nun bekomme ich im trace beim Responder immer Fehler ausgeworfen da er eine VPN ID möchte.

Der Aufbau eines VPN-Tunnels mit IKEv2/IPSec läuft über 4 IKE-Telegramme.
https://community.f5.com/t5/technical-a ... a-p/281164

Erst im IKE-Telegramm Nr. 3 (IKE-AUTH_Request) und Nr. 4 (IKE-AUTH_Response) werden die VPN-Gegenstellen authentifiziert. Für das erste (IKE-SA_INIT_Request) und zweite IKE-Telegramm (IKE-SA_INIT_Response) kann die VPN-Gegenstelle einzig über die IP-Adresse oder den DNS-Namen identifiziert werden. Ist eine Identifikation der VPN-Gegenstelle zum Zeitpunkt des 1. oder 2. IKE-Telegramm des VPN-Tunnelaufbau nicht möglich, muss ein DEFAULT-Gegenstelle in der VPN-Konfiguration vorgesehen werden. Hier befindet sich die VPN-Gegenstelle hinter einem NAT, was eine Identifikation über die öffentliche IPv4-Adresse verunmöglicht.

fragen-zum-thema-vpn-f14/keine-ikev2-ve ... ml#p104295

Siehe auch die entsprechende VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

[vinet]

wieso funktioniert das dann bei der Firmware 10.72? scheint wohl nur bei der 10.50 zu Problemen zu kommen.

Auch wenn beide Seiten eine fest WAN IP haben ist ein VPN Aufbau mit der Firmware 10.50 bei hinterlegten 0.0.0.0 Gateway Adresse nicht möglich.