[Gelöst] Ipsec Fritzbox 7590 <-> VPS Kopplung

JJFF · 26 Jan 2019

Hey!
Ich habe mal das Häkchen bei Zwangstrennung durch den Anbieter verschieben in die Zeit zwischen in der FB entfernt. Ich nehme mal an, dass das die Trennung per FB auslöst. Ich bin beim lokalen Hamburger Anbieter Willy.tel und es kann gut sein, dass die tatsächlich immer noch alle 24h trennen. Ich hatte bis vor einiger Zeit einen Telekomanschluss, da war das fast kein Thema mehr (de-facto feste IP, es sein denn ich habe die FB neu starten müssen).

bei "Zwangs-IP-Wechsel" bricht natürlich der Tunnel zusammen und der VPS Server muß sich erst die neue IP-Adresse bei DynDNS-Server holen und dann die VPN-Verbindung neu aufbauen.

nur macht er das dann wohl nicht (immer).
Ich hatte es schon mal mit auto=route in der ipsec.conf auf dem VPS versucht, hatte damit aber keinen Erfolg.

die Fritzbox vpn.cfg ist wohl beim Kopieren untergegangen, ist so standardmäßig in der FB vorhanden, habe ich nichts dran geändert:

Code:

##### BEGIN SECTION vpn_cfg /var/flash/vpn.cfg
/*
 * /var/flash/vpn.cfg
 * Sat Jan 12 09:34:51 2019
 */

meta { encoding = "utf-8"; }

vpncfg {
        vpncfg_version = 1;
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_user;
                name = "vserver";
                boxuser_id = 10;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.178.201;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "SECRET";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "SECRET";
                        passwd = "SECRET";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.201;
                }
                phase2ss = "LT8h/esp-all-all/ah-none/comp-all/no-pfs";
                accesslist =
                             "permit ip 0.0.0.0 0.0.0.0 192.168.178.201 255.255.255.255";
                app_id = 0;
        }
}


// EOF
##### END SECTION vpn_cfg

Shirocco88 · 26 Jan 2019

PeterPawn schrieb:
Das Wiki zu strongSwan widmet den Möglichkeiten der Protokollierung sogar einen eigenen "Unterpunkt": https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration

Hast Du den Loglevel schon mal erhöht ?
auch finde ich ausser dem "spärlichen" Meldungen in "/var/log/messages" in #19 keine Trace-Meldungen, die den Auf- oder Abbau genau beschreiben.

ich denke da an einen Loglevel wie hier:
https://www.ip-phone-forum.de/threa...wan-vpn-server-verbinden.286094/#post-2164895

DannyP schrieb:
ipsec.conf

Code:

config setup charondebug="ike 2, knl 2, cfg 2"

JJFF · 26 Jan 2019

Hallo @Shirocco88

das /var/log/daemon.log beinhaltet in gekürzter Version (ist es das was in dem Post gemeint ist?):

Code:

Jan 20 06:28:31 remote charon: 13[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:28:31 remote charon: 07[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:28:34 remote charon: 06[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32856] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:28:34 remote charon: 06[ENC] generating QUICK_MODE request 2483141343 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote charon: 06[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:28:34 remote charon: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:28:34 remote charon: 14[ENC] parsed QUICK_MODE response 2483141343 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote charon: 14[IKE] CHILD_SA home{120} established with SPIs ccbed5e6_i 6c536efa_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote charon: 14[ENC] generating QUICK_MODE request 2483141343 [ HASH ]
Jan 20 06:28:34 remote charon: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:28:34 remote charon: 04[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote charon: 04[ENC] parsed INFORMATIONAL_V1 request 2365571354 [ HASH D ]
Jan 20 06:28:34 remote charon: 04[IKE] received DELETE for ESP CHILD_SA with SPI 8af25d92
Jan 20 06:28:34 remote charon: 04[IKE] closing CHILD_SA home{118} with SPIs c0847cb0_i (0 bytes) 8af25d92_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote ipsec[1205]: 10[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 09[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 09[ENC] parsed INFORMATIONAL_V1 request 972761596 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 09[IKE] received DELETE for ESP CHILD_SA with SPI 7047a103
Jan 20 06:28:34 remote ipsec[1205]: 09[IKE] closing CHILD_SA home{116} with SPIs c3410b22_i (0 bytes) 7047a103_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote ipsec[1205]: 10[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 10[ENC] parsed INFORMATIONAL_V1 request 4097492275 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 10[IKE] received DELETE for ESP CHILD_SA with SPI c3410b22
Jan 20 06:28:34 remote ipsec[1205]: 10[IKE] CHILD_SA not found, ignored
Jan 20 06:28:34 remote ipsec[1205]: 09[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 09[ENC] parsed INFORMATIONAL_V1 request 1203122518 [ HASH N(DPD) ]
Jan 20 06:28:34 remote ipsec[1205]: 09[ENC] generating INFORMATIONAL_V1 request 2659265478 [ HASH N(DPD_ACK) ]
Jan 20 06:28:34 remote ipsec[1205]: 09[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 08[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:28:34 remote ipsec[1205]: 08[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:28:34 remote ipsec[1205]: 12[KNL] creating acquire job for policy 46.111.222.14/32[udp/59326] === 192.168.178.2/32[udp/ntp] with reqid {1}
Jan 20 06:28:34 remote ipsec[1205]: 12[ENC] generating QUICK_MODE request 1150467192 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote ipsec[1205]: 12[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 14[ENC] parsed QUICK_MODE response 1150467192 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote ipsec[1205]: 14[IKE] CHILD_SA home{119} established with SPIs c7f9fb60_i e473e2e3_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote ipsec[1205]: 14[ENC] generating QUICK_MODE request 1150467192 [ HASH ]
Jan 20 06:28:34 remote ipsec[1205]: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 12[ENC] parsed INFORMATIONAL_V1 request 1822713017 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 12[IKE] received DELETE for ESP CHILD_SA with SPI d59bebf5
Jan 20 06:28:34 remote charon: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 12[IKE] closing CHILD_SA home{117} with SPIs c63c3ca1_i (0 bytes) d59bebf5_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote ipsec[1205]: 08[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 08[ENC] parsed INFORMATIONAL_V1 request 2960319648 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 08[IKE] received DELETE for ESP CHILD_SA with SPI c63c3ca1
Jan 20 06:28:34 remote ipsec[1205]: 08[IKE] CHILD_SA not found, ignored
Jan 20 06:28:34 remote ipsec[1205]: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 12[ENC] parsed INFORMATIONAL_V1 request 4130866318 [ HASH N(DPD) ]
Jan 20 06:28:34 remote ipsec[1205]: 12[ENC] generating INFORMATIONAL_V1 request 985952767 [ HASH N(DPD_ACK) ]
Jan 20 06:28:34 remote ipsec[1205]: 12[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 07[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 07[ENC] parsed INFORMATIONAL_V1 request 2923706991 [ HASH N(DPD) ]
Jan 20 06:28:34 remote ipsec[1205]: 07[ENC] generating INFORMATIONAL_V1 request 1865149437 [ HASH N(DPD_ACK) ]
Jan 20 06:28:34 remote ipsec[1205]: 07[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 13[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:28:34 remote ipsec[1205]: 07[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:28:34 remote ipsec[1205]: 06[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32856] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:28:34 remote ipsec[1205]: 06[ENC] generating QUICK_MODE request 2483141343 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote ipsec[1205]: 06[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 14[ENC] parsed QUICK_MODE response 2483141343 [ HASH SA No ID ID ]
Jan 20 06:28:34 remote ipsec[1205]: 14[IKE] CHILD_SA home{120} established with SPIs ccbed5e6_i 6c536efa_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote ipsec[1205]: 14[ENC] generating QUICK_MODE request 2483141343 [ HASH ]
Jan 20 06:28:34 remote ipsec[1205]: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 04[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:28:34 remote ipsec[1205]: 04[ENC] parsed INFORMATIONAL_V1 request 2365571354 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 04[IKE] received DELETE for ESP CHILD_SA with SPI 8af25d92
Jan 20 06:28:34 remote charon: 11[ENC] parsed INFORMATIONAL_V1 request 1022207357 [ HASH D ]
Jan 20 06:28:34 remote ipsec[1205]: 04[IKE] closing CHILD_SA home{118} with SPIs c0847cb0_i (0 bytes) 8af25d92_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:28:34 remote charon: 11[IKE] received DELETE for ESP CHILD_SA with SPI c0847cb0
Jan 20 06:28:34 remote charon: 11[IKE] CHILD_SA not found, ignored
Jan 20 06:29:58 remote charon: 15[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:29:58 remote charon: 15[ENC] parsed INFORMATIONAL_V1 request 111963446 [ HASH N(DPD) ]
Jan 20 06:29:58 remote charon: 15[ENC] generating INFORMATIONAL_V1 request 1161922528 [ HASH N(DPD_ACK) ]
Jan 20 06:29:58 remote charon: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:31:19 remote charon: 07[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:31:19 remote charon: 07[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:31:26 remote charon: 15[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32876] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:31:26 remote charon: 15[ENC] generating QUICK_MODE request 3786436800 [ HASH SA No ID ID ]
Jan 20 06:31:26 remote charon: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:31:26 remote charon: 10[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:31:26 remote charon: 10[ENC] parsed QUICK_MODE response 3786436800 [ HASH SA No ID ID ]
Jan 20 06:31:26 remote charon: 10[IKE] CHILD_SA home{121} established with SPIs c609587a_i 37aeacf8_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:31:26 remote charon: 10[ENC] generating QUICK_MODE request 3786436800 [ HASH ]
Jan 20 06:31:26 remote charon: 10[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:31:26 remote charon: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:31:26 remote charon: 11[ENC] parsed INFORMATIONAL_V1 request 3133958895 [ HASH D ]
Jan 20 06:31:26 remote charon: 11[IKE] received DELETE for ESP CHILD_SA with SPI e473e2e3
Jan 20 06:31:26 remote charon: 11[IKE] closing CHILD_SA home{119} with SPIs c7f9fb60_i (0 bytes) e473e2e3_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:31:26 remote charon: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:31:26 remote charon: 14[ENC] parsed INFORMATIONAL_V1 request 1440580 [ HASH D ]
Jan 20 06:31:26 remote charon: 14[IKE] received DELETE for ESP CHILD_SA with SPI c7f9fb60
Jan 20 06:31:26 remote charon: 14[IKE] CHILD_SA not found, ignored
Jan 20 06:31:59 remote charon: 06[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:31:59 remote charon: 06[ENC] parsed INFORMATIONAL_V1 request 249992076 [ HASH N(DPD) ]
Jan 20 06:31:59 remote charon: 06[ENC] generating INFORMATIONAL_V1 request 1564018635 [ HASH N(DPD_ACK) ]
Jan 20 06:31:59 remote charon: 06[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:34:03 remote charon: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:34:03 remote charon: 14[ENC] parsed INFORMATIONAL_V1 request 1966146641 [ HASH N(DPD) ]
Jan 20 06:34:03 remote charon: 14[ENC] generating INFORMATIONAL_V1 request 671904995 [ HASH N(DPD_ACK) ]
Jan 20 06:34:03 remote charon: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:34:11 remote charon: 04[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:34:11 remote charon: 04[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:34:39 remote charon: 15[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32914] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:34:39 remote charon: 15[ENC] generating QUICK_MODE request 1613931406 [ HASH SA No ID ID ]
Jan 20 06:34:39 remote charon: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:34:39 remote charon: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:34:39 remote charon: 12[ENC] parsed QUICK_MODE response 1613931406 [ HASH SA No ID ID ]
Jan 20 06:34:39 remote charon: 12[IKE] CHILD_SA home{122} established with SPIs ce74ef9f_i 3ab693a2_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:34:39 remote charon: 12[ENC] generating QUICK_MODE request 1613931406 [ HASH ]
Jan 20 06:34:39 remote charon: 12[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:34:39 remote charon: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:34:39 remote charon: 12[ENC] parsed INFORMATIONAL_V1 request 1958626928 [ HASH D ]
Jan 20 06:34:39 remote charon: 12[IKE] received DELETE for ESP CHILD_SA with SPI 6c536efa
Jan 20 06:34:39 remote charon: 12[IKE] closing CHILD_SA home{120} with SPIs ccbed5e6_i (0 bytes) 6c536efa_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:34:39 remote charon: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:34:39 remote charon: 11[ENC] parsed INFORMATIONAL_V1 request 1636503066 [ HASH D ]
Jan 20 06:34:39 remote charon: 11[IKE] received DELETE for ESP CHILD_SA with SPI ccbed5e6
Jan 20 06:34:39 remote charon: 11[IKE] CHILD_SA not found, ignored
Jan 20 06:36:03 remote charon: 04[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:36:03 remote charon: 04[ENC] parsed INFORMATIONAL_V1 request 1017204973 [ HASH N(DPD) ]
Jan 20 06:36:03 remote ipsec[1205]: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 11[ENC] parsed INFORMATIONAL_V1 request 1022207357 [ HASH D ]
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] received DELETE for ESP CHILD_SA with SPI c0847cb0
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] CHILD_SA not found, ignored
Jan 20 06:36:03 remote ipsec[1205]: 15[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 15[ENC] parsed INFORMATIONAL_V1 request 111963446 [ HASH N(DPD) ]
Jan 20 06:36:03 remote ipsec[1205]: 15[ENC] generating INFORMATIONAL_V1 request 1161922528 [ HASH N(DPD_ACK) ]
Jan 20 06:36:03 remote ipsec[1205]: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 07[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:36:03 remote ipsec[1205]: 07[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:36:03 remote ipsec[1205]: 15[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32876] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:36:03 remote ipsec[1205]: 15[ENC] generating QUICK_MODE request 3786436800 [ HASH SA No ID ID ]
Jan 20 06:36:03 remote ipsec[1205]: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 10[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 10[ENC] parsed QUICK_MODE response 3786436800 [ HASH SA No ID ID ]
Jan 20 06:36:03 remote ipsec[1205]: 10[IKE] CHILD_SA home{121} established with SPIs c609587a_i 37aeacf8_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:36:03 remote ipsec[1205]: 10[ENC] generating QUICK_MODE request 3786436800 [ HASH ]
Jan 20 06:36:03 remote ipsec[1205]: 10[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 11[ENC] parsed INFORMATIONAL_V1 request 3133958895 [ HASH D ]
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] received DELETE for ESP CHILD_SA with SPI e473e2e3
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] closing CHILD_SA home{119} with SPIs c7f9fb60_i (0 bytes) e473e2e3_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:36:03 remote ipsec[1205]: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 14[ENC] parsed INFORMATIONAL_V1 request 1440580 [ HASH D ]
Jan 20 06:36:03 remote ipsec[1205]: 14[IKE] received DELETE for ESP CHILD_SA with SPI c7f9fb60
Jan 20 06:36:03 remote ipsec[1205]: 14[IKE] CHILD_SA not found, ignored
Jan 20 06:36:03 remote ipsec[1205]: 06[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:36:03 remote charon: 04[ENC] generating INFORMATIONAL_V1 request 130397255 [ HASH N(DPD_ACK) ]
Jan 20 06:36:03 remote ipsec[1205]: 06[ENC] parsed INFORMATIONAL_V1 request 249992076 [ HASH N(DPD) ]
Jan 20 06:36:03 remote ipsec[1205]: 06[ENC] generating INFORMATIONAL_V1 request 1564018635 [ HASH N(DPD_ACK) ]
Jan 20 06:36:03 remote ipsec[1205]: 06[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 14[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 14[ENC] parsed INFORMATIONAL_V1 request 1966146641 [ HASH N(DPD) ]
Jan 20 06:36:03 remote ipsec[1205]: 14[ENC] generating INFORMATIONAL_V1 request 671904995 [ HASH N(DPD_ACK) ]
Jan 20 06:36:03 remote ipsec[1205]: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 04[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:36:03 remote ipsec[1205]: 04[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:36:03 remote ipsec[1205]: 15[KNL] creating acquire job for policy 46.111.222.14/32[tcp/32914] === 192.168.178.2/32[tcp/7389] with reqid {1}
Jan 20 06:36:03 remote ipsec[1205]: 15[ENC] generating QUICK_MODE request 1613931406 [ HASH SA No ID ID ]
Jan 20 06:36:03 remote ipsec[1205]: 15[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 12[ENC] parsed QUICK_MODE response 1613931406 [ HASH SA No ID ID ]
Jan 20 06:36:03 remote ipsec[1205]: 12[IKE] CHILD_SA home{122} established with SPIs ce74ef9f_i 3ab693a2_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:36:03 remote ipsec[1205]: 12[ENC] generating QUICK_MODE request 1613931406 [ HASH ]
Jan 20 06:36:03 remote ipsec[1205]: 12[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 12[ENC] parsed INFORMATIONAL_V1 request 1958626928 [ HASH D ]
Jan 20 06:36:03 remote ipsec[1205]: 12[IKE] received DELETE for ESP CHILD_SA with SPI 6c536efa
Jan 20 06:36:03 remote ipsec[1205]: 12[IKE] closing CHILD_SA home{120} with SPIs ccbed5e6_i (0 bytes) 6c536efa_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:36:03 remote ipsec[1205]: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 11[ENC] parsed INFORMATIONAL_V1 request 1636503066 [ HASH D ]
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] received DELETE for ESP CHILD_SA with SPI ccbed5e6
Jan 20 06:36:03 remote ipsec[1205]: 11[IKE] CHILD_SA not found, ignored
Jan 20 06:36:03 remote ipsec[1205]: 04[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:36:03 remote charon: 04[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:36:03 remote ipsec[1205]: 04[ENC] parsed INFORMATIONAL_V1 request 1017204973 [ HASH N(DPD) ]
Jan 20 06:37:24 remote charon: 11[KNL] creating delete job for CHILD_SA ESP/0x00000000/46.59.130.184
Jan 20 06:37:24 remote charon: 11[JOB] CHILD_SA ESP/0x00000000/46.59.130.184 not found for delete
Jan 20 06:38:03 remote charon: 11[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (92 bytes)
Jan 20 06:38:03 remote charon: 11[ENC] parsed INFORMATIONAL_V1 request 3019565355 [ HASH N(DPD) ]
Jan 20 06:38:03 remote charon: 11[ENC] generating INFORMATIONAL_V1 request 3029683525 [ HASH N(DPD_ACK) ]
Jan 20 06:38:03 remote charon: 11[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (92 bytes)
Jan 20 06:38:54 remote charon: 15[KNL] creating acquire job for policy 46.111.222.14/32[udp/35792] === 192.168.178.2/32[udp/7389] with reqid {1}
Jan 20 06:38:54 remote charon: 14[ENC] generating QUICK_MODE request 1864486700 [ HASH SA No ID ID ]
Jan 20 06:38:54 remote charon: 14[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (204 bytes)
Jan 20 06:38:54 remote charon: 13[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (156 bytes)
Jan 20 06:38:54 remote charon: 13[ENC] parsed QUICK_MODE response 1864486700 [ HASH SA No ID ID ]
Jan 20 06:38:54 remote charon: 13[IKE] CHILD_SA home{123} established with SPIs cb3baace_i 57e53b45_o and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:38:54 remote charon: 13[ENC] generating QUICK_MODE request 1864486700 [ HASH ]
Jan 20 06:38:54 remote charon: 13[NET] sending packet: from 46.111.222.14[500] to 149.233.137.82[500] (60 bytes)
Jan 20 06:38:54 remote charon: 12[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:38:54 remote charon: 12[ENC] parsed INFORMATIONAL_V1 request 1522511473 [ HASH D ]
Jan 20 06:38:54 remote charon: 12[IKE] received DELETE for ESP CHILD_SA with SPI 37aeacf8
Jan 20 06:38:54 remote charon: 12[IKE] closing CHILD_SA home{121} with SPIs c609587a_i (0 bytes) 37aeacf8_o (0 bytes) and TS 192.168.178.201/32 === 192.168.178.0/24
Jan 20 06:38:54 remote charon: 10[NET] received packet: from 149.233.137.82[500] to 46.111.222.14[500] (76 bytes)
Jan 20 06:38:54 remote charon: 10[ENC] parsed INFORMATIONAL_V1 request 1273128570 [ HASH D ]
Jan 20 06:38:54 remote charon: 10[IKE] received DELETE for ESP CHILD_SA with SPI c609587a
Jan 20 06:38:54 remote charon: 10[IKE] CHILD_SA not found, ignored

ich setze dann jetzt in der ipsec.conf die ikelifetime=8h und füge die Zeile charondebug="ike 2, knl 2, cfg 2" ein.

PeterPawn · 26 Jan 2019

Ich bin mir nicht sicher, daß strongSwan es tatsächlich auf die Reihe bekommt, selbst einen Wechsel der Server-IP zu erkennen, wenn es sich um eine dynamische Adresse handelt. Vielleicht gibt es inzwischen tatsächlich irgendwo ein Plugin dafür (z.B. für die vici-Schnittstelle) - aber ich kenne das noch so, daß man den Adresswechsel schon selbst "überwachen" muß und dann beim Wechsel die Connection (notfalls gezielt über "swanctl") neu starten muß, weil nur dabei die DNS-Auflösung erneut erfolgt.

Normalerweise ist das ja kein unterstütztes Szenario (auch nicht bei strongSwan als "road-warrior"), wenn der Server seinerseits auch noch eine dynamische IP-Adresse haben kann. Auch das AVM-VPN trifft für solche Szenarien ("unsupported" nach RFC) ja eigene Vorkehrungen, indem ständig DNS-Abfragen erfolgen, ob sich die IP-Adresse für einen "remotehostname" eventuell geändert hat.

Solange es kein Plugin dafür gibt, braucht man auch nur ein simples Skript, das sich die letzte IP-Adresse merkt und dann ständig (am besten noch in Abhängigkeit von der TTL in der DNS-Antwort, weil die dazwischen ohnehin gecacht wird) den DNS-Namen abfragt. Ändert sich die Adresse, muß die Verbindung gestoppt und neu gestartet werden, dabei sollte auch der IKE-Daemon eine neue DNS-Auflösung durchführen.

EDIT: Wobei hier DPD vielleicht auch schon gute Dienste leistet ... ich weiß aber auch hier wieder nicht, ob DPD von sich aus die Verbindung so weit neu startet, daß auch eine neue DNS-Abfrage erfolgt. Daher sollte man dann mal nach den angebotenen Schnittstellen von strongSwan schauen und nach einem Weg Ausschau halten, über DPD-Fehler benachrichtigt zu werden ... da könnte man dann das Stoppen und den Neustart der Verbindung auch unterbringen. Wieweit neue "auto"-Parameter genau das jetzt erledigen können (also ob es etwas ähnliches wie "auto = new_resolve" gibt), könnte man auch mal in der Dokumentation ergründen.

JJFF · 26 Jan 2019

@PeterPawn
wie wäre es denn wenn die FB und der VPS die Rollen tauschen? Dann hat der Server ja keine wecheselnde IP mehr und in der Funktion "Diese FRITZ!Box mit einem Firmen-VPN verbinden" gibt es Haken Verbindung dauerhaft halten.

Ich gucke mal, ob ich das hinbekomme...

PeterPawn · 26 Jan 2019

Das braucht aber wieder ein "entferntes Netzwerk", was bei einem VPS mit einer oder zwei öffentlichen Adressen (die m.E. nach auch meist noch /32 sind) als "left" gar nicht so einfach zu realisieren ist. Immerhin muß (zumindest meines Wissens) wenigstens einer der beiden Parameter "left" oder "right" bei strongSwan auf ein lokales Interface passen beim Matchen der IP-Adressen ... das kann aber kaum die öffentliche IP-Adresse sein, weil die wieder in der FRITZ!Box nur entweder über den Tunnel oder über den direkten Weg erreichbar sein kann. Ansonsten braucht es eine ziemliche Konfigurationsorgie, bei der alle die Ports für den Tunnel gesperrt werden (mit dem GUI-Editor ist es dann also auch wieder vorbei), die über die öffentliche IP-Adresse des VPS erreichbar sein sollen. Für die Angabe des "entfernten Netzwerks" in der FRITZ!Box-Konfiguration sollte man also tunlichst nicht auf die externe IP des virtuellen Servers zurückgreifen.

Wenn man sich sehr gut mit IPSec (spez. auch IKEv1, weil die Box von AVM nichts anderes kann) auskennt, kriegt man das vermutlich auch hin ... ein "watchdog" für die Änderung des DNS-Namens ist aber allemal einfacher, zumal man - so man es richtig macht - sogar die DynDNS-Aktualisierung der Box selbst abfangen und auswerten kann. Entweder man verwendet dafür zwei DynDNS-Konten (solange die Box ohnehin über die MyFRITZ!-Adresse angesprochen wird, kann man ja noch einen zweiten Account auch "offiziell" konfigurieren) oder man schreibt sich ein Proxy-Skript für den eigenen Server, das von der Box bei Änderungen aufgerufen wird und die Daten an den eigentlichen DynDNS-Service weiterleitet.

Shirocco88 · 27 Jan 2019

PeterPawn schrieb:
Das braucht aber wieder ein "entferntes Netzwerk", was bei einem VPS mit einer oder zwei öffentlichen Adressen (die m.E. nach auch meist noch /32 sind) als "left" gar nicht so einfach zu realisieren ist.

habe gerade mal die SuFu angeworfen;
da gibt es Erfolgsberichte hierzu:
https://www.ip-phone-forum.de/threads/vpn-7390-7270-7170-strongswan.227473/page-3#post-2018835

sowie:

PsychoMantis schrieb:
Ich habe die Verbindung (fast) auf Anhieb hinbekommen.
Zuerst musste ich den neusten sourcecode holen, entpacken und mit "./configure --enable-kernel-libipsec && make && make install" installieren. (Anmerkung: das mit libipsec ist nur nötig, wenn der Vserver vom Kernel kein ipsec beherrscht - das ist zum Beispiel bei meinem OpenVZ-Vserver der Fall. Ein Freund von mir hat einen Vserver auf KVM - bei ihm geht es ohne --enable-kernel-libipsec).
Dann habe ich die Fritzbox und den strongswan mit diesen Konfigs gefüttert (FBF soll der Initiator der Verbindung sein und Vserver der Responder)

ist zwar aus 2016, aber ggf. ist dies auch ein Lösungsansatz;

freue mich über weitere Erfahrungsberichte bzw. Fragen/Diskussionen.

PeterPawn · 27 Jan 2019

Das ist dort aber (wenn ich mich richtig erinnere, anhand der paar Zeilen, die ich zum "Auffrischen" gerade gelesen habe) eine LAN-LAN-Verbindung - prinzipiell sind zwar alle diese Konfigurationen auch IPSec, aber sie sind eben doch mindestens subtil jeweils anders und müssen auch anders auf der strongSwan-Seite konfiguriert werden ... das ist es auch, was ich mit #28 zum Ausdruck bringen wollte. Vor allem darf man eben dann nicht "stillschweigend" irgendetwas anderes konfigurieren, wenn "the audience" dem dann noch folgen können soll.

JJFF · 27 Jan 2019

Wasserstandsmeldung: die Verbindung hat zumindest den Reconnect heute nach überlebt. Ich hatte aber noch keine Zeit in die Logs zu schauen.

Ist die ganze Problematik eigentlich ein Strongswan-Problem? Ich bin darauf ja nicht festgelegt, wenn das bei z.B. Racoon nicht zu Problemen führen würde, könnte ich auch umsteigen.

zwei Fragen:

Das braucht aber wieder ein "entferntes Netzwerk", was bei einem VPS mit einer oder zwei öffentlichen Adressen (die m.E. nach auch meist noch /32 sind) als "left" gar nicht so einfach zu realisieren ist. Immerhin muß (zumindest meines Wissens) wenigstens einer der beiden Parameter "left" oder "right" bei strongSwan auf ein lokales Interface passen beim Matchen der IP-Adressen ... das kann aber kaum die öffentliche IP-Adresse sein, weil die wieder in der FRITZ!Box nur entweder über den Tunnel oder über den direkten Weg erreichbar sein kann. Ansonsten braucht es eine ziemliche Konfigurationsorgie, bei der alle die Ports für den Tunnel gesperrt werden (mit dem GUI-Editor ist es dann also auch wieder vorbei), die über die öffentliche IP-Adresse des VPS erreichbar sein sollen. Für die Angabe des "entfernten Netzwerks" in der FRITZ!Box-Konfiguration sollte man also tunlichst nicht auf die externe IP des virtuellen Servers zurückgreifen.

Auch auf die Gefahr jetzt laienhaft im Nebel zu stochern: Wäre es ein Ansatz sich eine VLAN Netzwerkschnittstellen einzurichten und darüber entferntes Netzwerk herzustelln, welches dann nicht gleich der öffentlichen IP wäre (Ich hatte an anderer Stelle gelesen, ich meine das war im Zusammenhang mit einer Openvpn Verbindung, gelesen)?

Wenn man sich sehr gut mit IPSec (spez. auch IKEv1, weil die Box von AVM nichts anderes kann) auskennt, kriegt man das vermutlich auch hin ... ein "watchdog" für die Änderung des DNS-Namens ist aber allemal einfacher, zumal man - so man es richtig macht - sogar die DynDNS-Aktualisierung der Box selbst abfangen und auswerten kann. Entweder man verwendet dafür zwei DynDNS-Konten (solange die Box ohnehin über die MyFRITZ!-Adresse angesprochen wird, kann man ja noch einen zweiten Account auch "offiziell" konfigurieren) oder man schreibt sich ein Proxy-Skript für den eigenen Server, das von der Box bei Änderungen aufgerufen wird und die Daten an den eigentlichen DynDNS-Service weiterleitet.

@PeterPawn hast du dafür ein Beispiel an dem ich mich entlang hangeln kann (habe folgendes gefunden: https://gist.github.com/winhamwr/7897090)? Würde man das dann über

Code:

left|rightupdown = <path>

what updown script to run to adjust routing and/or firewalling when the status of the connection
changes (default ipsec _updown). Relevant only locally, other end need not agree on it.
Charon uses the updown script to insert firewall rules only, since routing has been implemented directly
into the daemon.

oder doch lieber über einen CronJob (wie in dem Beispiel) anstoßen?

Ich werde heute Abend auch nochmal versuchen, ob das Dead Peer Detection protocol irgendeinen Effekt hat.

@Shirocco88: Danke für den Hinweis auf den Thread. Ich werde ihn mir heute Abend mal in Ruhe durchlesen.

PeterPawn · 27 Jan 2019

Vermutlich kommt man auch mit einem TUN-Interface auf dem VPS hin (so man die notwendigen Module laden kann, was in Docker- und anderen pseudo-virtualisierten Umgebungen - wo die virtuellen Server alle denselben Kernel verwenden müssen - nicht immer gesagt ist) ... ein lokales LAN an den Adapter mit der offiziellen Adresse zu binden, ist jedenfalls keine gute Idee; außer man dichtet das dann wieder per Firewall entsprechend ab, daß keine Pakete mit den lokalen Adressen tatsächlich ihren Weg zum Adapter finden.

Das ist aber alles auch brotlose Kunst ... es gibt wahnsinnig viele denkbare Wege, jeder davon hat seine Vor- und Nachteile. Mit ein paar weiteren Informationen, z.B.:

- ob es da einen Webserver gibt, auf dem man eigene CGI-Skripte ausführen kann - oder wo irgendeine Skript-Sprache per Module unterstützt ist und nicht nur statisches HTML
- wie nun die DynDNS-Konten in der FRITZ!Box benutzt werden
- welche Vorkenntnisse zum Automatisieren mit welcher Sprache überhaupt vorhanden sind
- usw. ... mir fallen da garantiert noch weitere Fragen/Faktoren ein

könnte man zwar einen davon auswählen ... aber dann muß man den eben auch in aller Konsequenz verfolgen. Mitten im Rennen die Pferde zu wechseln, macht nur bei sehr, sehr langen Rennen einen Sinn, wenn die dafür benötigte Zeit durch die zunehmende Erschöpfung der Konkurrenten ausgeglichen würde.

Schon die Frage/Überlegung, ob das auf Dauer nur eine einzige VPN-Verbindung bleiben wird oder ob da noch weitere "peers" dazukommen könnten (und wenn ja, wie dann die Verbindungen laufen), sollte hier eine Rolle spielen ... wenn es am Ende zwei FRITZ!Boxen mit dynamischer Adresse sind, ist eine Lösung am Server eher diejenige, die beide Boxen (und ggf. noch weitere) "bedienen" kann und man würde sicherlich nicht unbedingt etwas auf Seiten der FRITZ!Box basteln, was dann bei jeder weiteren ebenso erfolgen müßte.

Ob die Skripte bei "updown" auch bei DPD-Signalisierung aufgerufen werden, weiß ich nicht ... aber das ist ja leicht zu testen. Wenn das der Fall sein sollte, wäre das vielleicht ein möglicher Ansatz. Aber eben auch nur dann, wenn man aus diesem Skript heraus die Verbindung beenden und neu starten kann (und nicht beim Beenden dann auch alles andere, was zu der Verbindung "gehört", den Bach runtergeht, inkl. des "updown"-Skripts) ... zumindest dann, wenn die erneute DNS-Auflösung (wie früher) nur beim Start der Verbindung erfolgen sollte.

JJFF · 27 Jan 2019

DPD hat nichts gebracht.

bei mir läuft jetzt folgender snippet als minütlicher cronjob ab, wenns das tut bin ich erstmal zufrieden...

Code:

#!/bin/bash

nc -w 10 -z 192.168.178.2 22 || ipsec restart;

exit 0

Danke Euch für die Unterstützung!

Languages

Suche

Languages

Suche

[Gelöst] Ipsec Fritzbox 7590 <-> VPS Kopplung

JJFF

Neuer User

Shirocco88

Aktives Mitglied

JJFF

Neuer User

PeterPawn

IPPF-Urgestein

JJFF

Neuer User

PeterPawn

IPPF-Urgestein

Shirocco88

Aktives Mitglied

PeterPawn

IPPF-Urgestein

JJFF

Neuer User

PeterPawn

IPPF-Urgestein

JJFF

Neuer User

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums