IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Alle allgemeinen Fragen zum VPN Thema.

Moderator: Lancom-Systems Moderatoren

Antworten
blackeagle2002de
Beiträge: 135
Registriert: 23 Jan 2005, 14:47
Kontaktdaten:

IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Beitrag von blackeagle2002de » 17 Feb 2019, 22:15

Hallo,

wir haben in den Vergangenen Wochen aufgrund von Watchdogs unser VPN Load Balancing von Extranet PPTP auf den IKEv2 Load-Balancer gem. Lancom Anleitung umgestellt. Der IKEv2 Load-Balancer hat mit LCOS 10.12 soweit auch ganz gut funktioniert. Mit dem Update auf LCOS 10.20 kommt es jedoch zu merkwürdigen Verbindungsabbrüchen der VPN Verbindungen. In der Zentrale sind 5 Internet Leitungen eingerichtet, in den Außenstellen 2-3. Alle Load-Balancer sind mit 4 VPN-Verbindungen eingerichtet, bei den Außenstellen werden daher entsprechend bis zu zwei VPN-Verbindungen über ein Internet Gateway aufgebaut. Das Fehlverhalten betrifft mehrere Außenstellen, soll hier jedoch nur an einer Außenstelle dokumentiert werden. Das Fehlverhalten betrifft alle 10.20 Releaseversionen. Es brechen von den 4 über den Loadbalancer zusammengefassten VPN-Verbindungen genau alle 10 Minuten ein oder zwei Verbindungen ab. Die Außenstellen bauen die VPN-Verbindungen aktiv auf. Bei allen VPN Verbindungen ist ein Polling auf den Router der Gegenseite eingerichtet, da uns die 30 Sekunden per DPD für die RDP Verbindung zu langsam ist. Hier nachfolgend das Geräteaktivitätenprotokoll der Zentrale:
42 17.02.2019 08:02:20 VPN Nicht verbunden mit Außenstelle_B_4
42 17.02.2019 08:02:20 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 08:02:20 VPN Nicht verbunden mit Außenstelle_A_4
42 17.02.2019 08:02:21 VPN Nicht verbunden mit Außenstelle_C_4
26 17.02.2019 08:02:23 VPN Start der Protokollverhandlung mit Außenstelle_B_4 (über VODA_SDSL)
25 17.02.2019 08:02:23 VPN Abgehender Ruf zu Außenstelle_A_4 (über VODA_SDSL)
43 17.02.2019 08:02:23 VPN Nicht verbunden mit Außenstelle_A_4 - Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindungsaufbau) [0x1104]
25 17.02.2019 08:02:23 VPN Abgehender Ruf zu Außenstelle_A_3 (über VODA_SDSL)
43 17.02.2019 08:02:23 VPN Nicht verbunden mit Außenstelle_A_3 - Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindungsaufbau) [0x1104]
26 17.02.2019 08:02:23 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
28 17.02.2019 08:02:24 VPN Verbunden mit Außenstelle_B_4 (über VODA_SDSL)
26 17.02.2019 08:02:24 VPN Start der Protokollverhandlung mit Außenstelle_C_4 (über KABELD)
28 17.02.2019 08:02:24 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
28 17.02.2019 08:02:25 VPN Verbunden mit Außenstelle_C_4 (über KABELD)
26 17.02.2019 08:02:28 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über VODA_SDSL)
28 17.02.2019 08:02:29 VPN Verbunden mit Außenstelle_A_4 (über VODA_SDSL)
42 17.02.2019 08:12:20 VPN Nicht verbunden mit Außenstelle_B_4
42 17.02.2019 08:12:21 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 08:12:21 VPN Nicht verbunden mit Außenstelle_A_4
26 17.02.2019 08:12:23 VPN Start der Protokollverhandlung mit Außenstelle_B_4 (über KABELD)
42 17.02.2019 08:12:23 VPN Nicht verbunden mit Außenstelle_C_3
26 17.02.2019 08:12:24 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
28 17.02.2019 08:12:24 VPN Verbunden mit Außenstelle_B_4 (über KABELD)
28 17.02.2019 08:12:26 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
26 17.02.2019 08:12:26 VPN Start der Protokollverhandlung mit Außenstelle_C_3 (über VDSL_2)
28 17.02.2019 08:12:27 VPN Verbunden mit Außenstelle_C_3 (über VDSL_2)
26 17.02.2019 08:12:28 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über KABELD)
28 17.02.2019 08:12:29 VPN Verbunden mit Außenstelle_A_4 (über KABELD)
42 17.02.2019 08:22:20 VPN Nicht verbunden mit Außenstelle_B_4
42 17.02.2019 08:22:20 VPN Nicht verbunden mit Außenstelle_A_4
42 17.02.2019 08:22:22 VPN Nicht verbunden mit Außenstelle_C_4
26 17.02.2019 08:22:23 VPN Start der Protokollverhandlung mit Außenstelle_B_4 (über VODA_SDSL)
26 17.02.2019 08:22:23 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über VODA_SDSL)
28 17.02.2019 08:22:24 VPN Verbunden mit Außenstelle_B_4 (über VODA_SDSL)
26 17.02.2019 08:22:24 VPN Start der Protokollverhandlung mit Außenstelle_C_4 (über VODA_SDSL)
28 17.02.2019 08:22:24 VPN Verbunden mit Außenstelle_A_4 (über VODA_SDSL)
28 17.02.2019 08:22:25 VPN Verbunden mit Außenstelle_C_4 (über VODA_SDSL)
42 17.02.2019 08:32:21 VPN Nicht verbunden mit Außenstelle_A_4
42 17.02.2019 08:32:21 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 08:32:22 VPN Nicht verbunden mit Außenstelle_C_3
26 17.02.2019 08:32:24 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
26 17.02.2019 08:32:24 VPN Start der Protokollverhandlung mit Außenstelle_C_3 (über VDSL_2)
28 17.02.2019 08:32:25 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
28 17.02.2019 08:32:25 VPN Verbunden mit Außenstelle_C_3 (über VDSL_2)
26 17.02.2019 08:32:29 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über KABELD)
28 17.02.2019 08:32:30 VPN Verbunden mit Außenstelle_A_4 (über KABELD)
42 17.02.2019 08:42:20 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 08:42:20 VPN Nicht verbunden mit Außenstelle_A_4
26 17.02.2019 08:42:23 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
25 17.02.2019 08:42:23 VPN Abgehender Ruf zu Außenstelle_A_4 (über VODA_SDSL)
43 17.02.2019 08:42:23 VPN Nicht verbunden mit Außenstelle_A_4 - Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindungsaufbau) [0x1104]
28 17.02.2019 08:42:24 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
26 17.02.2019 08:42:27 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über VODA_SDSL)
42 17.02.2019 08:42:27 VPN Nicht verbunden mit Außenstelle_C_4
28 17.02.2019 08:42:28 VPN Verbunden mit Außenstelle_A_4 (über VODA_SDSL)
26 17.02.2019 08:42:30 VPN Start der Protokollverhandlung mit Außenstelle_C_4 (über KABELD)
28 17.02.2019 08:42:32 VPN Verbunden mit Außenstelle_C_4 (über KABELD)
42 17.02.2019 08:52:20 VPN Nicht verbunden mit Außenstelle_B_4
42 17.02.2019 08:52:21 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 08:52:21 VPN Nicht verbunden mit Außenstelle_A_4
42 17.02.2019 08:52:21 VPN Nicht verbunden mit Außenstelle_C_4
26 17.02.2019 08:52:23 VPN Start der Protokollverhandlung mit Außenstelle_B_4 (über KABELD)
26 17.02.2019 08:52:24 VPN Start der Protokollverhandlung mit Außenstelle_C_4 (über VODA_SDSL)
26 17.02.2019 08:52:24 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
25 17.02.2019 08:52:24 VPN Abgehender Ruf zu Außenstelle_A_4 (über VODA_SDSL)
43 17.02.2019 08:52:24 VPN Nicht verbunden mit Außenstelle_A_4 - Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindungsaufbau) [0x1104]
28 17.02.2019 08:52:24 VPN Verbunden mit Außenstelle_B_4 (über KABELD)
28 17.02.2019 08:52:25 VPN Verbunden mit Außenstelle_C_4 (über VODA_SDSL)
28 17.02.2019 08:52:25 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
26 17.02.2019 08:52:28 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über KABELD)
28 17.02.2019 08:52:29 VPN Verbunden mit Außenstelle_A_4 (über KABELD)
42 17.02.2019 08:52:35 VPN Nicht verbunden mit Außenstelle_C_4
26 17.02.2019 08:52:37 VPN Start der Protokollverhandlung mit Außenstelle_C_4 (über KABELD)
28 17.02.2019 08:52:38 VPN Verbunden mit Außenstelle_C_4 (über KABELD)
42 17.02.2019 09:02:21 VPN Nicht verbunden mit Außenstelle_A_4
42 17.02.2019 09:02:21 VPN Nicht verbunden mit Außenstelle_A_3
42 17.02.2019 09:02:22 VPN Nicht verbunden mit Außenstelle_C_3
26 17.02.2019 09:02:24 VPN Start der Protokollverhandlung mit Außenstelle_A_3 (über VDSL_2)
25 17.02.2019 09:02:24 VPN Abgehender Ruf zu Außenstelle_A_4 (über VODA_SDSL)
43 17.02.2019 09:02:24 VPN Nicht verbunden mit Außenstelle_A_4 - Kein passender Eintrag in PPP-Liste vorhanden (Aktiver Verbindungsaufbau) [0x1104]
26 17.02.2019 09:02:24 VPN Start der Protokollverhandlung mit Außenstelle_C_3 (über VDSL_2)
28 17.02.2019 09:02:25 VPN Verbunden mit Außenstelle_A_3 (über VDSL_2)
28 17.02.2019 09:02:26 VPN Verbunden mit Außenstelle_C_3 (über VDSL_2)
26 17.02.2019 09:02:29 VPN Start der Protokollverhandlung mit Außenstelle_A_4 (über VODA_SDSL)
28 17.02.2019 09:02:30 VPN Verbunden mit Außenstelle_A_4 (über VODA_SDSL)
Nachfolgend noch der VPN-Trace aus der Zentrale und einer der vorgenannten Außenstellen (zu unterschiedlichen Zeitpunkten, aber der Vorgang wiederholt sich ja alle 10 Minuten)


VPN-Trace Außenstelle:

root@Außenstelle_A:/
> trace + vpn-statusVPN-Status ON

root@Außenstelle_A:/
>
[VPN-Status] 2019/02/17 11:52:17,248
Peer Zentrale_1: NAT-T keep-alive (0xFF) sent physically
transport: [id: 129, UDP (17) {outgoing, fixed source address}, dst: X.X.X.X, tag 1 (U), src: 192.168.0.2, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1500, (R) iface: KABELD (5), next hop: 192.168.0.1], local port: 4500, remote port: 4500

[VPN-Status] 2019/02/17 11:52:21,580
VPN: disconnecting Zentrale_4 (Y.Y.Y.Y)

[VPN-Status] 2019/02/17 11:52:21,580
VPN: Error: ICMP-conn.-Error (0x0113) for Zentrale_4 (Y.Y.Y.Y)

[VPN-Status] 2019/02/17 11:52:21,580
VPN: WAN state changed to WanDisconnect for Zentrale_4 (Y.Y.Y.Y), called by: 01a2928c

[VPN-Status] 2019/02/17 11:52:21,581
Disconnect Request for peer Zentrale_4 (ikev2)
Deleting IKE_SA (ISAKMP-PEER-Zentrale_4, Zentrale_4)
CHILD_SA (Zentrale_4, 'IPSEC-0-Zentrale_4-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x160B9D84 Inbound-SPI 0x062A863F) removed from SADB
CHILD_SA (Zentrale_4, 'IPSEC-0-Zentrale_4-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x160B9D84 Inbound-SPI 0x062A863F) freed
Peer Zentrale_4: Constructing an INFORMATIONAL-REQUEST for send
Message scheduled for retransmission (1) in 6.426671 seconds
Sending an INFORMATIONAL-REQUEST of 96 bytes (initiator encrypted)
Gateways: Z.Z.Z.Z:500-->Y.Y.Y.Y:500, tag 2 (UDP)
SPIs: 0x35930FB5E07BDB03BE9F5A2092F995B0, Message-ID 2
IKE_SA (Zentrale_4, 'ISAKMP-PEER-Zentrale_4' IPSEC_IKE SPIs 0x35930FB5E07BDB03BE9F5A2092F995B0) removed from SADB

DISCONNECT-RESPONSE sent for handle 17

[VPN-Status] 2019/02/17 11:52:21,581
vpn-maps[17], remote: Zentrale_4, idle, static-name

[VPN-Status] 2019/02/17 11:52:21,582
selecting next remote gateway using strategy eFirst for Zentrale_4
=> no remote gateway selected

[VPN-Status] 2019/02/17 11:52:21,582
selecting first remote gateway using strategy eFirst for Zentrale_4
=> CurrIdx=0, IpStr=>W.W.W.W<, IpAddr=W.W.W.W, IpTtl=0s

[VPN-Status] 2019/02/17 11:52:21,582
VPN: installing ruleset for Zentrale_4 (W.W.W.W)

[VPN-Status] 2019/02/17 11:52:21,582
Config parser: Start

[VPN-Status] 2019/02/17 11:52:21,582
Config parser: Finish
Wall clock time: 0 ms
CPU time: 0 ms

[VPN-Status] 2019/02/17 11:52:21,582
VPN: WAN state changed to WanIdle for Zentrale_4 (W.W.W.W), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:21,584
Tearing down ipsec-0-Zentrale_4-pr0-l0-r0, because its remote gateway has changed from Y.Y.Y.Y to W.W.W.W

[VPN-Status] 2019/02/17 11:52:21,594
VPN: rulesets installed

[VPN-Status] 2019/02/17 11:52:21,610
IKE log: 115221.610217 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,610
IKE log: 115221.610340 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,610
IKE log: 115221.610439 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,689
IKE log: 115221.689142 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,690
IKE log: 115221.690738 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,730
IKE log: 115221.730330 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,769
IKE log: 115221.769821 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,769
IKE log: 115221.769940 Default pf_key_v2_acquire: -Could not find an IKE_SA for peer Zentrale_4


[VPN-Status] 2019/02/17 11:52:21,840
VPN: disconnecting Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:21,840
VPN: Error: ICMP-conn.-Error (0x0113) for Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:21,840
VPN: WAN state changed to WanDisconnect for Zentrale_3 (V.V.V.V), called by: 01a2928c

[VPN-Status] 2019/02/17 11:52:21,841
Disconnect Request for peer Zentrale_3 (ikev2)
Deleting IKE_SA (ISAKMP-PEER-Zentrale_3, Zentrale_3)
CHILD_SA (Zentrale_3, 'IPSEC-0-Zentrale_3-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x4BB43652 Inbound-SPI 0x4101CCDF) removed from SADB
CHILD_SA (Zentrale_3, 'IPSEC-0-Zentrale_3-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x4BB43652 Inbound-SPI 0x4101CCDF) freed
Peer Zentrale_3: Constructing an INFORMATIONAL-REQUEST for send
Message scheduled for retransmission (1) in 3.441813 seconds
Sending an INFORMATIONAL-REQUEST of 96 bytes (initiator encrypted)
Gateways: Z.Z.Z.Z:500-->V.V.V.V:500, tag 2 (UDP)
SPIs: 0xDB5DE09A95478412C533CE1FCCA0A3FF, Message-ID 2
IKE_SA (Zentrale_3, 'ISAKMP-PEER-Zentrale_3' IPSEC_IKE SPIs 0xDB5DE09A95478412C533CE1FCCA0A3FF) removed from SADB

DISCONNECT-RESPONSE sent for handle 16

[VPN-Status] 2019/02/17 11:52:21,841
vpn-maps[16], remote: Zentrale_3, idle, dns-name, static-name

[VPN-Status] 2019/02/17 11:52:21,842
selecting next remote gateway using strategy eFirst for Zentrale_3
=> no remote gateway selected

[VPN-Status] 2019/02/17 11:52:21,842
selecting first remote gateway using strategy eFirst for Zentrale_3
=> CurrIdx=0, IpStr=>Zentralevdsl2.dyndns.org<, IpAddr=V.V.V.V, IpTtl=60s

[VPN-Status] 2019/02/17 11:52:21,842
VPN: installing ruleset for Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:21,842
Config parser: Start

[VPN-Status] 2019/02/17 11:52:21,842
Config parser: Finish
Wall clock time: 0 ms
CPU time: 0 ms

[VPN-Status] 2019/02/17 11:52:21,842
VPN: WAN state changed to WanIdle for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:21,853
VPN: rulesets installed

[VPN-Status] 2019/02/17 11:52:21,923
Peer Zentrale_4 [initiator]: Received an INFORMATIONAL-RESPONSE of 96 bytes (encrypted)
Gateways: Z.Z.Z.Z:500<--Y.Y.Y.Y:500
SPIs: 0x35930FB5E07BDB03BE9F5A2092F995B0, Message-ID 2

[VPN-Status] 2019/02/17 11:52:21,924
IKE_SA (Zentrale_4, 'ISAKMP-PEER-Zentrale_4' IPSEC_IKE SPIs 0x35930FB5E07BDB03BE9F5A2092F995B0) freed

[VPN-Status] 2019/02/17 11:52:21,924
DISCONNECT-RESPONSE sent for handle 17

[VPN-Status] 2019/02/17 11:52:21,924
VPN: Zentrale_4 (W.W.W.W) disconnected

[VPN-Status] 2019/02/17 11:52:21,924
vpn-maps[17], remote: Zentrale_4, idle, static-name

[VPN-Status] 2019/02/17 11:52:21,983
Peer Zentrale_3 [initiator]: Received an INFORMATIONAL-RESPONSE of 96 bytes (encrypted)
Gateways: Z.Z.Z.Z:500<--V.V.V.V:500
SPIs: 0xDB5DE09A95478412C533CE1FCCA0A3FF, Message-ID 2

[VPN-Status] 2019/02/17 11:52:21,984
IKE_SA (Zentrale_3, 'ISAKMP-PEER-Zentrale_3' IPSEC_IKE SPIs 0xDB5DE09A95478412C533CE1FCCA0A3FF) freed

[VPN-Status] 2019/02/17 11:52:21,984
DISCONNECT-RESPONSE sent for handle 16

[VPN-Status] 2019/02/17 11:52:21,984
VPN: Zentrale_3 (V.V.V.V) disconnected

[VPN-Status] 2019/02/17 11:52:21,984
vpn-maps[16], remote: Zentrale_3, idle, dns-name, static-name

[VPN-Status] 2019/02/17 11:52:24,850
VPN: WAN state changed to WanCall for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:24,850
starting external DNS resolution for Zentrale_3
IpStr=>Zentralevdsl2.dyndns.org<, IpAddr(old)=V.V.V.V, IpTtl(old)=60s

[VPN-Status] 2019/02/17 11:52:24,850
VPN: connecting to Zentrale_3 (V.V.V.V ikev2)

[VPN-Status] 2019/02/17 11:52:24,850
vpn-maps[16], remote: Zentrale_3, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:24,888
external DNS resolution for Zentrale_3
IpStr=>Zentralevdsl2.dyndns.org<, IpAddr(old)=0.0.0.0, IpTtl(old)=60s
IpStr=>Zentralevdsl2.dyndns.org<, IpAddr(new)=V.V.V.V, IpTtl(new)=60s

[VPN-Status] 2019/02/17 11:52:24,889
VPN: WAN state changed to WanIdle for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:24,889
VPN: WAN state changed to WanCall for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:24,889
VPN: connecting to Zentrale_3 (V.V.V.V ikev2)

[VPN-Status] 2019/02/17 11:52:24,889
vpn-maps[16], remote: Zentrale_3, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:24,889
vpn-maps[16], remote: Zentrale_3, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:24,889
vpn-maps[16], remote: Zentrale_3, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:24,889
VPN: installing ruleset for Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:24,889
Config parser: Start

[VPN-Status] 2019/02/17 11:52:24,889
Config parser: Finish
Wall clock time: 0 ms
CPU time: 0 ms

[VPN-Status] 2019/02/17 11:52:24,890
VPN: ruleset installed for Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:24,890
VPN: start IKE negotiation for Zentrale_3 (V.V.V.V)

[VPN-Status] 2019/02/17 11:52:24,890
VPN: WAN state changed to WanProtocol for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:24,894
VPN: rulesets installed

[VPN-Status] 2019/02/17 11:52:24,897
Received Connection-Request for Zentrale_3 (ikev2)
transport: [id: 23144, UDP (17) {outgoing, fixed source address}, dst: V.V.V.V, tag 2 (U), src: Z.Z.Z.Z, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1492, (R) iface: T-DSL_2 (8)], local port: 500, remote port: 500
Establishing connection(s): IPSEC-0-Zentrale_3-PR0-L0-R0
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4A74DA001431A3600000000000000000) entered to SADB
Peer Zentrale_3: Constructing an IKE_SA_INIT-REQUEST for send
Starting an IKEv2 negotiation
+IKE-SA:
IKE-Proposal-1 (7 transforms)
ENCR : AES-GCM-16-256 AES-CBC-256
PRF : PRF-HMAC-SHA-256 PRF-HMAC-SHA1
INTEG: HMAC-SHA-256 HMAC-SHA1
DH : 14
+KE-DH-Group 14 (2048 bits)
Message scheduled for retransmission (1) in 5.509496 seconds
Sending an IKE_SA_INIT-REQUEST of 552 bytes (initiator)
Gateways: Z.Z.Z.Z:500-->V.V.V.V:500, tag 2 (UDP)
SPIs: 0x4A74DA001431A3600000000000000000, Message-ID 0

[VPN-Status] 2019/02/17 11:52:25,087
Peer <UNKNOWN> [initiator]: Received an IKE_SA_INIT-RESPONSE of 541 bytes
Gateways: Z.Z.Z.Z:500<--V.V.V.V:500
SPIs: 0x4A74DA001431A36030C9778FB51CE57A, Message-ID 0
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4A74DA001431A3600000000000000000) removed from SADB
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4A74DA001431A36030C9778FB51CE57A) entered to SADB
Received 3 notifications:
+NAT_DETECTION_SOURCE_IP(0x6A71B10A7B489625EA2CC8DF8796E5CEEB12F323) (STATUS)
+NAT_DETECTION_DESTINATION_IP(0x4E579B9F4D9656330811161E32748C246C5D62A4) (STATUS)
+DEVICE-ID(0x5D8F8AD11D8F9EFBA598FA36370C6096E322950DD380B931B2A4FCC53764FC5B) (PRIVATE)
Peer (responder) is not behind a NAT. NAT-T is disabled
We (initiator) are not behind a NAT. NAT-T is disabled
+IKE-SA:
IKE-Proposal-1 (4 transforms)
ENCR : AES-CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: HMAC-SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)
IKE_SA_INIT [initiator] for peer Zentrale_3 initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x4A74DA001431A360, responder cookie: 0x30C9778FB51CE57A
SA ISAKMP for peer Zentrale_3 Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 IKE-DH-Group 14 PRF-HMAC-SHA-256
life time soft 02/18/2019 11:52:25 (in 86400 sec) / 0 kb
life time hard 02/18/2019 17:52:25 (in 108000 sec) / 0 kb
DPD: NONE
Negotiated: IKE_FRAGMENTATION

[VPN-Status] 2019/02/17 11:52:25,090
Establishing IKE_AUTH exchange for IPSEC-0-Zentrale_3-PR0-L0-R0 (Zentrale_3)
CHILD_SA (UNKNOWN, 'UNKNOWN' ) entered to SADB
Peer Zentrale_3: Constructing an IKE_AUTH-REQUEST for send
Starting a CHILD_SA negotiation for IPSEC-0-Zentrale_3-PR0-L0-R0
+CHILD-SA:
ESP-Proposal-1 My-SPI: 0xCAF684C9 (5 transforms)
ENCR : AES-GCM-16-256 AES-CBC-256
INTEG: HMAC-SHA-256 HMAC-SHA1
ESN : NONE
+Local-ID hgbmAußenstelle_A.mail_3@Zentrale.de:USER_FQDN
+I use AUTH(PSK)
+TSi 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
+TSr 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
Message scheduled for retransmission (1) in 7.105615 seconds
Sending an IKE_AUTH-REQUEST of 272 bytes (initiator encrypted)
Gateways: Z.Z.Z.Z:500-->V.V.V.V:500, tag 2 (UDP)
SPIs: 0x4A74DA001431A36030C9778FB51CE57A, Message-ID 1

[VPN-Status] 2019/02/17 11:52:25,170
Peer Zentrale_3 [initiator]: Received an IKE_AUTH-RESPONSE of 256 bytes (encrypted)
Gateways: Z.Z.Z.Z:500<--V.V.V.V:500
SPIs: 0x4A74DA001431A36030C9778FB51CE57A, Message-ID 1
Received 1 notification:
+INITIAL_CONTACT (STATUS)
+Received-ID Zentrale.Außenstelle_A_3@Zentrale.de:USER_FQDN matches the Expected-ID Zentrale.Außenstelle_A_3@Zentrale.de:USER_FQDN
+Peer identified: Zentrale_3
+Peer uses AUTH(PSK)
+Authentication successful

IKE_SA_INIT [initiator] for peer Zentrale_3 initiator id hgbmAußenstelle_A.mail_3@Zentrale.de, responder id Zentrale.Außenstelle_A_3@Zentrale.de
initiator cookie: 0x4A74DA001431A360, responder cookie: 0x30C9778FB51CE57A
SA ISAKMP for peer Zentrale_3 Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 IKE-DH-Group 14 PRF-HMAC-SHA-256
life time soft 02/18/2019 11:52:25 (in 86400 sec) / 0 kb
life time hard 02/18/2019 17:52:25 (in 108000 sec) / 0 kb
DPD: 30 sec
Negotiated: IKE_FRAGMENTATION

TSi: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
TSr: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
IKE_SA (Zentrale_3, 'ISAKMP-PEER-Zentrale_3' IPSEC_IKE SPIs 0x4A74DA001431A36030C9778FB51CE57A) removed from SADB
IKE_SA (Zentrale_3, 'ISAKMP-PEER-Zentrale_3' IPSEC_IKE SPIs 0x4A74DA001431A36030C9778FB51CE57A) entered to SADB
+CHILD-SA:
ESP-Proposal-1 Peer-SPI: 0xEBCD322D (3 transforms)
ENCR : AES-CBC-256
INTEG: HMAC-SHA-256
ESN : NONE

CHILD_SA [initiator] done with 2 SAS for peer Zentrale_3 rule IPSEC-0-Zentrale_3-PR0-L0-R0
Z.Z.Z.Z:500<--V.V.V.V:500, Routing tag 2, Com-channel 16
rule:' ipsec 0.0.0.0/0 <-> 0.0.0.0/0
outgoing SA ESP [0xEBCD322D] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
incoming SA ESP [0xCAF684C9] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
life time soft 02/17/2019 18:16:25 (in 23040 sec) / 1600000 kb
life time hard 02/17/2019 19:52:25 (in 28800 sec) / 2000000 kb
tunnel between src: Z.Z.Z.Z dst: V.V.V.V

[VPN-Status] 2019/02/17 11:52:26,226
VPN: Zentrale_3 connected

[VPN-Status] 2019/02/17 11:52:26,227
VPN: WAN state changed to WanConnect for Zentrale_3 (V.V.V.V), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:26,227
vpn-maps[16], remote: Zentrale_3, connected, dns-name, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:26,229
starting external DNS resolution for Zentrale_2
IpStr=>Zentralevdsl1.dyndns.org<, IpAddr(old)=U.U.U.U, IpTtl(old)=60s

[VPN-Status] 2019/02/17 11:52:26,249
external DNS resolution for Zentrale_2
IpStr=>Zentralevdsl1.dyndns.org<, IpAddr(old)=0.0.0.0, IpTtl(old)=60s
IpStr=>Zentralevdsl1.dyndns.org<, IpAddr(new)=U.U.U.U, IpTtl(new)=60s

[VPN-Status] 2019/02/17 11:52:29,230
VPN: WAN state changed to WanCall for Zentrale_4 (W.W.W.W), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:29,230
VPN: connecting to Zentrale_4 (W.W.W.W ikev2)

[VPN-Status] 2019/02/17 11:52:29,230
vpn-maps[17], remote: Zentrale_4, nego, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:29,230
vpn-maps[17], remote: Zentrale_4, nego, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:29,230
vpn-maps[17], remote: Zentrale_4, nego, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:29,230
VPN: start IKE negotiation for Zentrale_4 (W.W.W.W)

[VPN-Status] 2019/02/17 11:52:29,231
VPN: WAN state changed to WanProtocol for Zentrale_4 (W.W.W.W), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:29,237
Received Connection-Request for Zentrale_4 (ikev2)
transport: [id: 23187, UDP (17) {outgoing, fixed source address}, dst: W.W.W.W, tag 2 (U), src: Z.Z.Z.Z, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1492, (R) iface: T-DSL_2 (8)], local port: 500, remote port: 500
Establishing connection(s): IPSEC-0-Zentrale_4-PR0-L0-R0
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4D353F45C22E6B380000000000000000) entered to SADB
Peer Zentrale_4: Constructing an IKE_SA_INIT-REQUEST for send
Starting an IKEv2 negotiation
+IKE-SA:
IKE-Proposal-1 (7 transforms)
ENCR : AES-GCM-16-256 AES-CBC-256
PRF : PRF-HMAC-SHA-256 PRF-HMAC-SHA1
INTEG: HMAC-SHA-256 HMAC-SHA1
DH : 14
+KE-DH-Group 14 (2048 bits)
Message scheduled for retransmission (1) in 4.893741 seconds
Sending an IKE_SA_INIT-REQUEST of 552 bytes (initiator)
Gateways: Z.Z.Z.Z:500-->W.W.W.W:500, tag 2 (UDP)
SPIs: 0x4D353F45C22E6B380000000000000000, Message-ID 0

[VPN-Status] 2019/02/17 11:52:29,238
Received Connection-Request for Zentrale_4 (ikev2)
transport: [id: 23188, UDP (17) {outgoing, fixed source address}, dst: W.W.W.W, tag 2 (U), src: Z.Z.Z.Z, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1492, (R) iface: T-DSL_2 (8)], local port: 500, remote port: 500
Establishing connection(s): IPSEC-0-Zentrale_4-PR0-L0-R0

[VPN-Status] 2019/02/17 11:52:29,339
Peer <UNKNOWN> [initiator]: Received an IKE_SA_INIT-RESPONSE of 541 bytes
Gateways: Z.Z.Z.Z:500<--W.W.W.W:500
SPIs: 0x4D353F45C22E6B385116226D088A7338, Message-ID 0
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4D353F45C22E6B380000000000000000) removed from SADB
IKE_SA (UNKNOWN, 'UNKNOWN' IPSEC_IKE SPIs 0x4D353F45C22E6B385116226D088A7338) entered to SADB
Received 3 notifications:
+NAT_DETECTION_SOURCE_IP(0x215612B38D4028F63898D9C5DE789C2F39826581) (STATUS)
+NAT_DETECTION_DESTINATION_IP(0xCB27BA071326552FCC3F3135F7620E6E62075771) (STATUS)
+DEVICE-ID(0x5D8F8AD11D8F9EFBA598FA36370C6096E322950DD380B931B2A4FCC53764FC5B) (PRIVATE)
Peer (responder) is behind a NAT
NAT-T enabled => switching on port 4500
We (initiator) are not behind a NAT. NAT-T is already enabled
+IKE-SA:
IKE-Proposal-1 (4 transforms)
ENCR : AES-CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: HMAC-SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)
Switching to port pair 4500 ( NAT-T keep-alive is off)
IKE_SA_INIT [initiator] for peer Zentrale_4 initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x4D353F45C22E6B38, responder cookie: 0x5116226D088A7338
NAT-T enabled. We are not behind a nat, the remote side is behind a nat
SA ISAKMP for peer Zentrale_4 Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 IKE-DH-Group 14 PRF-HMAC-SHA-256
life time soft 02/18/2019 11:52:29 (in 86400 sec) / 0 kb
life time hard 02/18/2019 17:52:29 (in 108000 sec) / 0 kb
DPD: NONE
Negotiated: IKE_FRAGMENTATION

[VPN-Status] 2019/02/17 11:52:29,342
Establishing IKE_AUTH exchange for IPSEC-0-Zentrale_4-PR0-L0-R0 (Zentrale_4)
CHILD_SA (UNKNOWN, 'UNKNOWN' ) entered to SADB
Peer Zentrale_4: Constructing an IKE_AUTH-REQUEST for send
Starting a CHILD_SA negotiation for IPSEC-0-Zentrale_4-PR0-L0-R0
+CHILD-SA:
ESP-Proposal-1 My-SPI: 0xB5EA2766 (5 transforms)
ENCR : AES-GCM-16-256 AES-CBC-256
INTEG: HMAC-SHA-256 HMAC-SHA1
ESN : NONE
+Local-ID hgbmAußenstelle_A.mail_4@Zentrale.de:USER_FQDN
+I use AUTH(PSK)
+TSi 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
+TSr 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
Message scheduled for retransmission (1) in 6.156967 seconds
Sending an IKE_AUTH-REQUEST of 272 bytes (initiator encrypted)
Gateways: Z.Z.Z.Z:4500-->W.W.W.W:4500, tag 2 (UDP)
SPIs: 0x4D353F45C22E6B385116226D088A7338, Message-ID 1

[VPN-Status] 2019/02/17 11:52:29,402
Peer Zentrale_4 [initiator]: Received an IKE_AUTH-RESPONSE of 256 bytes (encrypted)
Gateways: Z.Z.Z.Z:4500<--W.W.W.W:4500
SPIs: 0x4D353F45C22E6B385116226D088A7338, Message-ID 1
Updating remote port to 4500
Received 1 notification:
+INITIAL_CONTACT (STATUS)
+Received-ID Zentrale.Außenstelle_A_4@Zentrale.de:USER_FQDN matches the Expected-ID Zentrale.Außenstelle_A_4@Zentrale.de:USER_FQDN
+Peer identified: Zentrale_4
+Peer uses AUTH(PSK)
+Authentication successful

IKE_SA_INIT [initiator] for peer Zentrale_4 initiator id hgbmAußenstelle_A.mail_4@Zentrale.de, responder id Zentrale.Außenstelle_A_4@Zentrale.de
initiator cookie: 0x4D353F45C22E6B38, responder cookie: 0x5116226D088A7338
NAT-T enabled. We are not behind a nat, the remote side is behind a nat
SA ISAKMP for peer Zentrale_4 Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 IKE-DH-Group 14 PRF-HMAC-SHA-256
life time soft 02/18/2019 11:52:29 (in 86400 sec) / 0 kb
life time hard 02/18/2019 17:52:29 (in 108000 sec) / 0 kb
DPD: 30 sec
Negotiated: IKE_FRAGMENTATION

TSi: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
TSr: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
IKE_SA (Zentrale_4, 'ISAKMP-PEER-Zentrale_4' IPSEC_IKE SPIs 0x4D353F45C22E6B385116226D088A7338) removed from SADB
IKE_SA (Zentrale_4, 'ISAKMP-PEER-Zentrale_4' IPSEC_IKE SPIs 0x4D353F45C22E6B385116226D088A7338) entered to SADB
+CHILD-SA:
ESP-Proposal-1 Peer-SPI: 0xDCA6A244 (3 transforms)
ENCR : AES-CBC-256
INTEG: HMAC-SHA-256
ESN : NONE

CHILD_SA [initiator] done with 2 SAS for peer Zentrale_4 rule IPSEC-0-Zentrale_4-PR0-L0-R0
Z.Z.Z.Z:4500<--W.W.W.W:4500, Routing tag 2, Com-channel 17
rule:' ipsec 0.0.0.0/0 <-> 0.0.0.0/0
outgoing SA ESP [0xDCA6A244] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
incoming SA ESP [0xB5EA2766] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
life time soft 02/17/2019 18:16:29 (in 23040 sec) / 1600000 kb
life time hard 02/17/2019 19:52:29 (in 28800 sec) / 2000000 kb
tunnel between src: Z.Z.Z.Z dst: W.W.W.W

[VPN-Status] 2019/02/17 11:52:30,402
Peer Zentrale_2: NAT-T keep-alive (0xFF) sent physically
transport: [id: 89, UDP (17) {outgoing, fixed source address}, dst: U.U.U.U, tag 1 (U), src: 192.168.0.2, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1500, (R) iface: KABELD (5), next hop: 192.168.0.1], local port: 4500, remote port: 4500

[VPN-Status] 2019/02/17 11:52:30,447
VPN: Zentrale_4 connected

[VPN-Status] 2019/02/17 11:52:30,447
VPN: WAN state changed to WanConnect for Zentrale_4 (W.W.W.W), called by: 01a28e5c

[VPN-Status] 2019/02/17 11:52:30,448
vpn-maps[17], remote: Zentrale_4, connected, static-name, connected-by-name

[VPN-Status] 2019/02/17 11:52:37,402
Peer Zentrale_1: NAT-T keep-alive (0xFF) sent physically
transport: [id: 129, UDP (17) {outgoing, fixed source address}, dst: X.X.X.X, tag 1 (U), src: 192.168.0.2, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1500, (R) iface: KABELD (5), next hop: 192.168.0.1], local port: 4500, remote port: 4500

[VPN-Status] 2019/02/17 11:52:50,403
Peer Zentrale_2: NAT-T keep-alive (0xFF) sent physically
transport: [id: 89, UDP (17) {outgoing, fixed source address}, dst: U.U.U.U, tag 1 (U), src: 192.168.0.2, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu:

1500, (R) iface: KABELD (5), next hop: 192.168.0.1], local port: 4500, remote port: 4500
x

Goodbye
VPN-Trace Zentrale:
root@Zentrale:/
> trace + vpn-status @Außenstellen_A Außenstellen_A_4

VPN-Status ON @ Außenstellen_A_4

root@Zentrale:/
>
[VPN-Status] 2019/02/17 12:12:21,651
Peer Außenstellen_A_4: Received an INFORMATIONAL-REQUEST of 96 bytes (encrypted)
Gateways: Y.Y.Y.Y:500<--W.W.W.W:500
SPIs: 0xAC2AE7CC9CF32F42BE36AD812833E62A, Message-ID 2

[VPN-Status] 2019/02/17 12:12:21,652
Peer Außenstellen_A_4: Constructing an INFORMATIONAL-RESPONSE for send
IKE_SA (Außenstellen_A_4, 'ISAKMP-PEER-Außenstellen_A_4' IPSEC_IKE SPIs 0xAC2AE7CC9CF32F42BE36AD812833E62A) removed from SADB

CHILD_SA (Außenstellen_A_4, 'IPSEC-0-Außenstellen_A_4-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x3C3AE63F Inbound-SPI 0x296BA463) removed from SADB

Sending an INFORMATIONAL-RESPONSE of 96 bytes (encrypted)
VLAN-ID 0, Routing tag 0, Com-channel 94 (valid), hTxChan 3
Gateways: Y.Y.Y.Y:500-->W.W.W.W:500
SPIs: 0xAC2AE7CC9CF32F42BE36AD812833E62A, Message-ID 2

[VPN-Status] 2019/02/17 12:12:21,655
vpn-maps[94], remote: Außenstellen_A_4, idle, static-name

[VPN-Status] 2019/02/17 12:12:21,659
selecting first remote gateway using strategy eFirst for Außenstellen_A_4
=> no remote gateway selected

[VPN-Status] 2019/02/17 12:12:21,659
VPN: installing ruleset for Außenstellen_A_4 (0.0.0.0)

[VPN-Status] 2019/02/17 12:12:21,659
VPN: WAN state changed to WanDisconnect for Außenstellen_A_4 (0.0.0.0), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:21,663
VPN: WAN state changed to WanIdle for Außenstellen_A_4 (0.0.0.0), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:21,668
Tearing down ipsec-0-Außenstellen_A_4-pr0-l0-r0, because its remote gateway has changed from W.W.W.W to 0.0.0.0
-No policy for ipsec-0-Außenstellen_A_4-pr0-l0-r0. Remote-address is unspecified or zero

[VPN-Status] 2019/02/17 12:12:24,680
VPN: WAN state changed to WanCall for Außenstellen_A_4 (0.0.0.0), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:24,680
VPN: connecting to Außenstellen_A_4 (0.0.0.0 ikev2)

[VPN-Status] 2019/02/17 12:12:24,680
vpn-maps[94], remote: Außenstellen_A_4, nego, static-name, connected-by-name

[VPN-Status] 2019/02/17 12:12:24,685
VPN: Error: IFC-I-No-PPP-table-entry-matched (0x1104) for Außenstellen_A_4 (0.0.0.0)

[VPN-Status] 2019/02/17 12:12:24,685
VPN: Error: IFC-I-Negotiator-no-remote (0x1114) for Außenstellen_A_4 (0.0.0.0)

[VPN-Status] 2019/02/17 12:12:24,685
vpn-maps[94], remote: Außenstellen_A_4, idle, static-name

[VPN-Status] 2019/02/17 12:12:24,685
VPN: WAN state changed to WanIdle for Außenstellen_A_4 (0.0.0.0), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:28,819
Peer DEFAULT: Received an IKE_AUTH-REQUEST of 272 bytes (encrypted)
Gateways: 192.168.0.2:4500<--W.W.W.W:4500
SPIs: 0x28DB7BDE28E7C0D3F64843FE0A7557C2, Message-ID 1
CHILD_SA (UNKNOWN, 'UNKNOWN' ) entered to SADB

Received 1 notification:
+INITIAL_CONTACT (STATUS)
+Received-ID hgbmAußenstellen_A.mail_4@Zentrale.de:USER_FQDN matches the Expected-ID hgbmAußenstellen_A.mail_4@Zentrale.de:USER_FQDN
+Peer identified: Außenstellen_A_4
+Peer uses AUTH(PSK)
+Authentication successful
IKE_SA (Außenstellen_A_4, 'ISAKMP-PEER-Außenstellen_A_4' IPSEC_IKE SPIs 0x28DB7BDE28E7C0D3F64843FE0A7557C2) removed from SADB

IKE_SA (Außenstellen_A_4, 'ISAKMP-PEER-Außenstellen_A_4' IPSEC_IKE SPIs 0x28DB7BDE28E7C0D3F64843FE0A7557C2) entered to SADB

TSi: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
TSr: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
+CHILD-SA:
ESP-Proposal-1 Peer-SPI: 0x0E6C95EC (5 transforms)
ENCR : AES-GCM-16-256 AES-CBC-256
INTEG: HMAC-SHA-256 HMAC-SHA1
ESN : NONE

[VPN-Status] 2019/02/17 12:12:28,823
Peer Außenstellen_A_4: Constructing an IKE_AUTH-RESPONSE for send
+Local-ID Zentrale.Außenstellen_A_4@Zentrale.de:USER_FQDN
+I use AUTH(PSK)

IKE_SA_INIT [responder] for peer Außenstellen_A_4 initiator id hgbmAußenstellen_A.mail_4@Zentrale.de, responder id Zentrale.Außenstellen_A_4@Zentrale.de
initiator cookie: 0x28DB7BDE28E7C0D3, responder cookie: 0xF64843FE0A7557C2
NAT-T enabled. We are behind a nat, the remote side is not behind a nat
SA ISAKMP for peer Außenstellen_A_4 Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 IKE-DH-Group 14 PRF-HMAC-SHA-256
life time soft 02/18/2019 15:12:28 (in 97200 sec) / 0 kb
life time hard 02/18/2019 18:12:28 (in 108000 sec) / 0 kb
DPD: 30 sec
Negotiated: IKE_FRAGMENTATION

+TSi 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
+TSr 0: ( 0, 0-65535, 0.0.0.0-255.255.255.255)
+CHILD-SA:
ESP-Proposal-1 My-SPI: 0x724521BE (3 transforms)
ENCR : AES-CBC-256
INTEG: HMAC-SHA-256
ESN : NONE

CHILD_SA [responder] done with 2 SAS for peer Außenstellen_A_4 rule IPSEC-0-Außenstellen_A_4-PR0-L0-R0
192.168.0.2:4500-->W.W.W.W:4500, VLAN-ID 0, HW switch port 0, Routing tag 0, Com-channel 2
rule:' ipsec 0.0.0.0/0 <-> 0.0.0.0/0
outgoing SA ESP [0x0E6C95EC] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
incoming SA ESP [0x724521BE] Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA-256 PFS-DH-Group None ESN None
life time soft 02/17/2019 19:24:28 (in 25920 sec) / 1800000 kb
life time hard 02/17/2019 20:12:28 (in 28800 sec) / 2000000 kb
tunnel between src: 192.168.0.2 dst: W.W.W.W

Sending an IKE_AUTH-RESPONSE of 256 bytes (encrypted)
VLAN-ID 0, Routing tag 0, Com-channel 94 (valid), hTxChan 0
Gateways: 192.168.0.2:4500-->W.W.W.W:4500
SPIs: 0x28DB7BDE28E7C0D3F64843FE0A7557C2, Message-ID 1

[VPN-Status] 2019/02/17 12:12:28,823
VPN: WAN state changed to WanCalled for Außenstellen_A_4 (W.W.W.W), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:28,823
vpn-maps[94], remote: Außenstellen_A_4, nego, static-name, connected-by-name

[VPN-Status] 2019/02/17 12:12:28,824
VPN: wait for IKE negotiation from Außenstellen_A_4 (W.W.W.W)

[VPN-Status] 2019/02/17 12:12:28,824
VPN: WAN state changed to WanProtocol for Außenstellen_A_4 (W.W.W.W), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:30,865
VPN: Außenstellen_A_4 connected

[VPN-Status] 2019/02/17 12:12:30,865
VPN: WAN state changed to WanConnect for Außenstellen_A_4 (W.W.W.W), called by: 0186848c

[VPN-Status] 2019/02/17 12:12:30,865
vpn-maps[94], remote: Außenstellen_A_4, connected, static-name, connected-by-name
x

Goodbye

Sobald die Außenstelle auf LCOS 10.12 zurückgesetzt wird tritt das Verhalten nicht mehr auf. Hat irgendjemand eine Idee woran das liegen könnte? Vielen Dank und viele Grüße

blackeagle2002de

GrandDixence
Beiträge: 454
Registriert: 19 Aug 2014, 22:41

Re: IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Beitrag von GrandDixence » 18 Feb 2019, 09:10

Aus den Aufzeichnungen ist ersichtlich, dass das Ping nicht mit einem Pong beantwortet wurde (ICMP-Polling). Wegen dem fehlgeschlagenen ICMP-Polling wird die WAN-Netzwerkverbindung als "getrennt" erachtet. Was als Konsequenz die kontrollierte Trennung des über diese WAN-Netzwerkverbindung realisierten VPN-Tunnels zur Folge hat (Disconnect Request for peer Zentrale_4). Ob der letzte Schritt korrekt ist, kann ich nicht beurteilen.

Da keine Netzwerkleitung eine Paketverlustrate von 0.0000000 % aufweist, können Ping's oder Pong's bei der Übermittlung verloren gehen. Deshalb sollte das ICMP-Polling so konfiguriert sein, dass erst nach mehreren fehlgeschlagenen Pings die Netzwerkverbindung als "getrennt" erachtet wird. Empfehlenswert ist auch das Prüfen mit zwei verschiedenen Netzwerkkomponenten. Siehe auch /Setup/WAN/Polling-Tabelle/ unter:
lancom-systems-router-aeltere-modelle-z ... tml#p75861

Aus den Aufzeichnungen deute ich, dass das ICMP-Polling durch den VPN-Tunnel realisiert wurde (im Datenkanal/ESP). Dies halte ich für keine gute Idee. Siehe:
fragen-zum-thema-vpn-f14/fast-kein-traf ... tml#p93007

Ich empfehle das Studium der folgenden Beiträge:
feedback-lcos-release-update-betatest-f ... 17245.html

fragen-zum-thema-vpn-f14/fast-kein-traf ... 16434.html

Wenn die VPN-Endpunkte nur VPN-Tunnels zu LANCOM-Geräte realisieren, sollte die zu verwendende Verschlüsselung (Proposals) besser konfiguriert werden. Damit der VPN-Tunnel schneller aufgebaut wird. Und der VPN-Tunnel sicherer realisiert wird. Die Verwendung von GCM statt CBC ist aus Sicherheitsgründen empfehlenswert. Die Wahl der Verschlüsselung (Proposals) sollte konform zu BSI TR-02102-3 erfolgen. Siehe auch:

fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795

viewtopic.php?f=14&t=17207&p=97603#p97589

https://www.heise.de/security/artikel/K ... ml?seite=3

blackeagle2002de
Beiträge: 135
Registriert: 23 Jan 2005, 14:47
Kontaktdaten:

Re: IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Beitrag von blackeagle2002de » 18 Feb 2019, 17:30

Hallo GrandDixence,

vielen Dank für Deine ausführliche Antwort! Wir werden bei Gelegenheit die VPN-Verbindungen wir von Dir vorgeschlagen auf GCM und konform zu BSI TR-02102-3 umstellen. Bzgl. des ICMP-Pollings möchte ich den Zweck noch etwas genauer beschreiben, vielleicht gibt es ja noch einen anderen Weg das Ziel zu erreichen:

Wir setzen seit einigen Jahren das VPN-Loadbalancing ein und haben mehr oder weniger als einzigen Dienst RDP Sessions darüber laufen. Bei dem vorherigen PPTP VPN-Loadbalancing hatten wir auf jede PPTP Gegenstelle sogar ein Polling von 1 Sekunde mit nur zwei Wiederholungen auf den gegenüberliegenden Router eingestellt. Dies hat natürlich zu häufigeren Verbindungsabbrüchen der einzelnen, zu einem Load-Balancer zusammengefassten PPTP-Verbindungen geführt (die meisten liefen aber im Durchschnitt dennoch bis zu 10 Tage störungsfrei selbst bei diesem knappen Polling durch). Genau diese schnellen Abbrüche haben wir jedoch auch bezweckt. Dadurch dass wir an allen Standorten mehrere Internetleitungen über verschiedene Technologien verwenden (DSL, KABEL, LTE) ist ein solcher Abbruch überhaupt nicht tragisch, soweit er vom Router sofort bemerkt wird und der Datenverkehr sofort auf eine andere Verbindung des Loadbalancers umgeleitet wird. Denn wenn die PPTP Verbindung pollingbedingt abgebrochen ist, war dies für die Nutzer überhaupt nicht wahrnehmbar, die RPD Session hat kurz gestockt und lief dann (über eine andere Verbindung des Loadbalancers) weiter. Ohne das Polling ist der Bildschirm schwarz geworden und die RDP Verbindung abgebrochen, da die Router zu spät festgestellt haben, dass der Weg nicht mehr zur Verfügung steht.
Genau dies haben wir jetzt mit dem IKEv2 Loadbalancer eingerichtet, nur das wir das Polling auf 1 Wiederholung bei 4 Sekunden eingestellt haben (ein kürzeres hatte nach unserem Eindruck zu Problemen beim VPN Verbindungsaufbau geführt, dieses war aber noch kurz genug, so dass die RDP Verbindung nicht abbricht). Dies funktioniert wie beschrieben ebenfalls problemlos mit LCOS 10.12, nur mit dem Update auf LCOS 10.20 kommt es zu den Abbrüchen. Wir hatten in der IKEv2 Konfiguration schon den Wert der DPD Prüfung auf 4 Sekunden heruntergesetzt, um den gleichen Effekt zu erzielen, dies hat aber leider nicht funktioniert. Gibt es daher vielleicht noch einen anderen Weg das vorbeschriebene Ziel zu erreichen?

Vielen Dank und viele Grüße

blackeagle2002de

GrandDixence
Beiträge: 454
Registriert: 19 Aug 2014, 22:41

Re: IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Beitrag von GrandDixence » 18 Feb 2019, 20:47

Ein Überwachungsintervall (ICMP-, LCP-Polling, DPD) < 30 Sekunden UND mit weniger als 3 Wiederholungsversuche macht in meinen Augen keinen Sinn.

LANCOM hat das Betriebsystem LCOS so programmiert, dass das kürzeste DPD-Intervall 30 Sekunden beträgt. Ein DPD-Intervall von 30 Sekunden ist für leitungsgebundene Übertragung sinnvoll. Für instabile Mobilfunkverbindungen sollte das DPD-Intervall > 30 Sekunden gewählt werden.

Sinnvoller wäre es, denn ISP dazu bringen, dass er stabilere (DSL-)Netzwerkverbindungen anbietet.

Zum Vergleich: Gemäss dem Connect-Mobilfunk-Netztest 2019 nutze ich mit meinen SIM-Karten Mobilfunknetze, welches eine von Connect gemessene Verfügbarkeit von 99.94% (Swisscom => einmaliger Ausfall von 60 Minuten innerhalb 7 Monaten) und gar 100% (Sunrise) aufweist.
https://www.connect.de/vergleich/mobilf ... -8330.html

Die mit DPD (30 Sekunden-Intervall) gemessene Verfügbarkeit der von mir verwalteten, per EuroDOCSIS (Fernsehkabelnetz) realisierten Internetanschlüsse beträgt mindestens 99.98% (in den letzten 35 Tage nur ein einmaliger Ausfall von 7 Minuten zwischen 1 Uhr und 2 Uhr mitten in der Nacht => vermutlich wegen Firmware-Update eines EuroDOCSIS-Kabelmodems).

blackeagle2002de
Beiträge: 135
Registriert: 23 Jan 2005, 14:47
Kontaktdaten:

Re: IKEv2 Loadbalancer Verbindungsabbrüche LCOS 10.20

Beitrag von blackeagle2002de » 19 Feb 2019, 18:47

Hallo GrandDixence,

vielen Dank für Deine Infos. Leider sind wir nicht in der Lage auf die IPSs so wie von Dir geäußert einzuwirken. Wir haben mehrere Standorte in ländlich geprägten Gebieten im Osten Deutschlands wo wir bis heute DSL mit maximal 3 Mbit im Download gestellt bekommen, mit leider sehr unbeständiger Leitung. Ein Anruf bei der Telekom Hotline daran etwas zu ändern ist leider vergebene Liebesmüh, alternative Anbieter gibt es erst gar nicht. Seit neuestem können wir zumindest per Funk noch ein paar Mbit dazubekommen. Insofern können wir Deine Aussage, dass diese Konfiguration keinen Sinn macht für unsere Situation nicht bestätigen. Im Gegenteil wir sind seit ca. 4 Jahren äußerst zufrieden mit dieser Konfiguration (vorhergehend wie beschrieben über PPTP), weil wir damit erstmalig in der Lage waren unseren Mitarbeitern in diesen Standorten eine halbwegs zumutbare Arbeitsumgebung zur Verfügung zu stellen, ohne ständige Verbindungsabbrüche.
Allerdings möchte ich jetzt auch nicht über das für und wieder dieser Konfiguration einsteigen, sondern herausfinden warum es mit dem LCOS Update auf 10.20 zu den Abbrüchen kommt, wohingegen die Version 10.12 ohne Probleme läuft. Ich werde mich damit mal an den Lancom Support wenden. Vielen Dank noch einmal für Deine Hilfe!

Viele Grüße

blackeagle2002de

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag

Zurück zu „Fragen zum Thema VPN“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast