IPSec-over-HTTPS via LTE

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Hallo,

ich habe hier eine Konfiguration, die mir Kopfzerbrechen bereitet.

VPN-Endpunkte sind:

- lokal: 1781VA mit LCOS 9.24.0121 beta
- remote: 1781EW+ mit LCOS 9.24.0121 beta

Beide LANCOM-Geräte verwenden externe ISP-Gateways (über Ethernet), eines davon ist ein experimentelles Gerät (TP-Link MR200: ein LTE-Router).
Weil das LTE-Gateway wohl eine kaputte IPSec-Passthru-Funktion hat, wollte ich auf IPSec-o-HTTPS ausweichen, aber das klemmt.

Im Detail:

1. funktionierender VPN-Link

local: 1781VA mit Fritzbox-Cable als ISP-Gateway (Netcologne mit public IPv4) - IPSec responder
remote: 1782EW+ mit Fritzbox-Cable als ISP-Gateway (Netcologne mit public IPv4) - IPSec initiator

Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 476 bytes
Gateways: 10.1.253.130:500<--78.34.70.233:500
SPIs: 0x9D7EC50F96CB5FCB0000000000000000, Message-ID 0
Peer identified: DEFAULT
Received 3 notifications:
+REDIRECT_SUPPORTED
+STATUS_NAT_DETECTION_SOURCE_IP
+STATUS_NAT_DETECTION_DESTINATION_IP
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are behind a NAT => sending periodic keep alives every 20 seconds
+IKE_SA:
Proposal 1 Protocol IPSEC_IKE
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)

Peer DEFAULT: Constructing an IKE_SA_INIT-REPLY for send
IKE_SA:
Proposal 1 Protocol IPSEC_IKE:
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+KE-DH-Group 14 (2048 bits)
Sending an IKE_SA_INIT-RESPONSE of 477 bytes
Gateways: 10.1.253.130:500-->78.34.70.233:500
SPIs: 0x9D7EC50F96CB5FCBA182372AE554F83A, Message-ID 0

IKE_FRAGMENTATION successfully negotiated
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x9D7EC50F96CB5FCB, responder cookie: 0xA182372AE554F83A
SA ISAKMP for peer DEFAULT encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/12/2016 12:53:35 (in 97200 sec) / 0 kb
life time hard 10/12/2016 15:53:35 (in 108000 sec) / 0 kb
Negotiated: IKE_FRAGMENTATION

VPN-Status] 2016/10/11 09:53:36,004
Peer DEFAULT: Received an IKE_AUTH-REQUEST of 240 bytes (encrypted)
Gateways: 10.1.253.130:4500<--78.34.70.233:4500
SPIs: 0x9D7EC50F96CB5FCBA182372AE554F83A, Message-ID 1
+Received-ID 10.1.33.1:IPV4_ADDR matches the Expected-ID 10.1.33.1:IPV4_ADDR
+Peer identified: AS03R001
+Peer uses AUTH(PSK)
+Authentication successful
Received 1 notification:
+STATUS_INITIAL_CONTACT
TSi: ( 0, 0-65535, 10.1.33.0-10.1.33.31 )
TSr: ( 0, 0-65535, 10.0.0.0-10.0.0.255 )
+CHILD_SA:
Proposal 1 Protocol IPSEC_ESP SPI=0xAB694F28
ENCR : AES_CBC-256
INTEG: HMAC-SHA-256
ESN : NONE

[VPN-Status] 2016/10/11 09:53:36,010
Peer AS03R001: Constructing an IKE_AUTH-REPLY for send
+Local-ID 10.1.5.1:IPV4_ADDR
+I use AUTH(PSK)

[..]

Peer AS03R001: Received an CREATE_CHILD_SA-REQUEST of 480 bytes (encrypted)
Gateways: 10.1.253.130:4500<--78.34.70.233:4500
SPIs: 0x9D7EC50F96CB5FCBA182372AE554F83A, Message-ID 2
TSi: ( 0, 0-65535, 10.1.33.0-10.1.33.31 )
TSr: ( 0, 0-65535, 10.3.0.0-10.3.255.255 )
+CHILD_SA:
Proposal 1 Protocol IPSEC_ESP SPI=0xDE3E4D43
ENCR : AES_CBC-256
INTEG: HMAC-SHA-256
DH : 14
ESN : NONE
+Received KE-DH-Group 14 (2048 bits)

CHILD_SA [responder] done with 2 SAS for peer AS03R001 rule ipsec-1-AS03R001-pr0-l0-r0
10.1.253.130:4500<--78.34.70.233:4500, VLAN-ID 0, HW switch port 0, Routing tag 0, Com-channel 11
rule:' ipsec 10.3.0.0/16 <-> 10.1.33.0/27
SA ESP [0xDE3E4D43] alg AES_CBC keylength 256 +hmac HMAC-SHA-256 outgoing
SA ESP [0x3FF2C071] alg AES_CBC keylength 256 +hmac HMAC-SHA-256 incoming
life time soft 10/11/2016 17:05:36 (in 25920 sec) / 1800000 kb
life time hard 10/11/2016 17:53:36 (in 28800 sec) / 2000000 kb
tunnel between src: 10.1.253.130 dst: 78.34.70.233

[..]
Danach ist der IPSec-Tunnel transparent und Daten fließen regulär.




2. Konfiguration über LTE

local: 1781VA mit Fritzbox-Cable als ISP-Gateway (Netcologne mit public IPv4)
remote: 1782EW+ mit ISP-Gateway TP-Link MR200 LTE-Router (T-Mobile private IPv4)

- TP MR200: IPSec-VPN passthru ist aktiviert


Die Verbindungsanfragen vom Initiator (remote) kommen lokal an
[VPN-Debug] 2016/10/11 09:40:34,101
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 476 bytes
Gateways: 10.1.253.130:500<--80.187.101.75:500
SPIs: 0xBD8A582C65FF57480000000000000000, Message-ID 0
VLAN-ID 0, HW switch port 0, Routing tag 0, Com-channel 11
Payloads: SA, KE, NONCE, NOTIFY(REDIRECT_SUPPORTED), NOTIFY(DETECTION_SOURCE_IP), NOTIFY(DETECTION_DESTINATION_IP), VENDOR(FRAGMENTATION)
Looking for payload VENDOR (43)...Found 1 payload.
+FRAGMENTATION
Looking for payload NOTIFY(DETECTION_SOURCE_IP) (41)...Found 1 payload.
+Computing SHA1(0xBD8A582C65FF57480000000000000000|80.187.101.75:500)
+Computing SHA1(0xBD8A582C65FF5748000000000000000050BB654B01F4)
+Computed: 0xF23061B200AE9805993182200E98EB3F22FAB98E
+Received: 0x02671AC757878D0C5C2C3FBBBEC624DD035491A9
+Not equal => NAT-T enabled => switching on port 4500
Looking for payload NOTIFY(DETECTION_DESTINATION_IP) (41)...Found 1 payload.
+Computing SHA1(0xBD8A582C65FF57480000000000000000|10.1.253.130:500)
+Computing SHA1(0xBD8A582C65FF574800000000000000000A01FD8201F4)
+Computed: 0x93E2C4A91F6614AB836013AC49B7CDAE19EED492
+Received: 0x61724603B78341C7F4CBD9543621E96E42E5E019
+Not equal. NAT-T already enabled
IKE_SA:
+ENCR : comparing received AES_CBC (12) with config AES_CBC
+Valid ENCR AES_CBC with key length 256 found
+INTEG: comparing received SHA-256 (12) with config SHA-256
+Valid INTEG SHA-256 found
+Valid DH-Group 14 found
+Valid PRF found 5 (SHA-256)
Looking for payload IKE_SA (33)...Found 1 payload.
Antworten werden vom Responder verschickt:
[VPN-Status] 2016/10/11 09:40:34,101
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 476 bytes
Gateways: 10.1.253.130:500<--80.187.101.75:500
SPIs: 0xBD8A582C65FF57480000000000000000, Message-ID 0
Peer identified: DEFAULT
Received 3 notifications:
+REDIRECT_SUPPORTED
+STATUS_NAT_DETECTION_SOURCE_IP
+STATUS_NAT_DETECTION_DESTINATION_IP
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are behind a NAT => sending periodic keep alives every 20 seconds
+IKE_SA:
Proposal 1 Protocol IPSEC_IKE
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)
Die Antworten kommen remote nicht an.


Vermutung IPSec-Passthrough fehlerhaft (gestützt durch andere Aussagen im TP-Link Forum)




3. Geplante Abhilfe: Nutzung von IPSec-over-HTTPS

- an beiden ISP-Gateway-Routern ist der jeweiligen LANCOM VPN-Endpunkt als exposed host, bzw. als Ziel für Portweiterleitung 443/tcp eingetragen.
- Auf beiden LCOS-Geräten wurde der IKEv2-Verbindungsparameter TN-o-HTTPS definiert: IPSec-over-HTTPS ja, IPCOMP nein, Tunnel und für die Verbindung aktiviert
[VPN-Status] 2016/10/11 19:46:07,155
Peer <UNKNOWN>: Received an IKE_SA_INIT-REQUEST of 476 bytes
Gateways: 10.1.253.130:443<--80.187.111.55:10801
SPIs: 0x179D0746DD5D8E810000000000000000, Message-ID 0
Peer identified: DEFAULT
Received 3 notifications:
+REDIRECT_SUPPORTED
+STATUS_NAT_DETECTION_SOURCE_IP
+STATUS_NAT_DETECTION_DESTINATION_IP
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are behind a NAT => sending periodic keep alives every 20 seconds
+IKE_SA:
Proposal 1 Protocol IPSEC_IKE
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+Received KE-DH-Group 14 (2048 bits)

[VPN-Status] 2016/10/11 19:46:07,207
Peer DEFAULT: Constructing an IKE_SA_INIT-REPLY for send
IKE_SA:
Proposal 1 Protocol IPSEC_IKE:
ENCR : AES_CBC-256
PRF : PRF-HMAC-SHA-256
INTEG: SHA-256
DH : 14
+KE-DH-Group 14 (2048 bits)
Sending an IKE_SA_INIT-RESPONSE of 477 bytes
Gateways: 10.1.253.130:443-->80.187.111.55:10801
SPIs: 0x179D0746DD5D8E81C16A3409B30BC5D7, Message-ID 0

IKE_FRAGMENTATION successfully negotiated
IKE_SA_INIT [responder] for peer DEFAULT initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0x179D0746DD5D8E81, responder cookie: 0xC16A3409B30BC5D7
SA ISAKMP for peer DEFAULT encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/12/2016 22:46:07 (in 97200 sec) / 0 kb
life time hard 10/13/2016 01:46:07 (in 108000 sec) / 0 kb
TCP/SSL encapsulation enabled
Negotiated: IKE_FRAGMENTATION

Peer DEFAULT: Received an IKE_AUTH-REQUEST of 240 bytes (encrypted)
Gateways: 10.1.253.130:443<--80.187.111.55:10801
SPIs: 0x179D0746DD5D8E81C16A3409B30BC5D7, Message-ID 1
+Received-ID 10.1.33.1:IPV4_ADDR matches the Expected-ID 10.1.33.1:IPV4_ADDR
+Peer identified: AS03R001
+Peer uses AUTH(PSK)
+Authentication successful
Received 1 notification:
+STATUS_INITIAL_CONTACT
TSi: ( 0, 0-65535, 10.1.33.0-10.1.33.31 )
TSr: ( 0, 0-65535, 10.0.0.0-10.0.0.255 )
+CHILD_SA:
Proposal 1 Protocol IPSEC_ESP SPI=0x61100EC0
ENCR : AES_CBC-256
INTEG: HMAC-SHA-256
ESN : NONE

Peer AS03R001: Constructing an IKE_AUTH-REPLY for send
+Local-ID 10.1.5.1:IPV4_ADDR
+I use AUTH(PSK)

IKE_SA_INIT [responder] for peer AS03R001 initiator id 10.1.33.1, responder id 10.1.5.1
initiator cookie: 0x179D0746DD5D8E81, responder cookie: 0xC16A3409B30BC5D7
NAT-T enabled. We are behind a nat, the remote side is not behind a nat
SA ISAKMP for peer AS03R001 encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/12/2016 22:46:07 (in 97200 sec) / 0 kb
life time hard 10/13/2016 01:46:07 (in 108000 sec) / 0 kb
TCP/SSL encapsulation enabled
Negotiated: IKE_FRAGMENTATION

+TSi 0: ( 0, 0-65535, 10.1.33.0-10.1.33.31 )
+TSr 0: ( 0, 0-65535, 10.0.0.0-10.0.0.255 )
CHILD_SA:
Proposal 1 Protocol IPSEC_ESP:
New Responder's-SPI: 0xECB0368D
ENCR : AES_CBC-256
ESN : NONE
INTEG: SHA-256
Sending an IKE_AUTH-RESPONSE of 224 bytes (encrypted)
Gateways: 10.1.253.130:443-->80.187.111.55:10801
SPIs: 0x179D0746DD5D8E81C16A3409B30BC5D7, Message-ID 1


CHILD_SA [responder] done with 2 SAS for peer AS03R001 rule ipsec-1-AS03R001-pr0-l0-r0
10.1.253.130:443<--80.187.111.55:10801, VLAN-ID 0, HW switch port 0, Routing tag 0, Com-channel 11
rule:' ipsec 10.0.0.0/24 <-> 10.1.33.0/27
SA ESP [0x61100EC0] alg AES_CBC keylength 256 +hmac HMAC-SHA-256 outgoing
SA ESP [0xECB0368D] alg AES_CBC keylength 256 +hmac HMAC-SHA-256 incoming
life time soft 10/12/2016 02:58:07 (in 25920 sec) / 1800000 kb
life time hard 10/12/2016 03:46:07 (in 28800 sec) / 2000000 kb
tunnel between src: 10.1.253.130 dst: 80.187.111.55

[.. weitere CHILD-SAs]

Es sieht ganz gut aus, aber der Tunnel wird nicht transparent für Daten.
[VPN-Status] 2016/10/11 19:54:44,591
IKE info: Delete Notification for Phase-2 SA spi [0x3ada01bb] could not be sent: no phase-1 sa exists to peer 80.187.111.55
Der Responder (local) meldet "ICMP Verbindungsfehler 0x0113"
Der Initiator (remote) meldet "Zeitüberschreitung .. (Aktiver Verbindungsaufbau) 0x1106"

Auch bei Umschaltung auf die Ausgangskonfiguration, die unter IPSec funktioniert (local: 1781VA mit Fritzbox-Cable als ISP-Gateway (Netcologne mit public IPv4) - IPSec responder; remote: 1782EW+ mit Fritzbox-Cable als ISP-Gateway (Netcologne mit public IPv4) - IPSec initiator), kommt keine IPSec-over-HTTPS-Verbindung zustande.

ICMP-Verbindungsfehler 0x0113 auf beiden Seiten.



Was läuft hier falsch? Habe ich bei der Umschaltung auf IPSec-over-HTTPS etwas falsch gemacht?

Gruß,
Rougu
Zuletzt geändert von Rougu am 11 Okt 2016, 21:54, insgesamt 1-mal geändert.
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: IPSec-over-HTTPS via LTE

Beitrag von GrandDixence »

Im Fall des:

remote: 1782EW+ mit ISP-Gateway TP-Link MR200 LTE-Router (T-Mobile private IPv4)

werden die Anforderungen gemäss:

https://www.lancom-systems.de/docs/LCOS ... 75697.html

nicht erfüllt. Wie das fremde Forum bereits mitteilte, ist die "VPN Passthrough"-Funktion des LTE-Router TP-Link MR200 wahrscheinlich fehlerhaft.

Mehr Details zum Thema "fehlerhaftes VPN Passthrough" siehe bitte RFC 3947 Kapitel 4 und RFC 3715 (insbesondere Kapitel 2.3):

https://tools.ietf.org/html/rfc3947#section-4

und

https://tools.ietf.org/html/rfc3715#section-2.3
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Danke GrandDixence für die Links zur Doku.

Mein Post zielt nicht darauf festzustellen, dass IPSec-Passthru von Drittanbietern defekt sein kann. Das ist hier lediglich eine Feststellung.

Mein Ziel ist vielmehr, IPSec-over-HTTPS in der LANCOM/NCP-Implementierung für die fragliche Router-Router-Verbindung zum Laufen zu kriegen.

Mit der Portweiterleitung von HTTPS zu den jeweiligen LANCOM VPN-Endpunkten sollte der Tunnel für Daten durchlässig werden, wenn der Verbindungsaufbau über HTTPS konfiguriert ist. Nur funktioniert das nicht so, wie ich es versuche. Aber warum? Was neben der Aktivierung in den Verbindungsparametern von IKEv2 muss noch eingestellt werden?

Gruß,

rougu
Christoph_vW
Beiträge: 282
Registriert: 02 Mai 2011, 09:47
Wohnort: Berlin
Kontaktdaten:

Re: IPSec-over-HTTPS via LTE

Beitrag von Christoph_vW »

Und den LANCOM in die DMZ vom TP-LINK zu stellen, bzw. auf dem TP-LINK Port forwardings einzustellen?

Also forwardings für:
UDP 500, 4500
ESP
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Die zuletzt genannten Optionen im TP-Link habe ich alle bereits verwendet.
Bitte keinen Gehirnschmalz darauf verwenden, IPSec (native, also IKE oder IKE NAT-T) mit dem kaputten TP-Link zum Laufen zu kriegen.

Es geht mir um LANCOM - LANCOM mit IPSec-over-HTTPS mit IKEv2.

Gruß,
rougu
15 Jahre LANCOM im Detail.
Hardware lebt, und sie ist böse.
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: IPSec-over-HTTPS via LTE

Beitrag von backslash »

Hi Rougu,

bist du denn sicher, daß beim ICMP-Polling die korrekte Absender-Adresse eingesetzt wird? Mach mal einen VPN-Packet-Trace von der Verbindung, um sicher zu gehen, daß die POLL-Pakete überhaupt über die Strecke gehen. Ggf. mußt du in der Polling-Tabelle die Absender-Adresse korrekt vorgeben.

Gruß
Backslash
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Hi Backslash,

ja, die Polling-Adressen sehen gut aus. Unten der lange Trace. Der Verbindungsaufbau und die Child-SAs klappen noch über HTTPS. Die ICMP-Polling-Pakete werden mehrfach verpackt und über 443/tcp verschickt. Antwort kommt keine.

Wenn ich eine Winzigkeit im SOHO-Router ändere,

Code: Alles auswählen

root@SOHO
cd /setup/vpn/ikev2/peers
set ZENTRALE * * * * * * DEFAULT

(schalte Verbindungsparameter von IPsec-HTTPS "on" nach "off")
steht die Verbindung sofort und stabil über NAT-T!

Daher die Frage, was habe ich bei IPSec-over-HTTPS vergessen? Oder schlummert hier ein Problem ausserhalb meiner Reichweite?

Der Trace ist ein wenig anonymisiert und gekürzt. Nicht relevante weitere Child-SAs habe ich weggelassen, damit das Posting nicht gegen unendlich strebt. Man sieht aber gut, wie das Polling-Paket den Aufbau der VPN-Verbindung auslöst und wie die passende Child-SA erzeugt wird.

Gruß,
rougu

Code: Alles auswählen

#
| LANCOM 1781EW+
| Ver. 9.24.0121 / 06.10.2016
| SN.  XXXXXXXXXXXXXXXXXX
| Copyright (c) LANCOM Systems

SOHO, Connection No.: 002 (LAN)

root@SOHO:/
> trace # vpn-pack vpn-stat
VPN-Packet           ON 
VPN-Status           ON 

root@SOHO:/
> 
[VPN-Status] 2016/10/12 17:21:07,464
VPN: WAN state changed to WanCall for ZENTRALE (78.0.222.111), called by: 00c1f1c4

[VPN-Status] 2016/10/12 17:21:07,464
VPN: connecting to ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:07,464
vpn-maps[13], remote: ZENTRALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2016/10/12 17:21:07,464
vpn-maps[13], remote: ZENTRALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2016/10/12 17:21:07,479
vpn-maps[13], remote: ZENTRALE, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2016/10/12 17:21:07,479
VPN: installing ruleset for ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:07,480
Config parser: Start

[VPN-Status] 2016/10/12 17:21:07,480
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2016/10/12 17:21:07,480
VPN: ruleset installed for ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:07,480
VPN: start IKE negotiation for ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:07,480
VPN: WAN state changed to WanProtocol for ZENTRALE (78.0.222.111), called by: 00c1f1c4

[VPN-Status] 2016/10/12 17:21:07,486
VPN: rulesets installed

[VPN-Packet] 2016/10/12 17:21:07,487
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33321
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50776 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 65496 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 59 a9 17 00 00 00 00 .Y......
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:07,487
no sa available: give up [2], should be retransmitted: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33321
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50776 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 65496 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 59 a9 17 00 00 00 00 .Y......
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Status] 2016/10/12 17:21:07,538
Peer ZENTRALE: Constructing an IKE_SA_INIT-REQUEST for send
Starting IKEv2 negotiation
IKE_SA:
  Proposal 1  Protocol IPSEC_IKE:
    ENCR : AES_CBC-256 
    INTEG: SHA-256 SHA1 
    PRF  : PRF-HMAC-SHA-256 PRF-HMAC-SHA1 
    DH   : 14 
+KE-DH-Group 14 (2048 bits)
Sending an IKE_SA_INIT-REQUEST of 476 bytes
Gateways: 192.168.178.42:15557-->78.0.222.111:443
SPIs: 0xF62F5BD7DDB1CB720000000000000000, Message-ID 0

[VPN-Status] 2016/10/12 17:21:07,713
Peer ZENTRALE: Received an IKE_SA_INIT-RESPONSE of 477 bytes
Gateways: 192.168.178.42:15557<--78.0.222.111:443
SPIs: 0xF62F5BD7DDB1CB72317B91693D23CD2E, Message-ID 0
Received 2 notifications: 
  +STATUS_NAT_DETECTION_SOURCE_IP
  +STATUS_NAT_DETECTION_DESTINATION_IP
Peer (responder) is behind a NAT
NAT-T enabled => switching on port 4500
We (initiator) are behind a NAT => sending periodic keep alives every 20 seconds
+IKE_SA:
  Proposal 1  Protocol IPSEC_IKE
    ENCR : AES_CBC-256
    PRF  : PRF-HMAC-SHA-256
    INTEG: SHA-256
    DH   : 14
+Received KE-DH-Group 14 (2048 bits)

IKE_FRAGMENTATION successfully negotiated
IKE_SA_INIT [initiator] for peer ZENTRALE initiator id <no ipsec id>, responder id <no ipsec id>
initiator cookie: 0xF62F5BD7DDB1CB72, responder cookie: 0x317B91693D23CD2E
SA ISAKMP for peer ZENTRALE encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/13/2016 17:21:07 (in 86400 sec) / 0 kb
life time hard 10/13/2016 23:21:07 (in 108000 sec) / 0 kb
TCP/SSL encapsulation enabled
Negotiated: IKE_FRAGMENTATION

[VPN-Status] 2016/10/12 17:21:07,716
Peer ZENTRALE: Constructing an IKE_AUTH-REQUEST for send
Starting a CHILD_SA negotiation for IPSEC-4-ZENTRALE-PR0-L0-R0
CHILD_SA:
  Proposal 1  Protocol IPSEC_ESP  incoming SPI 0x331359F3
    ENCR : AES_CBC-256 
    INTEG: SHA-256 SHA1 
+Local-ID  10.1.33.1:IPV4_ADDR
+I use AUTH(PSK)
+TSi 0: (  0,     0-65535,       10.1.33.0-10.1.33.31     )
+TSr 0: (  0,     0-65535,        10.0.0.0-10.0.0.255     )
Sending an IKE_AUTH-REQUEST of 240 bytes (encrypted)
Gateways: 192.168.178.42:15557-->78.0.222.111:443
SPIs: 0xF62F5BD7DDB1CB72317B91693D23CD2E, Message-ID 1

[VPN-Status] 2016/10/12 17:21:07,747
Peer ZENTRALE: Received an IKE_AUTH-RESPONSE of 224 bytes (encrypted)
Gateways: 192.168.178.42:15557<--78.0.222.111:443
SPIs: 0xF62F5BD7DDB1CB72317B91693D23CD2E, Message-ID 1
+Received-ID  10.1.5.1:IPV4_ADDR matches the Expected-ID 10.1.5.1:IPV4_ADDR
+Peer identified: ZENTRALE
+Peer uses AUTH(PSK)
+Authentication successful

IKE_SA_INIT [initiator] for peer ZENTRALE initiator id  10.1.33.1, responder id  10.1.5.1
initiator cookie: 0xF62F5BD7DDB1CB72, responder cookie: 0x317B91693D23CD2E
NAT-T enabled. We are  behind a nat, the remote side is not behind a nat
SA ISAKMP for peer ZENTRALE encryption aes-cbc authentication SHA-256 prf SHA-256
life time soft 10/13/2016 17:21:07 (in 86400 sec) / 0 kb
life time hard 10/13/2016 23:21:07 (in 108000 sec) / 0 kb
TCP/SSL encapsulation enabled
Negotiated: IKE_FRAGMENTATION

TSi: (  0,     0-65535,       10.1.33.0-10.1.33.31     )
TSr: (  0,     0-65535,        10.0.0.0-10.0.0.255     )
Received 1 notification: 
  +STATUS_INITIAL_CONTACT
+CHILD_SA:
  Proposal 1  Protocol IPSEC_ESP  SPI=0x7E70E0DF
    ENCR : AES_CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE


CHILD_SA [initiator] done with 2 SAS for peer ZENTRALE rule IPSEC-4-ZENTRALE-PR0-L0-R0
192.168.178.42:15557<--78.0.222.111:443, VLAN-ID 0, HW switch port 0, Routing tag 0, Com-channel 1
rule:' ipsec 10.1.33.0/27 <-> 10.0.0.0/24
SA ESP [0x7E70E0DF]  alg AES_CBC keylength 256 +hmac HMAC-SHA-256 outgoing
SA ESP [0x331359F3]  alg AES_CBC keylength 256 +hmac HMAC-SHA-256 incoming
life time soft 10/12/2016 23:45:07 (in 23040 sec) / 1600000 kb
life time hard 10/13/2016 01:21:07 (in 28800 sec) / 2000000 kb
tunnel between src: 192.168.178.42 dst: 78.0.222.111


[VPN-Packet] 2016/10/12 17:21:08,486
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33321
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50776 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 65496 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 59 a9 17 00 00 00 00 .Y......
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:08,486
encap: 192.168.178.42->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 33385
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 60179 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 82 29 00 00 E(.T.)..
                      3c 01 c6 58 0a 01 21 01 <..X..!.
                      0a 00 00 fe 08 00 ff d8 ........
                      28 92 00 00 00 00 28 92 (.....(.
                      00 00 00 00 80 59 a9 17 .....Y..
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/12 17:21:08,509
encrypted: 192.168.178.42->78.0.222.111  164  UDP port 15557->443
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 33385
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 60106 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 15557
Dest Port           : 443
Length              : 144
Checksum            : 0 (not available)
Body                : 7e 70 e0 df 00 00 00 01 ~p......
                      6c ba aa b0 a0 72 db 3b l....r.;
                      b8 ae da df 11 67 2a 90 .....g*.
                      16 95 4e 75 eb 1c 90 a8 ..Nu....
                      b4 f2 5b d2 5d 0f 28 2a ..[.].(*
                      f5 6b 0b e6 86 6d cd 18 .k...m..
                      08 18 18 f0 21 5f 1f 91 ....!_..
                      30 13 cb 59 17 2d 4d 1a 0..Y.-M.
                      b3 92 4a 37 6f 31 9a 9d ..J7o1..
                      03 65 90 b4 90 45 fa a4 .e...E..
                      20 1a 85 b1 5e 0e 28 50  ...^.(P
                      18 42 02 3b f2 d0 64 90 .B.;..d.
                      01 6c 7a 04 4b 84 fd 97 .lz.K...
                      23 b9 e2 2f a5 f7 d1 f3 #../....
                      43 fa 42 b0 5d 0b 4d fb C.B.].M.
                      87 5f 58 a4 e7 4a ee e0 ._X..J..
                      47 cd 6b ea 6c f0 54 73 G.k.l.Ts



[VPN-Packet] 2016/10/12 17:21:09,486
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33321
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50776 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 65496 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 59 a9 17 00 00 00 00 .Y......
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:09,486
encap: 192.168.178.42->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 33414
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 60150 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 82 29 00 00 E(.T.)..
                      3c 01 c6 58 0a 01 21 01 <..X..!.
                      0a 00 00 fe 08 00 ff d8 ........
                      28 92 00 00 00 00 28 92 (.....(.
                      00 00 00 00 80 59 a9 17 .....Y..
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/12 17:21:09,487
encrypted: 192.168.178.42->78.0.222.111  164  UDP port 15557->443
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 33414
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 60077 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 15557
Dest Port           : 443
Length              : 144
Checksum            : 0 (not available)
Body                : 7e 70 e0 df 00 00 00 02 ~p......
                      bc 3f eb 67 cc fb c0 5f .?.g..._
                      48 aa 89 d7 1a a9 ca 64 H......d
                      86 74 fe 4e cd cf f0 d4 .t.N....
                      24 51 66 4f a4 1e 59 3d $QfO..Y=
                      2b b6 43 67 b6 cc c4 de +.Cg....
                      ec 8a 6a 80 f0 1c 08 59 ..j....Y
                      bf 0b a9 73 d3 e3 79 d6 ...s..y.
                      42 c0 0f 52 f3 bf 9f 7f B..R....
                      86 ad fc fb 1d ff b2 b1 ........
                      9d 35 30 6a cf 0c 72 20 .50j..r 
                      22 ce 86 0d 54 1c 6a e0 "...T.j.
                      8f d7 ba 40 11 f5 d1 4b ...@...K
                      f4 a3 34 e4 64 36 89 11 ..4.d6..
                      7a 66 4f 6b 62 0d dc 56 zfOkb..V
                      a5 0d 3d 13 39 8d d0 eb ..=.9...
                      ff 8a 86 1a 15 09 b4 96 ........


[VPN-Packet] 2016/10/12 17:21:09,640
received: 78.0.222.111->192.168.178.42  164  ESP SPI[01bb3cc5]
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 164
ID                  : 33423
Fragment            : Offset 0
TTL                 : 60
Protocol            : ESP
Checksum            : 60075 (OK)
Src Address         : 78.0.222.111
Dest Address        : 192.168.178.42
IP Payload          : 01 bb 3c c5 00 90 00 00 ..<.....
                      5c 8a 10 71 00 00 00 01 \..q....
                      37 c2 3a a9 54 11 6d a6 7.:.T.m.
                      89 64 fa a0 d5 e4 a4 38 .d.....8
                      9d cd 07 3c 26 86 64 9d ...<&.d.
                      9e cb d0 ae 52 71 0c fe ....Rq..
                      27 00 5c 47 4b 86 ae 18 '.\GK...
                      f7 5d f2 68 d0 13 cf cf .].h....
                      43 fa e5 1a 9a d4 93 ea C.......
                      41 f0 1f 2b af 38 dd ee A..+.8..
                      5e 61 67 df 80 64 30 84 ^ag..d0.
                      23 d5 11 ef 8c 4f 0c 95 #....O..
                      56 e8 31 cd e3 26 ba 71 V.1..&.q
                      56 f2 d1 c1 61 f9 5a 9b V...a.Z.
                      81 22 9c 4a 77 42 95 aa .".JwB..
                      ce fe bf 0d cb bf 5a 53 ......ZS
                      e6 2d 0b 87 a5 37 e7 39 .-...7.9
                      aa 3f 32 a2 02 8a 5a 99 .?2...Z.


[VPN-Packet] 2016/10/12 17:21:09,644
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33432
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50665 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 54438 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 7a d4 28 00 00 00 00 .z.(....
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:09,644
encap: 192.168.178.42->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 33433
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 60131 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 82 98 00 00 E(.T....
                      3c 01 c5 e9 0a 01 21 01 <.....!.
                      0a 00 00 fe 08 00 d4 a6 ........
                      28 92 00 00 00 00 28 92 (.....(.
                      00 00 00 00 80 7a d4 28 .....z.(
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/12 17:21:09,644
encrypted: 192.168.178.42->78.0.222.111  164  UDP port 15557->443
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 33433
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 60058 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 15557
Dest Port           : 443
Length              : 144
Checksum            : 0 (not available)
Body                : 7e 70 e0 df 00 00 00 03 ~p......
                      36 15 a9 f8 71 c0 25 30 6...q.%0
                      41 2c a8 3d 92 f4 d7 b7 A,.=....
                      bc 0e 02 45 9f ab 1a ef ...E....
                      04 c4 2a 9a be 9c e9 4d ..*....M
                      51 49 62 2b 58 e1 7a 4d QIb+X.zM
                      0c 67 6b a2 2e 6e 94 4a .gk..n.J
                      9e 05 0f 6e 44 1d e5 2c ...nD..,
                      f9 f5 57 ff ce f8 d6 bd ..W.....
                      42 ae 05 64 f8 de ca 81 B..d....
                      b3 11 37 25 96 8b 2f 0d ..7%../.
                      d4 76 bc 41 69 71 2f dc .v.Aiq/.
                      50 7c ad 4f 53 83 d4 54 P|.OS..T
                      3f 97 3f 32 37 a1 42 d9 ?.?27.B.
                      db 25 75 f4 be 54 ff e2 .%u..T..
                      08 67 ad 8f 80 d7 1b 34 .g.....4
                      63 07 ec 82 29 70 28 50 c...)p(P


[VPN-Packet] 2016/10/12 17:21:10,637
received: 78.0.222.111->192.168.178.42  164  ESP SPI[01bb3cc5]
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 164
ID                  : 33447
Fragment            : Offset 0
TTL                 : 60
Protocol            : ESP
Checksum            : 60051 (OK)
Src Address         : 78.0.222.111
Dest Address        : 192.168.178.42
IP Payload          : 01 bb 3c c5 00 90 00 00 ..<.....
                      5c 8a 10 71 00 00 00 02 \..q....
                      d7 1d 2d ac e2 b1 00 2d ..-....-
                      af be 67 46 76 ca d8 a7 ..gFv...
                      94 22 73 e2 8b 5e 22 23 ."s..^"#
                      2c eb ce 3b 56 f1 5e 02 ,..;V.^.
                      63 fb 8b 16 a8 47 2f 8e c....G/.
                      58 5c 22 32 32 2e dd 24 X\"22..$
                      76 f5 e5 c8 23 00 e7 37 v...#..7
                      81 72 aa 0e cc 5f 84 13 .r..._..
                      29 e9 0d d9 59 83 d1 a5 )...Y...
                      0a 4f f9 9e 3f 4c 22 7c .O..?L"|
                      c3 d5 d2 55 fa eb 8f c3 ...U....
                      92 56 6d 7d 76 bb 3e 74 .Vm}v.>t
                      e3 a0 bf 96 f3 24 f5 58 .....$.X
                      7a 3a 2d 0c b6 d1 77 54 z:-...wT
                      18 aa a9 23 d6 85 70 86 ...#..p.
                      0e e4 1d 2c f5 92 b6 3b ...,...;


[VPN-Packet] 2016/10/12 17:21:10,640
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33453
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50644 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 41879 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 8a 05 28 00 00 00 00 ...(....
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:10,640
encap: 192.168.178.42->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 33454
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 60110 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 82 ad 00 00 E(.T....
                      3c 01 c5 d4 0a 01 21 01 <.....!.
                      0a 00 00 fe 08 00 a3 97 ........
                      28 92 00 00 00 00 28 92 (.....(.
                      00 00 00 00 80 8a 05 28 .......(
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/12 17:21:10,640
encrypted: 192.168.178.42->78.0.222.111  164  UDP port 15557->443
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 33454
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 60037 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 15557
Dest Port           : 443
Length              : 144
Checksum            : 0 (not available)
Body                : 7e 70 e0 df 00 00 00 04 ~p......
                      6b 22 0e 3f c2 fc 3d 3e k".?..=>
                      d4 26 02 72 23 d2 68 9d .&.r#.h.
                      ac 6e a3 d8 07 8b ea 92 .n......
                      96 0e d2 fc f9 3d 71 96 .....=q.
                      ab 07 63 9c 0c e4 dc 61 ..c....a
                      a5 38 d5 67 ab fc f2 6e .8.g...n
                      27 41 f5 a0 f7 c1 0e f9 'A......
                      5e 33 85 df 4b 05 6c 58 ^3..K.lX
                      57 21 4c a6 d2 5a 44 66 W!L..ZDf
                      bb cd de bf 3a f7 b4 10 ....:...
                      f4 3f 54 e4 50 65 79 a6 .?T.Pey.
                      07 71 0e 43 44 f4 36 c3 .q.CD.6.
                      3e f5 c4 78 ff 41 eb da >..x.A..
                      ac cc 06 4e 0c 09 fc 89 ...N....
                      52 3d 4d c3 bd 49 b0 ce R=M..I..
                      ed 11 e7 16 b4 ba 42 38 ......B8


[VPN-Packet] 2016/10/12 17:21:11,637
received: 78.0.222.111->192.168.178.42  164  ESP SPI[01bb3cc5]
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 164
ID                  : 33472
Fragment            : Offset 0
TTL                 : 60
Protocol            : ESP
Checksum            : 60026 (OK)
Src Address         : 78.0.222.111
Dest Address        : 192.168.178.42
IP Payload          : 01 bb 3c c5 00 90 00 00 ..<.....
                      5c 8a 10 71 00 00 00 03 \..q....
                      3b 4b 61 55 73 2c 0b db ;KaUs,..
                      87 ff 4c d7 87 a8 c0 20 ..L.... 
                      07 8a 76 96 cb d5 bc ba ..v.....
                      0f aa 7f b3 bc d9 8d 87 ........
                      67 73 67 24 5e 84 9c b7 gsg$^...
                      c4 37 33 e4 e4 04 69 41 .73...iA
                      33 31 7b c7 de 28 b8 46 31{..(.F
                      d5 c4 a0 f1 5c 1d 7b b8 ....\.{.
                      db 8e b1 4a 0f 55 a4 a0 ...J.U..
                      15 21 c4 01 87 a3 cb 62 .!.....b
                      52 73 c2 51 47 5f 10 c3 Rs.QG_..
                      66 bc c4 45 03 20 ae e7 f..E. ..
                      0e 77 35 0c 27 dc 90 55 .w5.'..U
                      5c bf 31 09 1b 46 7d 02 \.1..F}.
                      60 e8 23 76 31 1d 76 0b `.#v1.v.
                      15 c1 80 a1 e4 73 3b dc .....s;.


[VPN-Packet] 2016/10/12 17:21:11,640
for send: 10.1.33.1->10.0.0.254   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 33478
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 50619 (OK)
Src Address         : 10.1.33.1
Dest Address        : 10.0.0.254
-->ICMP Header
Msg                 : echo request
Checksum            : 24896 (OK)
Identifier          : 10386
Sequence            : 0
Body                : 00 00 28 92 00 00 00 00 ..(.....
                      80 99 47 70 00 00 00 00 ..Gp....
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/12 17:21:11,640
encap: 192.168.178.42->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 33479
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 60085 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 82 c6 00 00 E(.T....
                      3c 01 c5 bb 0a 01 21 01 <.....!.
                      0a 00 00 fe 08 00 61 40 ......a@
                      28 92 00 00 00 00 28 92 (.....(.
                      00 00 00 00 80 99 47 70 ......Gp
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/12 17:21:11,640
encrypted: 192.168.178.42->78.0.222.111  164  UDP port 15557->443
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 33479
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 60012 (OK)
Src Address         : 192.168.178.42
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 15557
Dest Port           : 443
Length              : 144
Checksum            : 0 (not available)
Body                : 7e 70 e0 df 00 00 00 05 ~p......
                      86 4f 9e 14 61 e4 06 51 .O..a..Q
                      e0 bc 7b 6d 7a f0 fa c6 ..{mz...
                      28 30 e9 89 99 ae aa 03 (0......
                      ca 77 38 3b 6c c4 df 61 .w8;l..a
                      2e 6c d7 af df dd 95 33 .l.....3
                      cf 74 ca 05 d9 8c aa 9d .t......
                      29 49 0e 54 97 ce f5 7a )I.T...z
                      11 a6 89 fe 72 04 55 fd ....r.U.
                      83 81 ae e3 cd 12 fb 05 ........
                      a1 38 75 cc 68 0a 7f cf .8u.h...
                      6a 3e 36 b0 43 f2 16 60 j>6.C..`
                      00 60 64 1c e8 a3 1c 04 .`d.....
                      36 60 5f 24 66 00 f6 f6 6`_$f...
                      04 27 23 dd ec 73 32 40 .'#..s2@
                      bb 65 e7 d1 62 7e 6b d3 .e..b~k.
                      02 81 cf 4b 84 9e 35 e3 ...K..5.


[.. weitere Polling-Versuche]


[VPN-Status] 2016/10/12 17:21:20,640
VPN: disconnecting ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:20,640
VPN: Error: ICMP-conn.-Error (0x0113) for ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:20,645
IKE info: Disconnect Request for peer ZENTRALE (ikev2)


[VPN-Status] 2016/10/12 17:21:20,645
IKE info: containing Protocol IPSEC_ESP, with spis [994dbe76  ] [d9f212ea  ]


[VPN-Status] 2016/10/12 17:21:20,646
IKE info: containing Protocol IPSEC_ESP, with spis [f69afb41  ] [5c8a1071  ]


[VPN-Status] 2016/10/12 17:21:20,646
IKE info: containing Protocol IPSEC_ESP, with spis [7e70e0df  ] [331359f3  ]


[VPN-Status] 2016/10/12 17:21:20,646
IKE info: containing Protocol IPSEC_ESP, with spis [f823c8f3  ] [d6ee5760  ]


[VPN-Status] 2016/10/12 17:21:20,647
IKE info: containing Protocol IPSEC_ESP, with spis [c572b97e  ] [45c97526  ]


[VPN-Status] 2016/10/12 17:21:20,647
IKE info: containing Protocol IPSEC_ESP, with spis [fb532368  ] [b456a2bb  ]


[VPN-Status] 2016/10/12 17:21:20,649
Peer ZENTRALE: Constructing an INFORMATIONAL-REQUEST  for send
Sending an INFORMATIONAL-REQUEST of 160 bytes (encrypted)
Gateways: 192.168.178.42:15557-->78.0.222.111:443
SPIs: 0xF62F5BD7DDB1CB72317B91693D23CD2E, Message-ID 7

[VPN-Status] 2016/10/12 17:21:20,650
vpn-maps[13], remote: ZENTRALE, idle, dns-name, static-name

[VPN-Status] 2016/10/12 17:21:20,656
selecting next remote gateway using strategy eFirst for ZENTRALE
     => no remote gateway selected

[VPN-Status] 2016/10/12 17:21:20,656
selecting first remote gateway using strategy eFirst for ZENTRALE
     => CurrIdx=0, IpStr=>vpn-gateway.mycompany.invalid<, IpAddr=78.0.222.111, IpTtl=60s

[VPN-Status] 2016/10/12 17:21:20,656
VPN: installing ruleset for ZENTRALE (78.0.222.111)

[VPN-Status] 2016/10/12 17:21:20,656
VPN: WAN state changed to WanDisconnect for ZENTRALE (78.0.222.111), called by: 00c1f1c4

[VPN-Status] 2016/10/12 17:21:20,656
Config parser: Start

[VPN-Status] 2016/10/12 17:21:20,656
Config parser: Finish
  Wall clock time: 0 ms
  CPU time: 0 ms

[VPN-Status] 2016/10/12 17:21:20,656
VPN: WAN state changed to WanIdle for ZENTRALE (78.0.222.111), called by: 00c1f1c4

[VPN-Status] 2016/10/12 17:21:20,656
VPN: ZENTRALE (78.0.222.111)  disconnected

[VPN-Status] 2016/10/12 17:21:20,656
vpn-maps[13], remote: ZENTRALE, idle, dns-name, static-name

[VPN-Status] 2016/10/12 17:21:20,659
VPN: rulesets installed

[VPN-Status] 2016/10/12 17:21:20,659
VPN: local reconnect lock active for ZENTRALE

[VPN-Status] 2016/10/12 17:21:20,694
VPN: local reconnect lock active for ZENTRALE

[VPN-Status] 2016/10/12 17:21:21,469
VPN: WAN state changed to WanCall for ZENTRALE (78.0.222.111), called by: 00c1f1c4

[VPN-Status] 2016/10/12 17:21:21,469
VPN: connecting to ZENTRALE (78.0.222.111)

[usw ...]

VPN-Packet           OFF
VPN-Status           OFF
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: IPSec-over-HTTPS via LTE

Beitrag von GrandDixence »

Ich interpretiere die Aufzeichnungen wie folgt:

Der VPN-Endpunkt sendet die IPSec-Pakete (mit TCP?) über TCP Port 443 (encrypted: 192.168.178.42->78.0.222.111 164 UDP port 15557->443) an den anderen VPN-Endpunkt. Der andere VPN-Endpunkt antwortet aber mit IP-Paketen Nr. 50 (received: 78.0.222.111->192.168.178.42 164 ESP). Die ESP-Pakete werden vom VPN-Endpunkt empfangen und verworfen.

Gemäss LCOS-Referenzhandbuch:

https://www.lancom-systems.de/docs/LCOS ... 71768.html

wird die IPSec over HTTPS-Technologie nur eingesetzt, wenn der VPN-Endpunkt zum anderen VPN-Endpunkt keine Verbindung über UDP Port 500 (IKE) aufbauen kann. Offenbar kann der andere VPN-Endpunkt zum VPN-Endpunkt über UDP Port 500 kommunizieren (78.0.222.111->192.168.178.42). Der VPN-Endpunkt kann aber nicht über UDP Port 500 (IKE) mit dem anderen VPN-Endpunkt kommunizieren (192.168.178.42->78.0.222.111).
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Hi,

Ich sehe auch, dass ein ESP-Paket von der Gegenseite ankommt.

@GrandDixense
Woraus schließt du, dass dieses ESP-Paket über Port 500/udp empfangen wurde?

Wenn ich die Gegenseite trace, stellt sich heraus, der der VPN-Trace die empfangenen Pollingpakete halbausgepackt anzeigt (eben als ESP-Paket). Auf die Reise ging ein mehrfach verkapseltes ICMP, und zwar letztlich über 443/tcp.

Code: Alles auswählen

root@ZENTRALE:/
> trace # vpn-pack vpn-stat
VPN-Packet           ON 
VPN-Status           ON 


[VPN-Packet] 2016/10/13 07:19:31,060
for send: 10.1.5.1->10.0.0.2   84  ICMP ECHOREQUEST
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 84
ID                  : 4045
Fragment            : Offset 0
TTL                 : 60
Protocol            : ICMP
Checksum            : 21937 (OK)
Src Address         : 10.1.5.1
Dest Address        : 10.0.0.2
-->ICMP Header
Msg                 : echo request
Checksum            : 1293 (OK)
Identifier          : 7608
Sequence            : 0
Body                : 00 00 1d b8 00 00 00 00 ........
                      80 cd b9 23 00 00 00 00 ...#....
                      00 01 02 03 04 05 06 07 ........
                      08 09 0a 0b 0c 0d 0e 0f ........
                      10 11 12 13 14 15 16 17 ........
                      18 19 1a 1b 1c 1d 1e 1f ........
                      20 21 22 23 24 25 26 27  !"#$%&'


[VPN-Packet] 2016/10/13 07:19:31,060
encap: 10.1.253.130->78.0.222.111  104  IP-ENCAP  
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 104
ID                  : 4046
Fragment            : Offset 0
TTL                 : 60
Protocol            : IPinIP
Checksum            : 53773 (OK)
Src Address         : 10.1.253.130
Dest Address        : 78.0.222.111
IP Payload          : 45 28 00 54 0f cd 00 00 E(.T....
                      3c 01 55 b1 0a 01 05 01 <.U.....
                      0a 00 00 02 08 00 05 0d ........
                      1d b8 00 00 00 00 1d b8 ........
                      00 00 00 00 80 cd b9 23 .......#
                      00 00 00 00 00 01 02 03 ........
                      04 05 06 07 08 09 0a 0b ........
                      0c 0d 0e 0f 10 11 12 13 ........
                      14 15 16 17 18 19 1a 1b ........
                      1c 1d 1e 1f 20 21 22 23 .... !"#
                      24 25 26 27             $%&'


[VPN-Packet] 2016/10/13 07:19:31,060
encrypted: 10.1.253.130->78.0.222.111  164  UDP port 443->13261
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x28) (Precedence 1 High Troughput) / (DSCP AF11)
Total length        : 164
ID                  : 4046
Fragment            : Offset 0
TTL                 : 60
Protocol            : UDP
Checksum            : 53700 (OK)
Src Address         : 10.1.253.130
Dest Address        : 78.0.222.111
-->UDP Header
Src Port            : 443
Dest Port           : 13261
Length              : 144
Checksum            : 0 (not available)
Body                : ac 77 a7 50 00 00 00 02 .w.P....
                      65 19 47 42 7a e8 87 67 e.GBz..g
                      56 9d 89 6d 18 5b 1e c5 V..m.[..
                      40 22 7d cd 28 51 10 d4 @"}.(Q..
                      91 1a 0b 0d 4a a4 d3 46 ....J..F
                      38 68 b0 1f 06 30 40 04 8h...0@.
                      b9 1a 8f 47 55 23 4b 09 ...GU#K.
                      2e 02 0c e5 9d 67 fd 58 .....g.X
                      75 0c 33 6f 51 b6 70 9e u.3oQ.p.
                      76 89 32 7c 69 17 49 fa v.2|i.I.
                      59 a4 7b 9a d2 f6 71 3e Y.{...q>
                      e0 53 03 23 41 fc 95 8b .S.#A...
                      80 51 68 fe 97 49 00 f5 .Qh..I..
                      67 75 c6 94 d1 69 99 82 gu...i..
                      85 18 6d c1 28 e4 a4 fd ..m.(...
                      54 56 3d 04 92 8e 01 4e TV=....N
                      38 b0 9f 8f d0 89 1f ed 8.......

Empfangenes Pollingpaket von SOHO:

Code: Alles auswählen

[VPN-Packet] 2016/10/13 07:19:31,083
received: 78.0.222.111->10.1.253.130  164  ESP SPI[33cd01bb]
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 164
ID                  : 4057
Fragment            : Offset 0
TTL                 : 60
Protocol            : ESP
Checksum            : 53696 (OK)
Src Address         : 78.0.222.111
Dest Address        : 10.1.253.130
IP Payload          : 33 cd 01 bb 00 90 00 00 3.......
                      59 5c 44 15 00 00 00 04 Y\D.....
                      9e 62 00 f5 b6 b4 e7 c9 .b......
                      15 6f fa e0 56 84 08 a6 .o..V...
                      58 40 1e ea 4f 4e 38 c5 X@..ON8.
                      16 db f1 b7 c6 17 d8 90 ........
                      d0 b4 b8 85 da 1a 3d 70 ......=p
                      68 03 a2 9e fe 2b ad 0a h....+..
                      68 05 cc 65 e9 83 1d 2d h..e...-
                      8d b6 88 61 aa cd 18 c3 ...a....
                      c2 cb e4 5f b3 a1 97 0c ..._....
                      f5 0f 4f 0f 39 51 11 08 ..O.9Q..
                      0d cc 71 d0 55 1d be a0 ..q.U...
                      34 30 f7 cc 86 46 d1 be 40...F..
                      93 41 ce 9e ad af 3a a9 .A....:.
                      0c e2 78 85 02 4d 49 d2 ..x..MI.
                      60 6d 54 ce 11 2c 13 45 `mT..,.E
                      5d 6d 3e 1a 5f 09 48 3a ]m>._.H:
Für mich ist noch nicht klar, weshalb die ICMP-Pollingpakete, die über IPSec-over-ICMP empfangen wurden, nicht vollständig dekodiert und beantwortet werden, wenn dieselbe Polling-Konfiguration ohne zusätzliche Verkapselung in HTTPs regulär funktioniert.




BTW:

Das LCOS-Manual spricht von einem Versuch über Standard-IPSec (500/udp oder 4500/udp) und einem Fallback auf HTTPS-Kapselung bei Fehlschlag.

Wenn die Gegenseite nach einem erfolgreichen Aufbau von SAs über HTTPS-Verkapselung eine ESP-Testballon über Port 500/udp zurückschicken sollte, dann sollte doch der Empfänger des "Testpakets" das als Trigger für einen Versuch über Standard-IPSec verwenden.

Das hier beobachtete Verhalten wäre insoweit nicht analog der Beschreibung.

In der Knowledgebase (https://www2.lancom.de/kb.nsf/fe78f8220 ... enDocument) wird beschrieben, dass der VPN-Client ein automatisches Fallback auf IPSec-over-HTTPS versucht und wie er auf IPSec-over-HTTPS gezwungen werden kann (udp port für IPSec inkompatibel verstellen).

Wie müssen dann im LCOS die Verbindungsparameter eines VPN-Peerings zwischen zwei Routern für IKEv2 eingestellt werden, damit nach einem Fehlschlag von IKE über Ports 500/udp und IKE-NAT-T über 4500/udp automatisch ein Fallback auf Encapsulation über 443/tcp erfolgt?

Gruß,
rougu
GrandDixence
Beiträge: 1150
Registriert: 19 Aug 2014, 22:41

Re: IPSec-over-HTTPS via LTE

Beitrag von GrandDixence »

Rougu hat geschrieben: Woraus schließt du, dass dieses ESP-Paket über Port 500/udp empfangen wurde?
Aus den veröffentlichten VPN-Traces.

Was tatsächlich über das Netzwerkkabel übertragen wurde, ist nur mit Hilfe von Wireshark und der Paket-Capture-Funktion des LANCOM-Routers ersichtlich.

IKEv1/IPSec und IKEv2/IPSec verwenden vereinfacht ausgedrückt einen Datenkanal (IPSec) und einen Steuer- und Kontrollkanal (IKE). Der Steuer- und Kontrollkanal wird bei IKE Version 1 (IKEv1) und IKE Version 2 (IKEv2) mit UDP über UDP Port 500 realisiert.

Ein ESP-Paket ist ein IP-Paket mit der IP-Protokollnummer 50. Solange kein NAT-Gerät zwischen den beiden VPN-Endpunkte eingesetzt wird, wird der Datenkanal ohne den Einsatz von UDP oder TCP realisiert. Im Tunnelmodus (ESP-Modus) werden die verschlüsselten Daten als "reine" IP-Pakete übertragen:

https://www.heise.de/security/artikel/V ... 70796.html

http://www.elektronik-kompendium.de/sit ... 410261.htm

Wird vom VPN-Endpunkt ein NAT-Gerät zwischen den beiden VPN-Endpunkten erkannt, wird der Datenkanal und der Steuer- und Kontrollkanal umgeschaltet und mit UDP über UDP Port 4500 (NAT-T => NAT-Traversal) realisiert. Dabei werden die ESP-Pakete in UDP-Pakete eingekapselt:

http://www.elektronik-kompendium.de/sit ... 906191.htm

Wird die Kommunikation über UDP Ziel-Port 4500 durch eine Firewall/Router/NAT-Gerät blockiert, kann nur noch die LANCOM-Technologie IPSec-over-HTTPS weiterhelfen. Statt die UDP-Pakete an den Ziel-Port 4500 zu versenden, werden wahrscheinlich die UDP-Pakete mit einem TLS-Header/Kopf versehen und in TCP-Pakete eingekapselt. Diese TCP-Pakete werden an TCP Ziel-Port 443 versendet. Der Datenkanal und der Steuer- und Kontrollkanal werden mit TCP über den TCP Zielport 443 (den TCP Port für HTTPS) realisiert => Hier kann ich nur Vermutungen auf Grundlage des LCOS-Referenzhandbuch anstellen, da ich noch nie eine IPSec-over-HTTPS-Übertragung eines Lancom-Router in Wireshark zu sehen bekam!

Egal ob, NAT-Traversal (Übertragung über UDP Port 4500) oder IPSec-over-HTTPS (Übertragung über TCP Port 443) im VPN-Endpunkt konfiguriert und aktiviert wurden, sollte vom LANCOM-Router beim VPN-Tunnelverbindungsaufbau das allererste IKE-Telegramm (IKE_SA_INIT-REQUEST) und die erste Antwort vom anderen VPN-Endpunkt (IKE_SA_INIT-RESPONSE) immer über UDP Port 500 versendet werden! Erhält der VPN-Endpunkt auf das IKE_SA_INIT-REQUEST keine Antwort (IKE_SA_INIT-RESPONSE), sollte vollautomatisch auf IPSec-over-HTTPS umgeschaltet und das IKE_SA_INIT-RESPONSE erneut versendet werden. Diesmal aber verpackt in einem TCP-Paket an TCP Zielport 443.

Gemäss der LANCOM-Knowledgebase kann beim LANCOM Advanced VPN-Client die Nutzung von IPSec-over-HTTPS für den VPN-Tunnelverbindungsaufbau erzwungen werden. Die Nutzung von IPSec-over-HTTPS für den VPN-Tunnelverbindungsaufbau kann beim LANCOM-Router mit LCOS v9.20 nicht erzwungen werden. Kommt das IKE_SA_INIT-RESPONSE vom UDP Quellport 500 zurück, sollte der Datenkanal über ESP (kein NAT-Gerät dazwischen UND kein MobIKE) oder UDP Port 4500 (NAT-Gerät dazwischen ODER MobIKE) realisiert werden:

https://www.heise.de/security/artikel/M ... 70948.html
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Das beobachtete Verhalten ist wie folgt: Es wird der IKEv2-Handshake über 443/tcp verkapselt abgewickelt:

Initiator "SOHO" sendet IKE_SA_INI-REQUEST an den Responder "ZENTRALE"
"ZENTRALE" antwortet mit IKE_SA_INIT-RESPONSE
Initiator "SOHO" sendet IKE_AUTH-REQUEST an den Responder "ZENTRALE"
"ZENTRALE" sendet IKE_AUTH-RESPONSE

Danach werden die CHILD_SAs aufgebaut. Alles erfolgt auch über 443/tcp.

An diesem Punkt meinen beide Seiten, sie hätten einen in 443/tcp verkapselten VPN-Tunnel erfolgreich aufgebaut.

Nun wird das erste Polling-ICMP-EchoReq von "SOHO" durch den HTTPS-gekapselten VPN-Tunnel an "ZENTRALE" geschickt. Von "ZENTRALE" kommt aber kein ICMP-Echo durch den Tunnel zurück.

Und genau dafür gibt es IHMO noch keine plausible Erklärung.

Gruß,
rougu
Rougu
Beiträge: 115
Registriert: 18 Sep 2007, 18:57
Wohnort: EU

Re: IPSec-over-HTTPS via LTE

Beitrag von Rougu »

Ich wollte nun doch einmal wissen, was auf der WAN-Seite passiert, wenn man zwei LCOS 9.24.0125 über IKEv2 mit Verbindungsparamenter "IPSec-HTTPS = on" koppeln will. Also Wireshark an und mitgelesen, was die MAC-Adresse des LANCOM-WAN-Interfaces hört und spricht.

=> "IPSec-HTTPS = on" benutzt keinen Vorlauf und keine Testpakete, ob reguläre Verbindungen über 500/udp oder 4500/udp zustande kommen.

Es sieht so aus, als wäre das der Weg, die Verbindung auf Port 443/tcp zu zwingen, denn über UDP läuft nur noch DHCP, DNS, NTP.

Nur leider läuft es am Ende nicht. Hier ist jetzt also erst mal Sackgasse: also "IPSec-HTTPS -> off" und mit nicht-kaputten WAN-Modems läuft's.

Gruß,
Rougu
Antworten