02.12.2020

14120

Lancom Router Site to Site Problem mit Außenstellen

Guten Tag zusammen,

in der Hauptgeschäftsstelle nutzen wir einen Lancom 1781VA Router und haben i.d.R. zwei gleichzeitige IPSec Site to Site Verbindungen mit den Außenstellen.
In Büro 1 kommt ein Omnia Turris Router hinter einer Fritzbox zum Einsatz. Der Router baut den Tunnel auf und wurde nicht ge-NATed sondern als Exposed Host in der Firtzbox gemapped.
Im Büro 2 steht ein Mikrotik Routerboard, ebenfalls hinter einer Fritzbox. Auch hier baut der Router (Mikrotik ) den Tunnelk auf. Er ist hier allerdings ge-NATed (500, 4500 und ESP) hinter der Fritzbox.

Folgendes Phänomen:

Site to Site Verbindung 1 mit entferntem Büro 1 ist aufgebaut (IKEv1).
Nun baut Büro 2 ebenfalls eine Site to Site Verbindung auf (allerdings über IKEv2).
In diesem Moment wird die erste Site to Site Verbindung scheinbar automatisch beendet.
Wir haben die Standard-VPN Option (5 gleichzeitige Tunnel), wobei gleichzeitig höchstens die beiden vorgenannten aufgebaut sind.

Log:

31 2020-12-02 07:19:03 AUTH Info User S2S-Buero1 logged out
32 2020-12-02 07:19:03 AUTH Hinweis User S2s_Buero2 successfully logged in

Mehr steht nicht drin...
Liegt es vllt. daran, dass beide Standorte unterschiedliche IKE verwenden?

Danke für weiterbringende Überlegungen.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 627416

Url: https://administrator.de/contentid/627416

Ausgedruckt am: 21.11.2024 um 21:11 Uhr

27 Kommentare

Neuester Kommentar

Vorweg: Auch der erste Router läuft über NAT. NAT ist es erst dann nicht, wenn der Router selbst die öffentliche IP am eigenen WAN-Interface hat, was in deinem Fall nicht sein kann. Exposed Host ist nur eine Kombination aus statischem NAT und einer öffenen Firewall.

Hast du eventuell in der Backuptabelle einen Eintrag, der einen oder beide VPN-Gegenstellen beinhaltet?
Gibt es Überschneidungen bei Einträgen in der Routingtabelle?

Nein, an den unterschiedlichen IKE-Versionen liegt es nicht, ich hab hier Router, da sind mehrere Dutzend Gegenstellen gleichzeitig aktiv, im IKEv1- und IKEv2-Mischbetrieb.

Für weitere Logs musst du mal einen vpn-status-Trace anwerfen.

trace + vpn-status wirft mir alles mit OFF aus:

Ausgaben des Befehls

BGP
BGP-Network OFF
BGP-Connection OFF
BGP-Control OFF
BGP-Adj-RIB-Out OFF
BGP-Adj-RIB-In OFF
BGP-Policy OFF

(...)

tr # vpn-status

Moin,

Was sagt denn der Lanmonitor ?

Versuch mal das Tracen mit dem Trace-Modul, welches im Lanconfig eingebaut ist.

In der CLI kannst du mit

"trace # vpn-status" zwischen Off und On wechseln, in dem du Enter drückst. Wenn der Router dir Tracedaten in der CLI ausgeben soll, muss ON aktiv sein.

Bsp:

root@router:/
> trace # vpn-status
VPN-Status                 OFF

root@router/
> trace # vpn-status
VPN-Status                  ON

Wenn du auch auf dem Mikrotik mehrere Tunnel aktiv hast geht das nicht mit den Default Settings des Level Parameters in der Policy.
Hier musst du zwingend den Level auf unique setzen sonst bricht der MT immer den Primätunnel ab wenn eine 2te SA aktiv wird. Ggf. ist das die Ursache ?!

aqui:

Danke, ich habe die Einstellung auf "unique" geändert.
Ich habe zwar keine zwei Tunnel, aber 2 installed SA.

Versucht und beide Tunnel bleiben nun bestehen.

Ich habe mal Logs aus der CLI gezogen.

Szenario:

Buero2 trennt die Verbindung zur Hauptstelle, woraufhin sich Buero zugleich wieder verbindet.
In diesem Moment wird der Tunnel des Bueros1 immer sofort gretennt...

Wir haben den Lancom so eingestellt, dass er als Responder fungieren soll und die Tunnel jeweils durch die Außenstellen aufgebaut werden.

Hier das Log:

login as: root
Keyboard-interactive authentication prompts from server:
| Local password authentication for root
| Password:
End of keyboard-interactive prompts from server


#
| LANCOM 1781VA (over ISDN)
| Ver. 10.40.0414RU3 / 04.11.2020
| SN.  4004166032100812
| Copyright (c) LANCOM Systems

Router-Hauptstelle, Connection No.: 002 (LAN)



[VPN-Status] 2020/12/03 09:48:43,961
VPN: Disconnect info: physical-disconnected (0x4304) for Peer-Buero2 (IP-Buero2)

[VPN-Status] 2020/12/03 09:48:43,961
VPN: disconnecting Peer-Buero2 (IP-Buero2)

[VPN-Status] 2020/12/03 09:48:43,961
VPN: Disconnect info: physical-disconnected (0x4304) for Peer-Buero2 (IP-Buero2)

[VPN-Status] 2020/12/03 09:48:43,970
Disconnect Request for peer Peer-Buero2 (ikev2)
Deleting IKE_SA (ISAKMP-PEER-Peer-Buero2, Peer-Buero2)
Peer Peer-Buero2: Constructing an INFORMATIONAL-REQUEST  for send
CHILD_SA ('Peer-Buero2', 'IPSEC-0-Peer-Buero2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x08572A2E Inbound-SPI 0xC01213DB) removed from SADB  
CHILD_SA ('Peer-Buero2', 'IPSEC-0-Peer-Buero2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0x08572A2E Inbound-SPI 0xC01213DB) freed  
Message scheduled for retransmission (1) in 6.075529 seconds
Sending an INFORMATIONAL-REQUEST of 96 bytes (responder encrypted)
Gateways: IP-Hauptstelle:4500-->IP-Buero2:4500, tag 0 (UDP)
SPIs: 0x17FCD68290A4D0CA2A94D99DD548B72C, Message-ID 109
IKE_SA ('Peer-Buero2', 'ISAKMP-PEER-Peer-Buero2' IPSEC_IKE SPIs 0x17FCD68290A4D0CA2A94D99DD548B72C) removed from SADB  

[VPN-Status] 2020/12/03 09:48:43,971
vpn-maps[29], remote: Peer-Buero2, idle, static-name

[VPN-Status] 2020/12/03 09:48:43,978
VPN: installing ruleset for Peer-Buero2 (0.0.0.0)

[VPN-Status] 2020/12/03 09:48:43,983
Config parser: Start

[VPN-Status] 2020/12/03 09:48:43,983
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2020/12/03 09:48:43,983
VPN: WAN state changed to WanIdle for Peer-Buero2 (0.0.0.0), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:43,984
DISCONNECT-RESPONSE sent for handle 29

Peer-Buero2 (ikev2): Remote gateway has changed from IP-Buero2 to 0.0.0.0 -> tearing down

[VPN-Status] 2020/12/03 09:48:43,986
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:43,989
Peer Peer-Buero2 [responder]: Received an INFORMATIONAL-RESPONSE of 112 bytes (encrypted)
Gateways: IP-Hauptstelle:4500<--IP-Buero2:4500
SPIs: 0x17FCD68290A4D0CA2A94D99DD548B72C, Message-ID 109

[VPN-Status] 2020/12/03 09:48:43,989
IKE_SA ('Peer-Buero2', 'ISAKMP-PEER-Peer-Buero2' IPSEC_IKE SPIs 0x17FCD68290A4D0CA2A94D99DD548B72C) freed  

[VPN-Status] 2020/12/03 09:48:43,989
VPN: Peer-Buero2 (0.0.0.0)  disconnected

[VPN-Status] 2020/12/03 09:48:43,990
vpn-maps[29], remote: Peer-Buero2, idle, static-name

[VPN-Status] 2020/12/03 09:48:44,088
Config parser: Start

[VPN-Status] 2020/12/03 09:48:44,118
Config parser: Finish
  Wall clock time: 29 ms
  CPU time: 9 ms

[VPN-Status] 2020/12/03 09:48:44,130
DISCONNECT-RESPONSE sent for handle 29

[VPN-Status] 2020/12/03 09:48:44,130
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:44,464
Peer DEFAULT: Received an IKE_SA_INIT-REQUEST of 424 bytes
Gateways: IP-Hauptstelle:4500<--IP-Buero2:4500
SPIs: 0x70C291A5A2C5F9E40000000000000000, Message-ID 0
Peer identified: DEFAULT
IKE_SA ('', '' IPSEC_IKE SPIs 0x70C291A5A2C5F9E4FD3BD8D212119FA0) entered to SADB  
Switching to local port 4500 and remote port 4500
Received 2 notifications:
  +NAT_DETECTION_DESTINATION_IP(0x1AD8F1C13F25C6D4E35E4F171C9A833397C9EABF) (STATUS)
  +NAT_DETECTION_SOURCE_IP(0x1AFC8E3111660BF7D3278265FD321D00DEC102E9) (STATUS)
We (responder) 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)

[VPN-Status] 2020/12/03 09:48:44,513
Peer DEFAULT: Constructing an IKE_SA_INIT-RESPONSE for send
+IKE-SA:
  IKE-Proposal-1  (4 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256
    INTEG: HMAC-SHA-256
    DH   : 14
+KE-DH-Group 14 (2048 bits)
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x70C291A5A2C5F9E4, responder cookie: 0xFD3BD8D212119FA0
NAT-T enabled. We are not behind a nat, the remote side is  behind a nat
SA ISAKMP for peer DEFAULT Encryption AES-CBC-256  Integrity AUTH-HMAC-SHA-256  IKE-DH-Group 14  PRF-HMAC-SHA-256
life time soft 12/04/2020 12:48:44 (in 97200 sec) / 0 kb
life time hard 12/04/2020 15:48:44 (in 108000 sec) / 0 kb
DPD: NONE

Sending an IKE_SA_INIT-RESPONSE of 481 bytes (responder)
Gateways: IP-Hauptstelle:4500-->IP-Buero2:4500, tag 0 (UDP)
SPIs: 0x70C291A5A2C5F9E4FD3BD8D212119FA0, Message-ID 0

[VPN-Status] 2020/12/03 09:48:44,589
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 400 bytes (encrypted)
Gateways: IP-Hauptstelle:4500<--IP-Buero2:4500
SPIs: 0x70C291A5A2C5F9E4FD3BD8D212119FA0, Message-ID 1
CHILD_SA ('', '' ) entered to SADB  
Updating remote port to 4500
Received 1 notification:
  +INITIAL_CONTACT (STATUS)
+Received-ID Peer-Buero2@domain:USER_FQDN matches the Expected-ID Peer-Buero2@domain:USER_FQDN
+Peer identified: Peer-Buero2
+Peer uses AUTH(PSK)
+Authentication successful
IKE_SA ('Peer-Buero2', 'ISAKMP-PEER-Peer-Buero2' IPSEC_IKE SPIs 0x70C291A5A2C5F9E4FD3BD8D212119FA0) removed from SADB  
IKE_SA ('Peer-Buero2', 'ISAKMP-PEER-Peer-Buero2' IPSEC_IKE SPIs 0x70C291A5A2C5F9E4FD3BD8D212119FA0) entered to SADB  
TSi: (  0,     0-65535,    192.168.10.0-192.168.10.255 )
TSr: (  0,     0-65535,   192.168.131.0-192.168.131.255)
+CHILD-SA:
  ESP-Proposal-1 Peer-SPI: 0x0A25D988 (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE

[VPN-Status] 2020/12/03 09:48:44,594
Peer Peer-Buero2: Constructing an IKE_AUTH-RESPONSE for send
+Local-ID Peer-Buero2@domain:USER_FQDN
+I use AUTH(PSK)

IKE_SA_INIT [responder] for peer Peer-Buero2 initiator id Peer-Buero2@domain, responder id Peer-Buero2@domain
initiator cookie: 0x70C291A5A2C5F9E4, responder cookie: 0xFD3BD8D212119FA0
NAT-T enabled. We are not behind a nat, the remote side is  behind a nat
SA ISAKMP for peer Peer-Buero2 Encryption AES-CBC-256  Integrity AUTH-HMAC-SHA-256  IKE-DH-Group 14  PRF-HMAC-SHA-256
life time soft 12/04/2020 12:48:44 (in 97200 sec) / 0 kb
life time hard 12/04/2020 15:48:44 (in 108000 sec) / 0 kb
DPD: 30 sec

+TSi 0: (  0,     0-65535,    192.168.10.0-192.168.10.255 )
+TSr 0: (  0,     0-65535,   192.168.131.0-192.168.131.255)
+CHILD-SA:
  ESP-Proposal-1 My-SPI: 0xA07E3750 (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE

CHILD_SA [responder] done with 2 SAS for peer Peer-Buero2 rule IPSEC-0-Peer-Buero2-PR0-L0-R0
IP-Hauptstelle:4500-->IP-Buero2:4500, Routing tag 0, Com-channel 29
rule:' ipsec 192.168.131.0/24 <-> 192.168.10.0/24  
outgoing SA ESP [0x0A25D988]  Encryption AES-CBC-256  Integrity AUTH-HMAC-SHA-256  PFS-DH-Group None  ESN None
incoming SA ESP [0xA07E3750]  Encryption AES-CBC-256  Integrity AUTH-HMAC-SHA-256  PFS-DH-Group None  ESN None
life time soft 12/03/2020 17:00:44 (in 25920 sec) / 1800000 kb
life time hard 12/03/2020 17:48:44 (in 28800 sec) / 2000000 kb
tunnel between src: IP-Hauptstelle dst: IP-Buero2

Sending an IKE_AUTH-RESPONSE of 240 bytes (responder encrypted)
Gateways: IP-Hauptstelle:4500-->IP-Buero2:4500, tag 0 (UDP)
SPIs: 0x70C291A5A2C5F9E4FD3BD8D212119FA0, Message-ID 1

[VPN-Status] 2020/12/03 09:48:44,594
set_ip_transport for Peer-Buero2: [id: 98952, UDP (17) {incoming unicast, fixed source address}, dst: IP-Buero2, tag 0 (U), src: IP-Hauptstelle, hop limit: 64, pmtu: 1500, iface: WITCOM (6), mac address: 70:db:98:61:b4:d6, port 0]

[VPN-Status] 2020/12/03 09:48:44,594
VPN: WAN state changed to WanCalled for Peer-Buero2 (IP-Buero2), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:44,594
vpn-maps[29], remote: Peer-Buero2, nego, static-name, connected-by-name

[VPN-Status] 2020/12/03 09:48:44,594
VPN: wait for IKE negotiation from Peer-Buero2 (IP-Buero2)

[VPN-Status] 2020/12/03 09:48:44,594
VPN: WAN state changed to WanProtocol for Peer-Buero2 (IP-Buero2), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:45,604
VPN: Peer-Buero2 connected

[VPN-Status] 2020/12/03 09:48:45,604
VPN: WAN state changed to WanConnect for Peer-Buero2 (IP-Buero2), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:45,604
vpn-maps[29], remote: Peer-Buero2, connected, static-name, connected-by-name

[VPN-Status] 2020/12/03 09:48:45,618
starting external DNS resolution for Peer-Buero1
IpStr=>dns-Name-Buero1<, IpAddr(old)=IP-Buero1, IpTtl(old)=60s

[VPN-Status] 2020/12/03 09:48:45,619
internal DNS resolution for Peer-Buero2
IpStr=>0.0.0.0<, IpAddr(old)=0.0.0.0, IpTtl(old)=0s
IpStr=>0.0.0.0<, IpAddr(new)=0.0.0.0, IpTtl(new)=0s

[VPN-Status] 2020/12/03 09:48:45,724
Config parser: Start

[VPN-Status] 2020/12/03 09:48:45,747
external DNS resolution for Peer-Buero1
IpStr=>dns-Name-Buero1<, IpAddr(old)=0.0.0.0, IpTtl(old)=60s
IpStr=>dns-Name-Buero1<, IpAddr(new)=IP-Buero1, IpTtl(new)=60s

[VPN-Status] 2020/12/03 09:48:45,754
Config parser: Finish
  Wall clock time: 30 ms
  CPU time: 9 ms

[VPN-Status] 2020/12/03 09:48:45,759
IKE info: Delete Notification sent for Phase-2 SA IPSEC-0-Peer-Buero1-PR0-L0-R0 to peer Peer-Buero1, spi [0x2a3016f6]


[VPN-Status] 2020/12/03 09:48:45,760
IKE info: Delete Notification sent for Phase-1 SA to peer Peer-Buero1, cookies [0xa7310e660648d94d 0xb6503aa3b859ead7]


[VPN-Status] 2020/12/03 09:48:45,768
Tearing down Peer-Buero1 (ikev1) (remote gateway changed from IP-Buero1 to 0.0.0.0)
Phase-2 SA ('Peer-Buero1', 'IPSEC-0-Peer-Buero1-PR0-L0-R0') removed from SADB  
  Containing Protocol IPSEC_ESP Outbound-SPI 0x7CF9D973 Inbound-SPI 0x2A3016F6
Phase-2 SA ('Peer-Buero1', 'IPSEC-0-Peer-Buero1-PR0-L0-R0') freed  
  Containing Protocol IPSEC_ESP Outbound-SPI 0x7CF9D973 Inbound-SPI 0x2A3016F6
Phase-1 SA ('Peer-Buero1', 'ISAKMP-PEER-Peer-Buero1' IPSEC_IKE Cookies 0xA7310E660648D94DB6503AA3B859EAD7) removed from SADB  
  Freeing exchanges...IKE-DISCONNECT-INDICATION sent for handle 23

[VPN-Status] 2020/12/03 09:48:45,769
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:45,789
vpn-maps[23], remote: Peer-Buero1, idle, dns-name, static-name

[VPN-Status] 2020/12/03 09:48:45,795
selecting first remote gateway using strategy eFirst for Peer-Buero1
     => IpStr=>dns-Name-Buero1<, IpAddr=IP-Buero1

[VPN-Status] 2020/12/03 09:48:45,796
VPN: installing ruleset for Peer-Buero1 (IP-Buero1)

[VPN-Status] 2020/12/03 09:48:45,796
VPN: WAN state changed to WanDisconnect for Peer-Buero1 (IP-Buero1), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:45,800
Config parser: Start

[VPN-Status] 2020/12/03 09:48:45,801
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2020/12/03 09:48:45,801
VPN: WAN state changed to WanIdle for Peer-Buero1 (IP-Buero1), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:45,801
vpn-maps[23], remote: Peer-Buero1, idle, dns-name, static-name

[VPN-Status] 2020/12/03 09:48:45,802
Phase-1 SA ('Peer-Buero1', 'ISAKMP-PEER-Peer-Buero1' IPSEC_IKE Cookies 0xA7310E660648D94DB6503AA3B859EAD7) freed  
DISCONNECT-INDICATION sent for handle 23
DISCONNECT-RESPONSE sent for handle 23

Peer-Buero1 (ikev1): Remote gateway has changed from 0.0.0.0 to IP-Buero1 -> tearing down

[VPN-Status] 2020/12/03 09:48:45,804
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:45,906
Config parser: Start

[VPN-Status] 2020/12/03 09:48:45,936
Config parser: Finish
  Wall clock time: 30 ms
  CPU time: 9 ms

[VPN-Status] 2020/12/03 09:48:45,948
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:46,136
VPN: local reconnect lock active for Peer-Buero1

[VPN-Status] 2020/12/03 09:48:46,151
VPN: local reconnect lock active for Peer-Buero1

[VPN-Status] 2020/12/03 09:48:46,437
VPN: connecting to Peer-Buero1 (IP-Buero1 IKEv1)

[VPN-Status] 2020/12/03 09:48:46,437
VPN: WAN state changed to WanCall for Peer-Buero1 (IP-Buero1), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:46,437
vpn-maps[23], remote: Peer-Buero1, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2020/12/03 09:48:46,444
set_ip_transport for Peer-Buero1: [id: 98971, UDP (17) {outgoing}, dst: IP-Buero1, tag 0 (U), src: IP-Hauptstelle, hop limit: 64, pmtu: 1500, (R) iface: WITCOM (6), next hop: IP-nextHOP]

[VPN-Status] 2020/12/03 09:48:46,444
Transport builder result for Peer-Buero1: success
[id: 98971, UDP (17) {outgoing}, dst: IP-Buero1, tag 0 (U), src: IP-Hauptstelle, hop limit: 64, pmtu: 1500, (R) iface: WITCOM (6), next hop: IP-nextHOP]
stack COM channel to parent WITCOM

[VPN-Status] 2020/12/03 09:48:46,445
vpn-maps[23], remote: Peer-Buero1, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2020/12/03 09:48:46,445
VPN: installing ruleset for Peer-Buero1 (IP-Buero1)

[VPN-Status] 2020/12/03 09:48:46,445
Config parser: Start

[VPN-Status] 2020/12/03 09:48:46,445
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2020/12/03 09:48:46,446
VPN: ruleset installed for Peer-Buero1 (IP-Buero1)

[VPN-Status] 2020/12/03 09:48:46,446
VPN: start IKE negotiation for Peer-Buero1 (IP-Buero1)

[VPN-Status] 2020/12/03 09:48:46,446
VPN: WAN state changed to WanProtocol for Peer-Buero1 (IP-Buero1), called by: 01c89d60

[VPN-Status] 2020/12/03 09:48:46,447
IKE info: Phase-1 negotiation started for peer Peer-Buero1 rule isakmp-peer-Peer-Buero1 using MAIN mode


[VPN-Status] 2020/12/03 09:48:46,454
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:48:53,455
Received Connection-Request for Peer-Buero1 (ikev1)
transport: [id: 98972, UDP (17) {outgoing}, dst: IP-Buero1, tag 0 (U), src: IP-Hauptstelle, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, (R) iface: WITCOM (6), next hop: IP-nextHOP], local port: 500, remote port: 500
Establishing connection(s): IPSEC-0-Peer-Buero1-PR0-L0-R0,IPSEC-1-Peer-Buero1-PR0-L0-R0,IPSEC-2-Peer-Buero1-PR0-L0-R0,IPSEC-3-Peer-Buero1-PR0-L0-R0

Phase-1 SA ('', '' IPSEC_IKE Cookies 0xF4C956C3F7FB81520000000000000000) entered to SADB  

[VPN-Status] 2020/12/03 09:49:15,456
Sending DPD-REQUEST (Peer-Buero2)
Peer Peer-Buero2: Constructing an INFORMATIONAL-REQUEST (DPD-REQUEST) for send
Message scheduled for retransmission (1) in 8.175254 seconds
Sending an INFORMATIONAL-REQUEST (DPD-REQUEST) of 80 bytes (responder encrypted)
Gateways: IP-Hauptstelle:4500-->IP-Buero2:4500, tag 0 (UDP)
SPIs: 0x70C291A5A2C5F9E4FD3BD8D212119FA0, Message-ID 0

[VPN-Status] 2020/12/03 09:49:15,466
Peer Peer-Buero2 [responder]: Received an INFORMATIONAL-RESPONSE of 96 bytes (encrypted)
Gateways: IP-Hauptstelle:4500<--IP-Buero2:4500
SPIs: 0x70C291A5A2C5F9E4FD3BD8D212119FA0, Message-ID 0

[VPN-Status] 2020/12/03 09:49:16,454
VPN: connection for Peer-Buero1 (IP-Buero1) timed out: no response

[VPN-Status] 2020/12/03 09:49:16,454     connection is blocked for 24 seconds

[VPN-Status] 2020/12/03 09:49:16,454
VPN: disconnecting Peer-Buero1 (0.0.0.0)

[VPN-Status] 2020/12/03 09:49:16,454     connection is blocked for 30 seconds

[VPN-Status] 2020/12/03 09:49:16,454
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for Peer-Buero1 (0.0.0.0)

[VPN-Status] 2020/12/03 09:49:16,461
Disconnect Request for peer Peer-Buero1 (ikev1)
Phase-1 SA ('', '' IPSEC_IKE Cookies 0xF4C956C3F7FB81520000000000000000) removed from SADB  
Phase-1 SA ('', '' IPSEC_IKE Cookies 0xF4C956C3F7FB81520000000000000000) freed  

[VPN-Status] 2020/12/03 09:49:16,462
vpn-maps[23], remote: Peer-Buero1, idle, dns-name, static-name

[VPN-Status] 2020/12/03 09:49:16,469
selecting first remote gateway using strategy eFirst for Peer-Buero1
     => IpStr=>dns-Name-Buero1<, IpAddr=0.0.0.0

[VPN-Status] 2020/12/03 09:49:16,469
VPN: installing ruleset for Peer-Buero1 (0.0.0.0)

[VPN-Status] 2020/12/03 09:49:16,469
VPN: WAN state changed to WanDisconnect for Peer-Buero1 (0.0.0.0), called by: 01c89d60

[VPN-Status] 2020/12/03 09:49:16,469
Config parser: Start

[VPN-Status] 2020/12/03 09:49:16,469
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2020/12/03 09:49:16,470
VPN: WAN state changed to WanIdle for Peer-Buero1 (0.0.0.0), called by: 01c89d60

[VPN-Status] 2020/12/03 09:49:16,471
DISCONNECT-RESPONSE sent for handle 23

Peer-Buero1 (ikev1): Remote gateway has changed from IP-Buero1 to 0.0.0.0 -> tearing down

[VPN-Status] 2020/12/03 09:49:16,472
VPN: rulesets installed

[VPN-Status] 2020/12/03 09:49:17,909
VPN: connection backoff wait timer blocks Peer-Buero1 (28 seconds remaining)

[VPN-Status] 2020/12/03 09:49:21,910
VPN: connection backoff wait timer blocks Peer-Buero1 (24 seconds remaining)

[VPN-Status] 2020/12/03 09:49:25,910
VPN: connection backoff wait timer blocks Peer-Buero1 (20 seconds remaining)

[VPN-Status] 2020/12/03 09:49:29,910
VPN: connection backoff wait timer blocks Peer-Buero1 (16 seconds remaining)
tr # vpn-status
[VPN-Status] 2020/12/03 09:49:33,911
VPN: connection backoff wait timer blocks Peer-Buero1 (12 seconds remaining)       tr #vpn-status
 Syntax Error: #vpn-status

root@Router-Hauptstelle:/
>
[VPN-Status] 2020/12/03 09:49:37,911
VPN: connection backoff wait timer blocks Peer-Buero1 (8 seconds remaining)
tr #vpn-status
 Syntax Error: #vpn-status

root@Router-Hauptstelle:/
> tr # vpn-status
VPN-Status                 OFF

Ich traue mich mal ein zweites Mal zu melden, dass das Problem erledigt zu sein scheint.

Für Buero1 war das Remote-Gateway mit 0.0.0.0 im Lancom eingetragen.
Das vertrug sich scheinbar nicht; wir haben hierfür jetzt einen dyn. DNS-Namen gesetzt.

Für Buero1 war das Remote-Gateway mit 0.0.0.0 im Lancom eingetragen.

Das ist kein Problem sondern ganz normal, wenn die Gegenseite die Verbindung aufbauen soll.

Du hast aber eine Fehlkonfiguration drin. Laut dem Trace ist die Verbindung zum Büro1 eine Main-Mode-Verbindung, wird aber mit 0.0.0.0 angegeben. Bei Main-Mode-Verbindungen müssen beide Seiten die IP-Adresse der Gegenseite kennen (es muss die IP sein) oder du musst mit Zertifikaten arbeiten. Ansonsten muss es eine Aggressive Mode-Verbindung oder über IKEv2 realisiert werden (IKEv2 hat den Unterschied Main/Aggressive Mode nicht mehr).

Wir haben jetzt die Vermutung, dass der Lancom die Routen auf 0.0.0.0 ändert sobald sich Buero2 verbindet.
Kann das sein?

Buero1 kann ggf. am Wochenende auf IKEv2 umgestellt werden.

Entweder ist das ne kräftige Fehlkonfiguration oder dem ist nicht so.

Ich seh oben auch ein physical disconnect. Also die WAN-Verbindung geht verloren. Liegt in der Routingtabelle evtl. eine Default-Route auf dem einen Tunnel?

Nein, also der physical disconnect kommt daher, dass ich die Verbindung zu Buero2 getrennt habe.
Dies, um einen Reconnect herbei zu führen und zu schauen, ob dabei dann die Verbindung zu Buero1 wieder gekickt wird.

Ich habe zwar keine zwei Tunnel, aber 2 installed SA.

Das war auch damit gemeint. Sorry wenn das verwirrend rüberkam...
Mit 2 oder mehreren Phase 2 SAs ist der "Level" Parameter unique dann immer zwingend auf dem MT.

Zwei SA sind richtig. Du brauchst eine für den Hinweg und eine für den Rückweg. Man hat doppelt so viele SA wie Netzbeziehungen.

Das meinst du aber jetzt auf beide Router in Summe bezogen, oder ?? Die P2 SA definiert man ja nur einmal pro Router.
Oben war es aber so gemeint (wenn man den TO richtig versteht) das der TO 2 Netzwerke tunneln will die sich nicht in eine gemeinsame CIDR Maske bringen lassen. Dann braucht er 2 SAs pro Richtung.
Nach deiner Rechnung sind es dann 4 SAs... Dann stimmt es wieder logisch.

Wir wollen Buero1 nun mal auf IKEv2 umstellen, um das ggf. bestehende Problem des Mainmode ausschließen zu können.

Ich bin gerade moch über die Regelerzeugung gestolpert.
Hier ist "automatisch" eingestellt, sowohl beim IKEv1 Peer (buero1) als auch beim IKEv2 Peer (buero2).

Könnte das der Fehler sein?
Also dass da tatsächlich die Route auf 0.0.0.0 gesetzt wird?

Anbei die Routing-Tabelle.
192.168.2.0 ist das lokale Netz von Buero1
192.168.10.0 ist das lokale Netz von Buero2

Könnte das der Fehler sein?

Nein, könnte es nicht !
Eine Firewall Regel und eine IP Route sind bekanntlich zwei gänzlich verschiedene Dinge und haben soviel miteinander zu tun wie ein Fisch mit einem Fahrrad. "Regelerzeugung" spricht ja nun deutlich für eine Firewall "Regel" die die IPsec Protokollkomponenten UDP 500 (IKE) und UDP 4500 (NAT-T) bzw. ESP passieren lässt und eben nicht für eine IP Route. Obwohl diese auch dynamisch erzeugt wird bei IPsec.
Bei IPsec VPN Tunnel sind keine Routen erforderlich ! Die Forwarding Information wird über die Phase 2 SAs automatisch in die Routing Tabelle übertragen.
Kann man auch immer selber sehen wenn man sich bei aktivem Tunnel einfach mal die Routing Tabelle des Systems ansieht. Dadrüber dann sinnfrei konfigurierte statische IP Routen können also nur Probleme bereiten und sind unsinnig.

Verstehe. Danke für die Aufklärung.
Also können die Routen in der Tabelle gelöscht werden?

bzgl. Firewall - meinst du die srcnat zwischen beiden Netzen?
Im Mikrotik (buero2) ist die mit "accept" konfiguriert.
Ohne konnte kein Ping/ICMP zwischen Außenstelle und Hauptstelle verschickt werden.

Also können die Routen in der Tabelle gelöscht werden?

Wenn es die Routen zu den VPN Netzen via Tunnel Interface sind ja, denn die sind überflüssig. Da mit statischen Routen "rumzubiegen" macht alles nur noch schlimmer.

Im Mikrotik (buero2) ist die mit "accept" konfiguriert.

Das ist richtig. Die legt MT automatisch an weil es natürlich Unsinn ist im Tunnel selber NAT (Masquerading) zu machen. Dort macht man logischerweise niemals NAT ansonsten wäre das Routing durch die dann aktive NAT Firewall immer eine Einbahnstrasse.
Siehe dazu auch hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

Die dritte, vierte und fünfte Route aus dem Bild sind sogenannte Sperrrouten. Die verhindern, dass beim Zugriff auf eine RFC1918-IP, die es im eigenen Netz nicht gibt, keine Kommunikation über die Defaultroute läuft. Steht aber auch in der Beschreibung dahinter, die abgeschnitten wurde.
Die erste und zweite Route müsste zu VPN-Verbindungen gehören und die letzte ist die Defaultroute.

Nach Löschen der statischen Routen, konnten keine Verbindungen mehr aufgebaut werden.
Habe ich wieder rückgängig gemacht.

Ich glaube (mal wieder) nun den Fehler gefunden zu haben: die IPv4 Regeln

WIZ-TO-WIZ-ANY wurde beim Anlegen des VPN-Zugangs für Buero2 durch den Assistenten angelegt.
Hier stand bis gerade eben noch 0.0.0.0/0 bei lokale Netzwerke.
Diesen Eintrag habe ich auf 192.168.131.0/255.255.255.0 geändert.
Diese Einstellung hat der VPN-Zugang für Buero1 auch.

Im Trace stand ja irgendwas von wegen, dass die Route auf 0.0.0.0 gesetzt wird.
Vllt. ist es das... erfahre ich aber erst wenn Buero1 später den Tunnel wieder aufbaut und Buero2 dann neu connected.

"Entferne Netzwerke" hat jetzt aber eine /32 Bit Hostmaske ?! Etwas komisch....
Was meinst du mit "...konnten keine Verbindungen mehr aufgebaut werden." Heisst das es kann kein Tunnel aufgebaut werden ? Der Tunnelaufbau hat mit einer Route nichts zu tun.
Oder meinst du damit lediglich das du remote Endgeräte via VPN dann nicht pingen kannst. Das man zusätzlich zur Phase 2 SA Negotiation noch statische Routen für die VPN Netze eintragen muss gibts bei keinem Hersteller. Es ist ungewöhnlich das Lancom sowas erzwingt...aber nungut. Dann sind die eben anders als der Rest der Welt.

Leider ist ja das Bild der v4 Routing Tabelle bei aktivem Tunnel unvollständig da man das Wichtigste, sprich das Gateway, nicht erkennen kann.

Ich meinte, dass nach Löschen der statischen Routen keine Tunnel mehr aufgebaut wurden, weder von Buero1 noch von Buero2.

Gateways stehen dort nicht, meinst du statt dessen die Spalte "Router"?
Also bei 192.168.2.0 steht dort der Peer Buero1 und bei bei 192.168.10.0 steht dort der Peer Buero2

Wir wären froh, nicht mehr mit dem Lancom hantieren zu müssen.
Was wir mit diesem Ding schon Ärger hatten...

Die Netzwerkregeln muss man nicht beachten, weil die bei "Automatisch" gar nicht beachtet werden. Es ist egal, ob was im Feld eingetragen ist oder nicht. Kannst zur Sicherheit den Eintrag löschen.

Bei der automatischen Regelerzeugung werden die Netzbeziehungen automatisch aus der Routingtabelle (alle Einträge für die jeweilige VPN-Gegenstelle) und den IP-Subnetzen, die das passende ARF-Tag tragen, erzeugt.

Die manuelle Regelerzeugung benötigt man erst, wenn man von einer VPN-Gegenstelle durch die Zentrale zu einer weiteren VPN-Gegenstelle durchgreifen möchte oder ein Netzwerk erreichen muss, das der Router in der Zentrale nicht als Interface hat.

Wir wären froh, nicht mehr mit dem Lancom hantieren zu müssen.

Kann man bei der megakryptischen Konfig Syntax und dem wirren IPsec Verhalten auch sehr gut nachvollziehen...
Aber du hast ja die freie Wahl, die Welt ist voller VPN Router und Firewalls.

Naja, das Ding war mal vergleichsweise teuer (m.W. 700 € im Jahr 2016).
Ich denke halt immer, solange er noch seinen Dienst tut.
Und ich scheue den Aufwand, alle über die Jahre gewachsenen Einstellungen 1:1 zu portieren.
Das kann wenn nur am Wochenende stattfinden, wo dann hoffentlich nicht gearbeitet wird.

Auf der anderen Seite liest man halt immer, dass Lancom zertifizierten Krempel verkauft und der Support 1A sei.
Mikrotik hatte ja mal schwere Sicherheitslücken wegen eines unverschlüsselten Hashes wenn ich mich nicht täusche.

Nen Mikrotik bekommt man hingegen für 100 € und würde uns absolut genügen.
Von neuen Sicherheitslücken habe ich seit damals nichts mehr gelesen.

Dazu kommt, dass ich in den wenigen Wochen, in denen ich jetzt einen Mikrotik mein Eigen nenne, schon mehr verstanden habe als nach 5 Jahren Lancom.

Ja, LANCOM ist anders, aber man kann sehr gut damit klar kommen. Jeder Hersteller hat seine Schwachen und Stärken.

VPN LANCOM zu LANCOM ist dagegen ne supereinfache Sache.

Im Gegensatz zu LANCOM hat Mikrotik keine All-in-One-Lösung. Modem und VoIP ist immer extern und mit Mehraufwand verbunden.

Zur Syntax: Da tun sich LANCOM und Mikrotik nichts, nur weils anders ist, ist es nicht unbedingt kryptisch.

gelöst Frage Netzwerke Router, Routing

Mehr von mossox

Tool oder Browser-Plugin um IPv4 und IPv6 zu erkennenmossox - 5 Kommentare

10G Rj45 NIC für HPE DL380 G10 und DL20 G11mossox - 12 Kommentare

HPE ProLiant ML 30 Gen11 OEM-SSD lauffähig?mossox - 7 Kommentare

WLAN-AP selbst zusammenstellen?mossox - 5 Kommentare

Heiß diskutiert