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

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
J

JJFF

Neuer User
Mitglied seit
9 Jan 2019
Beiträge
13
Punkte für Reaktionen
0
Punkte
1
Hallo Forum,
ich habe hier schon einiges über die Kopplung von VPS und Fritzbox per VPN gelesen, bekomme es aber einfach nicht hin. Bin mir so langsam auch nicht mehr sicher, ob es an meiner Unwissenheit in dem Thema liegt, oder ob sich seit den letzten Posts (viele sind von 2015/2016) einfach einiges verändert hat - sowohl an der Fritzbox als auch an Strongswan. Darum mal wieder dieses Thema.

Ziel:
Fritzbox 7590 mit MyFritz DynDNS soll an einen KVM VPS von netcup gekoppelt werden. Ich möchte, dass alle Geräte hinter Fritzbox per VPN den VPS erreichen und dieser auf alle Geräte hinter der Fritzbox Zugriff hat. Der VPS soll weiter unter seiner Adresse im Web verfügbar sein (für Webanwendungen). Hatte ihn mit VPNC ihn schon mal erfolgreich angebunden allerdings ist das Setup (Road Warrior?), ja nicht das was ich suche. Wenn ich das bei Wikipedia richtig gelesen habe, ist das ein Site-to-Site Setup, richtig?

Ausgangssituationg:
Fritzbox 7590
DynDNS per myfritz: abcdefg.myfritz.net
Interne IP 192.168.178.1
Netzwerk 192.168.178.0/24
Subnet 255.255.255.0​

VPS KVM Virtualisierung bei netcup
öffentliche IP 46.111.222.14
Netzwerk 46.111.222.14/21 (per ip addr show ermittelt)
Subnet 255.255.248.0 (per ifconfig ermittelt)
Gateway 46.38.232.1
Univention Corporate Server / Debian Stretch mit Linux strongSwan U5.5.1/K4.9.0-8-amd64
Ports 500 und 4500 UDP sind in der Firewall offen​

aus den Beiträgen hier und in anderen Foren habe ich folgende fritz.cfg erstellt:

Code: 
vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "VPS";
                boxuser_id = 0;
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remotehostname = 46.111.222.14;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "abcdefg.myfritz.net";
                }
                remoteid {
                        fqdn = "46.111.222.14";
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "PiC2cNRmyXKBTXXkXsXJ57wMVMTL";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 46.111.222.14;
                                mask = 255.255.248.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 46.111.222.14 255.255.248.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
                            "udp 0.0.0.0:4500 0.0.0.0:4500";

folgende ipsec.conf

Code: 
conn home
        authby=secret
        auto=add
        left=46.111.222.14
        leftsubnet=46.111.222.14/21
        right=abcdefg.myfritz.net
        rightid=@Fritzbox
        rightsubnet=192.168.178.0/24
        ike=aes256-sha-modp1024
        esp=aes256-sha1-modp1024

und folgende ipsec.secrets

Code: 
@46.111.222.14 @FB : PSK "PiC2cNRmyXKBTXXkXsXJ57wMVMTL"

ein ipsec up home ergibt:

Code: 
initiating IKE_SA home[540] to 46.59.215.9
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)
retransmit 1 of request with message ID 0
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)
retransmit 2 of request with message ID 0
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)
retransmit 3 of request with message ID 0
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)
retransmit 4 of request with message ID 0
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)
retransmit 5 of request with message ID 0
sending packet: from 46.111.222.14[500] to 46.59.215.9[500] (1044 bytes)

ipsec statusall

Code: 
Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-8-amd64, x86_64):
  uptime: 60 minutes, since Jan 09 21:01:21 2019
  malloc: sbrk 2703360, mmap 0, used 437824, free 2265536
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark stroke updown
Listening IP addresses:
  46.111.222.14
  192.168.54.244
  172.17.42.1
Connections:
        home:  46.111.222.14...abcdefg.myfritz.net  IKEv1/2
        home:   local:  [46.111.222.14] uses pre-shared key authentication
        home:   remote: [FB] uses pre-shared key authentication
        home:   child:  46.38.232.0/21 === 192.168.178.0/24 TUNNEL
Security Associations (0 up, 1 connecting):
        home[540]: CONNECTING, 46.38.237.214[%any]...46.59.215.9[%any]
        home[540]: IKEv2 SPIs: 3a34150f9cc23dd3_i* 0000000000000000_r
        home[540]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE

ein tcpdump -nni ens3 esp or icmp ergibt:
Code: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
22:03:29.607772 IP 46.111.222.14 > 185.255.31.6: ICMP 46.111.222.14 tcp port 7982 unreachable, length 48
22:03:30.259518 IP 110.249.212.13 > 46.111.222.14: ICMP host 110.249.212.46 unreachable - admin prohibited, length 60

in der ip xfrm policy stehen nur nullen.
Code: 
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main

Wo liegt der Fehler?

Danke für eure Hilfe!
 
Zuletzt bearbeitet:
Könntest Du Bitte mal die VPN-Troubleshooting Inputs der Fritzbox posten;
hierzu die erweiterte Supportdatei http://fritz.box/?lp=support erstellen und folgenden Abschnitt posten:
Code: 
##### BEGIN SECTION vpn VPN
SNIP
##### END SECTION vpn
 
Ich hätte da schon Zweifel, ob die Angabe der IP-Adresse als "remotehostname" ohne weiteres möglich ist ... denn bekanntlich versucht AVM dafür ständig irgendwelche DNS-Abfragen, um auch an Anschlüssen mit dynamischen IP-Adressen zu funktionieren und auf Wechsel dieser Adresse reagieren zu können.

Außerdem dürfte das AVM-VPN seine Probleme haben, den unverschlüsselten und den verschlüsselten Traffic für diese eine öffentliche IP-Adresse zu unterscheiden ... wenn alle Pakete an diese Adresse durch den Tunnel gehen würden, kämen ja auch die IPSec-Pakete mit dieser Zieladresse nie an, wenn sie selbst wieder im Tunnel landen sollen.

Hier würde ich noch einmal von vorne beginnen mit der Planung ... ich bin nicht einmal sicher, daß das AVM-VPN bei LAN-LAN-Kopplung ohne privates Netz auf der Seite des virtuellen Servers auskommt (also ob hier die "Sperre" der IPSec-Pakete über deren Portnummern ausreichend wäre).

Hier läge auch eine "Einwahlkonfiguration" (also die Verbindung der FRITZ!Box mit einem Firmennetzwerk - aka "der Server") irgendwie näher, solange das nur um diesen einen Host (eben den Server) geht.
 
Hallo Shirocco88
hallo PeterPawn

danke für eure Rückmeldungen.

@Shirocco88 Snipped anbei (ich hoffe ich habe alles vernünftig verfremdet...). Der obere Teil bezieht sich, glaub ich, noch auf eine andere Config, die ich ausprobiert hatte.
Code: 
##### BEGIN SECTION vpn VPN

VPN avmike
-------
-rw-r--r--    1 root     root         13416 Jan 10 04:20 /var/tmp/ike.log
-rw-r--r--    1 root     root         20527 Jan  9 21:50 /var/tmp/ike.old
2019-01-09 21:47:50 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:47:50 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:47:55 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:47:55 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:47:55 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 56b7dc1b2b3a581c RC 00000000 0000 SA flags=
2019-01-09 21:47:55 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:47:55 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 56b7dc1b2b3a581c RC c69d13649a33d429 8a2ed1b8 NOTIFICATION flags=
2019-01-09 21:47:55 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:47:55 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:00 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:00 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:00 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 18da57561dd43aca RC 00000000 0000 SA flags=
2019-01-09 21:48:00 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:00 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 18da57561dd43aca RC 9fa008a5b7efe2d6 e14aaf07 NOTIFICATION flags=
2019-01-09 21:48:00 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:00 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:05 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:05 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:05 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 58ce37f52700933e RC 00000000 0000 SA flags=
2019-01-09 21:48:05 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:05 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 58ce37f52700933e RC d7a919d22f42f3e0 edf3ec90 NOTIFICATION flags=
2019-01-09 21:48:05 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:05 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:10 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:10 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:10 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 4f17f6ceda8dfd69 RC 00000000 0000 SA flags=
2019-01-09 21:48:10 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:10 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 4f17f6ceda8dfd69 RC 517583a17666a992 574ca3a9 NOTIFICATION flags=
2019-01-09 21:48:10 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:10 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:15 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:15 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:15 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 284d080ded2bf0e5 RC 00000000 0000 SA flags=
2019-01-09 21:48:15 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:15 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 284d080ded2bf0e5 RC 3bba35d3519f98cc 291f0eed NOTIFICATION flags=
2019-01-09 21:48:15 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:15 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:20 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:20 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:20 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC c729a69a68ba452 RC 00000000 0000 SA flags=
2019-01-09 21:48:20 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:20 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC c729a69a68ba452 RC ab776fedb78001a9 436205aa NOTIFICATION flags=
2019-01-09 21:48:20 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:20 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:25 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:25 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:25 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 76fa0153e849a22b RC 00000000 0000 SA flags=
2019-01-09 21:48:25 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:25 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 76fa0153e849a22b RC 524f064636e5eceb a74ec8a NOTIFICATION flags=
2019-01-09 21:48:25 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:25 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:30 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:30 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:30 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 9bf833a123dfb696 RC 00000000 0000 SA flags=
2019-01-09 21:48:30 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:30 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 9bf833a123dfb696 RC 202dd6af2b2ee9b 21db9df5 NOTIFICATION flags=
2019-01-09 21:48:30 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:30 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:35 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:35 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:35 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 847231e7fa5d5d10 RC 00000000 0000 SA flags=
2019-01-09 21:48:35 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:35 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 847231e7fa5d5d10 RC 4d92eb15c71db5d3 3fa024bd NOTIFICATION flags=
2019-01-09 21:48:35 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:35 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:40 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:40 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:40 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC a078ff0acd337709 RC 00000000 0000 SA flags=
2019-01-09 21:48:40 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:40 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC a078ff0acd337709 RC 2ef094833a21dc87 347af48 NOTIFICATION flags=
2019-01-09 21:48:40 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:40 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:45 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:45 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:45 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC a7cdbab34e1286e3 RC 00000000 0000 SA flags=
2019-01-09 21:48:45 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:45 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC a7cdbab34e1286e3 RC d01cf05830819926 b9e05f93 NOTIFICATION flags=
2019-01-09 21:48:45 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:45 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:50 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:50 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:50 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 209f6cccb6cfbe04 RC 00000000 0000 SA flags=
2019-01-09 21:48:50 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:50 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 209f6cccb6cfbe04 RC 89d85e485b8fee33 8528a9a5 NOTIFICATION flags=
2019-01-09 21:48:50 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:50 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:48:55 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:48:55 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:48:55 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 66d67b3b5a3fb84d RC 00000000 0000 SA flags=
2019-01-09 21:48:55 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:48:55 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 66d67b3b5a3fb84d RC 50939aa9ad77abc5 76ef7577 NOTIFICATION flags=
2019-01-09 21:48:55 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:48:55 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:00 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:00 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:00 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC d3cac8ddd5f4c178 RC 00000000 0000 SA flags=
2019-01-09 21:49:00 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:00 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC d3cac8ddd5f4c178 RC 685b2891677caa1b 8a93da3d NOTIFICATION flags=
2019-01-09 21:49:00 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:00 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:05 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:05 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:05 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 1fb5e9d110ddaa57 RC 00000000 0000 SA flags=
2019-01-09 21:49:05 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:05 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 1fb5e9d110ddaa57 RC 506b8853ab8ba09d f4235b38 NOTIFICATION flags=
2019-01-09 21:49:05 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:05 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:10 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:10 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:10 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 15d25535e2bc0997 RC 00000000 0000 SA flags=
2019-01-09 21:49:10 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:10 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 15d25535e2bc0997 RC 7639908dd2c5357 270f6f8a NOTIFICATION flags=
2019-01-09 21:49:10 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:10 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:15 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:15 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:15 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC b8d169b448082d46 RC 00000000 0000 SA flags=
2019-01-09 21:49:15 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:15 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC b8d169b448082d46 RC 1af21be79dbcb3ef 5a4f83c4 NOTIFICATION flags=
2019-01-09 21:49:15 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:15 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:20 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:20 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:20 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC f1e42ba278040169 RC 00000000 0000 SA flags=
2019-01-09 21:49:20 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:20 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC f1e42ba278040169 RC c367dafcabdf7ac1 d06ba9e3 NOTIFICATION flags=
2019-01-09 21:49:20 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:20 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:25 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:25 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:25 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 9a560e47bf913c68 RC 00000000 0000 SA flags=
2019-01-09 21:49:25 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:25 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 9a560e47bf913c68 RC ee53b5666d4cdf73 467b3e81 NOTIFICATION flags=
2019-01-09 21:49:25 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:25 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:30 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:30 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:30 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 906967a4756f8886 RC 00000000 0000 SA flags=
2019-01-09 21:49:30 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:30 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 906967a4756f8886 RC 190f58ee78cc8586 2be3538 NOTIFICATION flags=
2019-01-09 21:49:30 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:30 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:35 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:35 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:35 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC beb11e0f9fde56bb RC 00000000 0000 SA flags=
2019-01-09 21:49:35 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:35 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC beb11e0f9fde56bb RC afad56b09013966f bf99c39e NOTIFICATION flags=
2019-01-09 21:49:35 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:35 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:40 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:40 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:40 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 1348287332a52e4e RC 00000000 0000 SA flags=
2019-01-09 21:49:40 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:40 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 1348287332a52e4e RC 6fc2f59fd7a908c c87040f0 NOTIFICATION flags=
2019-01-09 21:49:40 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:40 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:45 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:45 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:45 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC c219ba6d3b77d384 RC 00000000 0000 SA flags=
2019-01-09 21:49:45 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:45 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC c219ba6d3b77d384 RC b0c870a1a9b2ea0b a657d2cd NOTIFICATION flags=
2019-01-09 21:49:45 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:45 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:50 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:50 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:50 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 213da270585816 RC 00000000 0000 SA flags=
2019-01-09 21:49:50 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:50 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 213da270585816 RC 7bce0862aac48d12 ac838723 NOTIFICATION flags=
2019-01-09 21:49:50 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:50 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:49:55 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:49:55 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:49:55 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 919f248545afc4e0 RC 00000000 0000 SA flags=
2019-01-09 21:49:55 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:49:55 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 919f248545afc4e0 RC f65682b5a8067737 bf6d28f7 NOTIFICATION flags=
2019-01-09 21:49:55 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:49:55 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:00 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:00 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:00 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 683a9fcaa1c1671e RC 00000000 0000 SA flags=
2019-01-09 21:50:00 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:00 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 683a9fcaa1c1671e RC 1249dfae3a0237f6 ce7b7a30 NOTIFICATION flags=
2019-01-09 21:50:00 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:00 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:05 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:05 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:05 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 955d87f88404b224 RC 00000000 0000 SA flags=
2019-01-09 21:50:05 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:05 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 955d87f88404b224 RC 2ea0f6784918dc69 78e8dbd0 NOTIFICATION flags=
2019-01-09 21:50:05 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:05 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:10 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:10 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:10 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC cf3abd016f5c0639 RC 00000000 0000 SA flags=
2019-01-09 21:50:10 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:10 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC cf3abd016f5c0639 RC 38218537eb4d3b89 5cde50b NOTIFICATION flags=
2019-01-09 21:50:10 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:10 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:15 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:15 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:15 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC c2c6c964afaf4f2d RC 00000000 0000 SA flags=
2019-01-09 21:50:15 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:15 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC c2c6c964afaf4f2d RC 4d83dd8dcb8c3d4a a1e8a946 NOTIFICATION flags=
2019-01-09 21:50:15 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:15 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:20 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:20 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:20 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC cb74f24cadbcb9cc RC 00000000 0000 SA flags=
2019-01-09 21:50:20 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:20 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC cb74f24cadbcb9cc RC 48586151c8039560 d3acb3f0 NOTIFICATION flags=
2019-01-09 21:50:20 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:20 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:25 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:25 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:25 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 4f829ace03c9553 RC 00000000 0000 SA flags=
2019-01-09 21:50:25 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:25 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 4f829ace03c9553 RC c9ef017dee147323 f9021a3c NOTIFICATION flags=
2019-01-09 21:50:25 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:25 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:30 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:30 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:30 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC ade1da1b8e622b74 RC 00000000 0000 SA flags=
2019-01-09 21:50:30 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:30 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC ade1da1b8e622b74 RC ad7cbeccc5e7ad06 c878c704 NOTIFICATION flags=
2019-01-09 21:50:30 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:30 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:35 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:35 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:35 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 8b3c6620c6ae4be0 RC 00000000 0000 SA flags=
2019-01-09 21:50:35 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:35 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 8b3c6620c6ae4be0 RC bec4737e530a9b53 471eef8c NOTIFICATION flags=
2019-01-09 21:50:35 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:35 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:40 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:40 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:40 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 832f964d9f7c8a7f RC 00000000 0000 SA flags=
2019-01-09 21:50:40 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:40 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 832f964d9f7c8a7f RC 7490d678b0a9574e dd402d3b NOTIFICATION flags=
2019-01-09 21:50:40 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:40 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:45 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:45 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:45 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 5345cbb6ab4f58f0 RC 00000000 0000 SA flags=
2019-01-09 21:50:45 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:45 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 5345cbb6ab4f58f0 RC 35e34d441171bd7a a087f9fc NOTIFICATION flags=
2019-01-09 21:50:45 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:45 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:50 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:50 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:50 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC ab0da7e0a2630619 RC 00000000 0000 SA flags=
2019-01-09 21:50:50 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:50 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC ab0da7e0a2630619 RC cd66a0943ee3bd54 3e64ee64 NOTIFICATION flags=
2019-01-09 21:50:50 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:50 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:55 avmike:< create_sa(appl=dsld,cname=ipsec.tld.de)
2019-01-09 21:50:55 avmike:ipsec.tld.de: Phase 1 starting
2019-01-09 21:50:55 avmike:>>> aggressive mode [46.111.222.14] ipsec.tld.de: V1.0 720 IC 4ced34f4871561b3 RC 00000000 0000 SA flags=
2019-01-09 21:50:55 avmike:ipsec.tld.de: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:50:55 avmike:<<<  infomode[46.111.222.14] ipsec.tld.de: V1.0 56 IC 4ced34f4871561b3 RC 61bf624e97306a55 a47e6b46 NOTIFICATION flags=
2019-01-09 21:50:55 avmike:ipsec.tld.de: Phase 1 failed (initiator): IKE-Error 0x203f
2019-01-09 21:50:55 avmike:< cb_sa_create_failed(name=ipsec.tld.de,reason=IKE-Error 0x203f)
2019-01-09 21:50:59 avmike:< add(appl=dsld,cname=vpnuser,localip=46.59.215.91, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:50:59 avmike:new neighbour vpnuser:  dynamic  user  every-id  nat_t
2019-01-09 21:51:28 avmike:< add(appl=dsld,cname=vpnuser,localip=46.59.215.91, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:51:28 avmike:new neighbour vpnuser:  dynamic  user  every-id  nat_t
2019-01-09 21:54:59 avmike:< add(appl=dsld,cname=vpnuser,localip=46.59.215.91, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:54:59 avmike:new neighbour vpnuser:  dynamic  user  every-id  nat_t
2019-01-09 21:54:59 avmike:< add(appl=dsld,cname=Linux-VPS,localip=46.59.215.91, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x48001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:54:59 avmike:new neighbour Linux-VPS:  nat_t
2019-01-09 21:54:59 avmike:< create_sa(appl=dsld,cname=Linux-VPS)
2019-01-09 21:54:59 avmike:Linux-VPS: Phase 1 starting
2019-01-09 21:54:59 avmike:>>> identity protection mode [46.111.222.14] Linux-VPS: V1.0 532 IC 3db7b37615c803d9 RC 00000000 0000 SA flags=
2019-01-09 21:54:59 avmike:Linux-VPS: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:54:59 avmike:<<<  identity protection mode[46.111.222.14] Linux-VPS: V1.0 136 IC 3db7b37615c803d9 RC eb62f82e8d588e4f 0000 SA flags=
2019-01-09 21:54:59 avmike:identity protection mode Linux-VPS: selected lifetime: 3600 sec(no notify)
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: XAUTH
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: DPD
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: NAT-T RFC 3947
2019-01-09 21:54:59 avmike:>>> identity protection mode [46.111.222.14] Linux-VPS: V1.0 228 IC 3db7b37615c803d9 RC eb62f82e8d588e4f 0000 KEY flags=
2019-01-09 21:54:59 avmike:Linux-VPS: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:54:59 avmike:<<<  infomode[46.111.222.14] Linux-VPS: V1.0 56 IC 3db7b37615c803d9 RC eb62f82e8d588e4f bd9b85c7 NOTIFICATION flags=
2019-01-09 21:54:59 avmike:Linux-VPS: Phase 1 failed (initiator): IKE-Error 0x2005
2019-01-09 21:54:59 avmike:< cb_sa_create_failed(name=Linux-VPS,reason=IKE-Error 0x2005)
2019-01-09 21:54:59 avmike:< add(appl=dsld,cname=vpnuser,localip=46.59.215.91, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:54:59 avmike:new neighbour vpnuser:  dynamic  user  every-id  nat_t
2019-01-09 21:54:59 avmike:< add(appl=dsld,cname=Linux-VPS,localip=46.59.215.91, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x48001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2019-01-09 21:54:59 avmike:new neighbour Linux-VPS:  nat_t
2019-01-09 21:54:59 avmike:< create_sa(appl=dsld,cname=Linux-VPS)
2019-01-09 21:54:59 avmike:Linux-VPS: Phase 1 starting
2019-01-09 21:54:59 avmike:>>> identity protection mode [46.111.222.14] Linux-VPS: V1.0 532 IC d63365969f12a0d4 RC 00000000 0000 SA flags=
2019-01-09 21:54:59 avmike:Linux-VPS: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:54:59 avmike:<<<  identity protection mode[46.111.222.14] Linux-VPS: V1.0 136 IC d63365969f12a0d4 RC b96e6203f4a0ea9f 0000 SA flags=
2019-01-09 21:54:59 avmike:identity protection mode Linux-VPS: selected lifetime: 3600 sec(no notify)
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: XAUTH
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: DPD
2019-01-09 21:54:59 avmike:Linux-VPS receive VENDOR ID Payload: NAT-T RFC 3947
2019-01-09 21:55:00 avmike:>>> identity protection mode [46.111.222.14] Linux-VPS: V1.0 228 IC d63365969f12a0d4 RC b96e6203f4a0ea9f 0000 KEY flags=
2019-01-09 21:55:00 avmike:Linux-VPS: Warning: source changed from 0.0.0.0:500 to 46.111.222.14:500
2019-01-09 21:55:00 avmike:<<<  infomode[46.111.222.14] Linux-VPS: V1.0 56 IC d63365969f12a0d4 RC b96e6203f4a0ea9f 7d7ea90d NOTIFICATION flags=
2019-01-09 21:55:00 avmike:Linux-VPS: Phase 1 failed (initiator): IKE-Error 0x2005
2019-01-09 21:55:00 avmike:< cb_sa_create_failed(name=Linux-VPS,reason=IKE-Error 0x2005)
2019-01-09 22:00:33 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:00:37 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:00:44 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:00:57 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:01:20 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:02:02 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:03:18 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:03:22 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:03:29 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:03:42 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:04:05 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:04:47 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:06:03 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:06:07 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:06:14 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:06:27 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:06:50 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-09 22:07:32 avmike:46.111.222.14: packet check: IKE-Error 0x200a:
2019-01-10 01:38:24 avmike:< add(appl=dsld,cname=vpnuser,localip=46.59.219.53, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-10 01:38:24 avmike:new neighbour vpnuser:  dynamic  user  every-id  nat_t
2019-01-10 01:38:24 avmike:< add(appl=dsld,cname=Linux-VPS,localip=46.59.219.53, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x48001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2019-01-10 01:38:24 avmike:new neighbour Linux-VPS:  nat_t
2019-01-10 01:38:24 avmike:< create_sa(appl=dsld,cname=Linux-VPS)
2019-01-10 01:38:24 avmike:Linux-VPS: Phase 1 starting
2019-01-10 01:38:24 avmike:>>> identity protection mode [46.111.222.14] Linux-VPS: V1.0 532 IC 5b501b5254e70fb9 RC 00000000 0000 SA flags=
2019-01-10 01:38:26 avmike:>r> identity protection mode [46.111.222.14] Linux-VPS: V1.0 532 IC 5b501b5254e70fb9 RC 00000000 0000 SA flags=
2019-01-10 01:38:30 avmike:>r> identity protection mode [46.111.222.14] Linux-VPS: V1.0 532 IC 5b501b5254e70fb9 RC 00000000 0000 SA flags=
2019-01-10 01:38:38 avmike:Linux-VPS: Phase 1 failed (initiator): IKE-Error 0x2027
2019-01-10 01:38:39 avmike:< cb_sa_create_failed(name=Linux-VPS,reason=IKE-Error 0x2027)
2019-01-10 04:20:54 avmike:<<<  identity protection mode[216.218.206.66:65392] ???: V1.0 64 IC 3e35c70729dfedef RC 00000000 0000 SA flags=
2019-01-10 04:20:54 avmike:no phase1ss for cert users configured
2019-01-10 04:20:54 avmike:216.218.206.66:65392: new_neighbour_template failed

VPN assocs
----------
/proc/kdsld/dsliface/internet/ipsec/assocs:
vpnuser: 46.59.219.55:0.0.0.0 0.0.0.0:192.168.178.201 0 SAs  valid enabled dynlocalip dynremoteip
    permit ip any host 192.168.178.201
    Forbidden Clients: 192.168.179.0/24
Linux-VPS: 46.59.219.55:0.0.0.0 255.255.255.255:0.0.0.0 0 SAs  valid enabled dynlocalip
    permit ip any 46.111.222.14 255.255.248.0
    Forbidden Clients: 192.168.179.0/24

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
vpnuser: pmtu 0 mtu 1492 dont_filter_netbios
Linux-VPS: pmtu 0 mtu 1492 dont_filter_netbios

##### END SECTION vpn


@PeterPawn
Verstehe ich dich richtig, dass ich möglicherweise eine virtuelle Lanschnittstelle anlege und darüber den Ipsec Traffic laufen lasse und über die "normale" Server IP dann die Erreichbarkeit aus dem Internet? Momenatn denke ich würde es reichen wenn nur https-Traffic über die Server IP geht und alles andere über die VLan IP. Würde man das dann per IP-Tables routen?
Ich hatte auf der Seite von Stronswan auch kurz das Thema Split-Tunneling überflogen. Wäre das ein dritter Ansatz oder das gleiche?

Hast Du für die Einwahlkonfiguration eine gute Quelle/How-To in welches ich mich einarbeiten kann?

Danke euch!
 
Noch einmal ganz (ganz) deutlich ... ohne exakte Beschreibung, was am Ende tatsächlich über diese VPN-Verbindung getunnelt werden soll, kann man nicht mal einen sinnvollen Plan machen.

Was soll denn
JJFF schrieb:
Momenatn denke ich würde es reichen wenn nur https-Traffic über die Server IP geht und alles andere über die VLan IP.
Zum Vergrößern anklicken....
eigentlich heißen? Selbst wenn ich mal annehme, daß die "Server IP" die 46.111.222.14 sein soll ... was bitte ist denn eine "VLan IP"?

Warum sollte man "per IP-Tables" irgendetwas routen? Und vor allem, wo sollte das erfolgen? Auf der FRITZ!Box gibt es schon mal kein "iptables"-Kommando und man kann auch nur mit großem Aufwand etwas in der Richtung einbinden. Man kann alles Mögliche mit "iptables" machen (bis hin zu Änderungen an Paketen und der Auswahl der richtigen Transformation für IPSec im Kernel) - aber "routen" kann man damit eigentlich gar nichts.

Normalerweise versteht man unter "split tunneling" eine Konfiguration, bei der Daten unterschiedliche Wege nehmen können ... meist in Abhängigkeit von ihrem Source-EP bzw. dem Target-EP. Was sollte das i.V.m. dem strongSwan hier für einen Sinn ergeben ... bisher dachte ich, daß die FRITZ!Box solches "split tunneling" verwenden müßte.

Aber das führt wieder zur Frage, was da nun tatsächlich über den Tunnel gesendet und/oder empfangen werden soll ... solange man da nur raten kann, ist alles andere auch nur Gestocher im Nebel.

Und auch wenn man das dann weiß, gehört zu einem "Fehlerbericht" in Bezug auf VPN-Probleme eine vollständige "Berichterstattung" - in dem "Fitzelchen" von Protokoll (ja, nicht "Zitrone von Schale", was einem Cineasten vielleicht auch einfallen könnte) sind schon mal mind. drei verschiedene Fehler zu sehen und es ist sehr unwahrscheinlich, daß die alle mit derselben Konfiguration aufgetreten sind. Die Ansätze der Protokolle und Konfigurationsdateien in #1 waren per se schon nicht schlecht ... warum das auf der FRITZ!Box-Seite jetzt so abfällt bzw. warum der Leser sich die verschiedenen verwendeten Konfigurationen nun irgendwie selbst ausmalen soll, kann ich nicht so richtig verstehen. Unvollständige Informationen sind auch beim Leser reine Zeitverschwendung, weil man dann weiterhin nur raten kann, was da wohl in den Konfigurationsdateien stehen mag.

JJFF schrieb:
Hast Du für die Einwahlkonfiguration eine gute Quelle/How-To in welches ich mich einarbeiten kann?
Zum Vergrößern anklicken....
Nein, habe ich nicht. DIe FRITZ!Box kann (per GUI-Editor) per se drei verschiedene Szenarien abdecken ... einen "remote client", der sich bei der FRITZ!Box einwählt (dafür braucht es pro Verbindung einen Benutzereintrag in der Box), die Einwahl der FRITZ!Box bei einem "access server" und die Kopplung zweier lokaler Netze - die beiden letzten kommen ohne einen gesonderten FRITZ!Box-Benutzer aus. Welches Szenario dem geplanten Einsatzzweck nun am nächsten kommt, wird man dann auch erkennen können, wenn man den Sinn dieser VPN-Verbindung erst mal erfahren hat.
 
Ergänzend Beispiele für "Use-Cases" des VPN-Tunnels:
1.) alle Rechner aus dem LAN der Fritzbox sollen über den IPsec-Tunnel auf den VPS-Server zugreifen können
==> Fritzbox VPN-Typ: "conntype_user"

2.) alle Rechner aus dem LAN der Fritzbox sollen (genattet) auf das private Netz VPS-Server zugreifen,
hierbei ist "Split-Tunnel" oder" Catch-All" (d.h. allen Traffic aus dem LAN der Fritzbox an den VPN-Server schicken) konfigurierbar.
==> Fritzbox VPN-Typ: "conntype_out", VPN-Verbindung zu einem "Firmen-LAN"

3.) die beiden privaten Netze von Fritzbox und VPS-Server werden per IPsec-Tunnel verbunden.
hierbei ist u.a. "Split-Tunnel" oder" Catch-All" (z.B. allen Traffic aus dem LAN der Fritzbox an den VPN-Server schicken) konfigurierbar.
==> Fritzbox VPN-Typ: "conntype_lan"

Hier ist TE gefordert dies zu benennen/beschreiben.
 
  • Like
Reaktionen: Micha0815
Hallo und danke euch,
danke auch für die Ermahnung, @PeterPawn, mich hier verständlich auszudrücken. War etwas der Müdigkeit geschuldet...

Ich versuche den Einsatzzweck mal etwas besser zu beleuchten (bitte seht mir eine möglicherweise falsche Verwendung der Termini nach. Ich übe noch...):
Ein Bild sagt ja bekanntlich mehr als 1000 Worte, hier mal ein mein grobes Wunschsetup.

(irgendwie klappt das einbinden von dem Bild nicht, daher per Link - Bild dem Board angehängt - by stoney)

w7gSi76.png


Ich möchte den Traffic zwischen dem VPS und dem Neztwerk hinter der Fritzbox per VPN (für bestimmte Ports) absichern, gleichzeitig den Zugriff aus dem Internet auf einige laufende Anwendugnen (auf anderen Ports) frei erreichbar haben - sowohl auf dem VPS als auch auf Geräten hinter der Fritzbox.

Da ich an den Geräten (Homeserver 1 & 2) hinter Fritzbox immer mal wieder rumbastle und sich dadurch das setup häufiger ändert, wollte ich den VPN Tunnel nicht von dort zum VPS definieren sondern dies der Fritzbox überlassen und die Konfiguration zentral und einmalig aufsetzen. Ist das so sinnvoll?

Ich hatte den VPS schon mal per VPNC erfolgreich in die Fritzbox einwählen lassen (da kamen vermutlich auch ein paar der Snippets im Protokoll oben her), konnte aber weder die restlichen Geräte im Fritznetz erreichen (ping klappte nur auf die Fritzbox) noch war der VPS dann noch aus dem Internet unter seiner IP erreichbar (logisch, er hatte ja jetzt die IP der Fritzbox). Ich bin dann davon ausgegangen, dass ein Einwahlszenario damit nicht das richtige ist. Richtig?

Ich hatte auch mal überlegt, dass es sich eigentlich um ein End-to-Site setup (habe ich im Stronswan Wiki gelesen) handeln müsste, da sich ja eigentlich hinter dem VPS keine weiteren Teilnehmer mehr befinden. Leider gab zu dem Setup aber wenig Beispiele, wehalb ich auf eine Site-to-Site Lösung umgeschwenkt bin.

Ist das so besser verständlich und machen meine Gedanken Sinn?
 
Zuletzt bearbeitet von einem Moderator:
Mal abgesehen davon, daß die beiden Server im Heimnetz vermutlich nicht dieselbe IP-Adresse benutzen werden, ergibt das schon Sinn ... aber hier ist es dann tatsächlich besser, wenn sich der virtuelle Server selbst als "remote client" in die FRITZ!Box einwählt. Damit erhält er eine IP(v4)-Adresse aus dem LAN der FRITZ!Box und ist über diese dann "per Tunnel" erreichbar. Bei virtuellen Servern stellt sich dann häufig aber die Frage der verwendeten Virtualisierung und ob bei dieser dann der (eingeschränkte) Admin entsprechende Löcher in eine Firewall stanzen kann - aber das ist wieder ein anderes Thema und von der verwendeten Topologie nicht direkt abhängig.

Jedenfalls würde man hier tatsächlich für den VPS einen Benutzer in der FRITZ!Box anlegen und dann kann er sich (als "road-warrior" - daß er eine feste IPv4-Adresse hat, interessiert dabei nicht wirklich) in der FRITZ!Box anmelden ... allerdings muß diese dazu irgendwie im Internet auffindbar sein (DynDNS-Adresse).

Das wäre jedenfalls die einfachste Konfiguration für diesen Einsatzfall ... alle Zugriffe auf den Server sind über den Tunnel möglich und gleichzeitig bleibt der Server unter seiner externen IP-Adresse erreichbar.

Allerdings sollte man dann die VPN-Benutzer noch einmal neu einrichten ... da jeder dieser Benutzer seine eigene lokale IP-Adresse "reserviert", führen die (irgendwo oben sichtbaren) schon vorhandenen Konten zu einer "Verschiebung" der .201 - das muß nicht zwangsläufig ein Problem sein, wirkt aber "unordentlich" und bringt ggf. bei späteren Änderungen Probleme mit sich. Richtet man die Verbindung für den Server als erste ein, sollte die auch immer diese Adresse kriegen.

Allerdings ist es nicht trivial, für diese Serververbindung dann einen DNS-Namen zu vergeben ... wenn man den unbedingt braucht (notfalls behilft man sich mit passenden "hosts"-Einträgen bzw. "lmhosts", wenn es um Windows geht), muß man etwas mehr Aufwand investieren, weil die FRITZ!Box den VPN-Adressen bisher keine Namen zuordnet (das ist auch nicht wirklich trivial zu lösen, weil dasselbe Gerät direkt im LAN ja eine andere IPv4-Adresse hat).
 
JJFF schrieb:
Ich möchte den Traffic zwischen dem VPS und dem Neztwerk hinter der Fritzbox per VPN (für bestimmte Ports) absichern, gleichzeitig den Zugriff aus dem Internet auf einige laufende Anwendugnen (auf anderen Ports) frei erreichbar haben - sowohl auf dem VPS als auch auf Geräten hinter der Fritzbox.
Zum Vergrößern anklicken....

auf seiten der Fritzbox würde ich bei der empfohlenen "User Dial-In" VPN-Configuration eine Anpassung der Accesslist-Configuration durchführen und die VPN-Tunnel-Nutzung seitens Fritzbox-LAN auf die 2 Devices (RasPI, NAS) und deren benötigten Protokolle "whitelisten".
 
Hallo zusammen,

mit dem Hinweis auf das Einwahlszenario habe ich etwas im Netz gesucht und siehe da, es funktioniert. DANKE!!!

Ich habe in der Fritzbox einen Benutzer vserver angelegt. Meine ein ipsec.conf sieht folgendermaßen aus
Code: 
config setup
        uniqueids=no
conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1 
 
   # Anforderung Fritzbox
        ike=aes256-sha-modp1024
        esp=aes256-sha1-modp1024
        keyexchange=ikev1
        aggressive=yes

conn home
        left=46.111.222.14
        leftid=keyid:vserver
        leftsourceip=%config4
        leftauth=psk
        leftauth2=xauth
        leftfirewall=yes 
        xauth_identity=vserver
     
        right=abcdefg.myfritz.net
        [email protected]
        rightsubnet=192.168.178.0/24
        rightauth=psk
        auto=add

die ipsec.secrets
Code: 
: PSK 0n8kE12fggP0ZjMTS

vserver : XAUTH "S7244FtjpdCUSV"

Ich werde beobachten wie stabil das setup läuft. Kann man daran noch etwas verbessern?

@Shirocco88 das Thema "whitelisten" werde ich angehen, wenn der RaspPI wieder angeschlossen wird.
 
Dann kannst Du das Thema ja entsprechend kennzeichnen, damit sich andere schon am Titel (bzw. am "Tag") orientieren können, danke.
 
Hallo nochmal!

Es hat sich doch ein Problem ergeben, bei dem ich nicht wirklich sicher bin wie ich es löse:

Die Verbindung zur Fritzbox wird nicht gehalten.

ipsec statusall gibt folgendes:

Code: 
Status of IKE charon daemon (strongSwan 5.5.1, Linux 4.9.0-8-amd64, x86_64):
  uptime: 3 days, since Jan 20 11:22:34 2019
  malloc: sbrk 2834432, mmap 0, used 515488, free 2318944
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Listening IP addresses:
  46.111.222.14
  172.17.42.1
Connections:
        home:    46.111.222.14...abcdefg.myfritz.net  IKEv1 Aggressive
        home:   local:  [vserver] uses pre-shared key authentication
        home:   local:  [vserver] uses XAuth authentication: any with XAuth identity 'vserver'
        home:   remote: uses pre-shared key authentication
        home:   child:  dynamic === 192.168.178.0/24 TUNNEL
Security Associations (0 up, 0 connecting):
  none

per ipsec up wird die Verbindung wieder hergestellt und alles funktioniert wieder top, aber wie kann ich sicherstellen, dass die Verbindung dauerhaft gehalten wird und auch wieder aufgebaut wird, wenn der VPS neu gestartet wird.
 
JJFF schrieb:
an einen KVM VPS von netcup gekoppelt werden.
Zum Vergrößern anklicken....
auf welchem LINUX Derivate (Debian, Red Hat, SuSE, ...) basiert den "KVM VPS von netcup" ?
JJFF schrieb:
auch wieder aufgebaut wird, wenn der VPS neu gestartet wird.
Zum Vergrößern anklicken....
das wird üblicherweise per rc-start-skript aus init.d oder per systemd gestartet;
abhängig von LINUX Derivate/OS-Version.
ohne weitere Angaben tut man sich hier schwer.
 
Es handelt sich ein Debian Stretch System.

Nach Neuinstallation von Strongswan klappt zumindest der Verbindungsaufbau nach Neustart. Tunnel steht, Fritzbox zeigt grün an und pings gehen ohne Probleme hin und her.
Die Tunnel wird nur weiterhin nicht dauerhaft gehalten.
 
Auch wenn ich wie eine kaputte Schallplatte klinge ... zu so einer Frage gehören (automatisch und unaufgefordert) die notwendigen Hintergrundinformationen. Schon die Frage, ob strongSwan hier eine NAT-T-Konstellation detektiert und verwendet, hat unmittelbaren Einfluß darauf, ob man mit Keepalives (über charon-Konfiguration) etwas ausrichten kann oder nicht. Daher braucht es sowohl die aktuell verwendeten Konfigurationen und die dazugehörenden (also ebenfalls aktuellen) Protokolle - alles andere ist reine Zeitverschwendung (beim Leser wohlgemerkt).

Trotz der Aufforderung (oder nennen wir es "Bitte") in #5, solche Fragen mit den notwendigen Daten zu "untermauern", sollen die Leute hier erneut erst wieder (und zwar denjenigen mit dem Problem, der eigentlich von sich aus jedwede Anstrengung unternehmen müßte, es den Leuten bei Antwortversuchen so einfach wie möglich zu machen, sein Problem zu erkennen) "an der Zunge ziehen", damit diese Infos dann doch noch zur Verfügung gestellt werden?

Sorry ... nicht so mein Fall - eine Erklärung, warum das so, wie es hier erwartet wird, nur "brotlose Kunst" ist, sollte ausreichen. Daher bin ich hier raus - auch wenn ich mir die "Erklärung", warum das so ist, wieder mal nicht verkneifen konnte (manchmal ist aber auch das besser, als einfach nur in eisiges Schweigen zu verfallen, weil es dem Fragesteller die Option der "Besserung" offeriert).

Ob der (mehr oder weniger versteckte) Hinweis auf "keepalives" zum Offenhalten der Verbindung noch etwas bringt oder nicht, muß man sehen ... ich gebe jedenfalls meinen Senf erst wieder dazu, wenn belastbare Informationen (zuviel kann man in so einem Fall eigentlich gar nicht "veröffentlichen") vorliegen.
 
Hallo @PeterPawn,
leider bin ich in der ganze Materie Anfänger, daher sieh es mir nach wenn ich mit dem Hinweis auf automatische und unaufgeforderte Hintergrundinformationen wenig anfangen kann. Schon in #8 habe ich nicht wirklich verstanden, was Du denn genau jetzt von mir benötigst.

An dem ganze Szenarion inklusive Konfiguration hat sich zu #10 bzw. #7 nichts verändert, sonst hätte ich das erwähnt.

Denn Du mir einen Hinweis gibt, welche Hintergrundinfos denn standardmäßig zu einer guten Darstellung des Problems gehört, kann ich das gerne liefern.
 
JJFF schrieb:
welche Hintergrundinfos denn standardmäßig zu einer guten Darstellung des Problems gehört, kann ich das gerne liefern.
Zum Vergrößern anklicken....
da fällt mir auf Anhieb folgendes ein:

1.) Inputs von VPS-Server:
Code: 
echo "==================================================="
echo "Tabelle filter (Packet Filtering)"
echo "iptables -L -vn"
echo
echo "==================================================="
echo "Tabelle nat"
echo "iptables -t nat -L -vn"
iptables -t nat -L -vn
echo "==================================================="
2.) Inputs von Fritzbox:
Auszug auf Supportdaten
http://fritz.box/?lp=support

Code: 
##### BEGIN SECTION vpn VPN
...
##### END SECTION vpn


##### BEGIN SECTION dyndns DynDNS
...
##### END SECTION dyndns


##### BEGIN SECTION Networking Supportdata networking
...
##### END SECTION Networking Supportdata networking


##### BEGIN SECTION Events Events
...
##### END SECTION Events


ggf. bei vpn.cfg die Zeilen key, remoteip, remotehostname anonymisieren;
das ike.log sollte die Zeile "avmike:< add(appl=dsld,cname=" beginnend enthalten;
alles in CODE-Tags und dann kann man weiteres sagen.
 
@JJFF:
Nicht böse sein, aber die vollständigen Konfigurationsdateien und die Protokolle einer VPN-Session (am besten noch an der Stelle, wo die Verbindung dann eben nicht erneuert wird) sollte jeder finden können, der sich überhaupt an die Konfiguration so einer Topologie macht ... spätestens wenn man den ersten Handgriff daran vornimmt, sollte man ja wissen, wo sich die Konfigurationsdateien befinden und wenn man die Protokolle nicht selbst lesen will und daher nicht weiß, wo diese zu finden sind, hilft auch bei dieser Frage - wie so oft - "das Internet" mit einer Suchmaschine ungemein weiter.

Wo man bei der FRITZ!Box die Protokolldateien findet (nämlich in den Support-Daten), ist auch nicht sooo schwer zu ermitteln - es steht hier überall (wenn's um VPN geht) und auch hier hilft eine Suchmaschine ggf. weiter, wenn ich so gar nicht weiß, was mein Gegenüber nun von mir will.

Man kann eben anhand der "ipsec.conf" nicht erkennen, welche Parameter die aufgebaute VPN-Verbindung benutzt und auch die Fragen hinsichtlich DPD und Keepalive kann man sich zwar ggf. selbst zusammensuchen, indem man erst mal mühsam erkundet, was denn nun die Standardwerte für die jeweils nicht gesetzten Parameter wären ... das geht aber anhand des Protokolls deutlich einfacher, denn da werden diese Angaben nämlich explizit aufgelistet. Das Wiki zu strongSwan widmet den Möglichkeiten der Protokollierung sogar einen eigenen "Unterpunkt": https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration

Solange niemand weiß, WARUM die Verbindung abgebaut und nicht wieder erneuert wird (hier ist nur zu lesen, daß es so sein soll), KANN man auch nur im Nebel stochern, wie man diesen Umstand vermeiden könnte. Wo anders als im Protokoll sollte man das jetzt erkunden können?

Ist es tatsächlich zu "fordernd", wenn man solche Überlegungen auch bei einem Fragesteller voraussetzt? Das ist doch nun mal ein technisches Forum und bei so ziemlich jedem technischen Problem steht doch am Beginn erst einmal die genaue Diagnose, was die Ursache des Problems ist (ob der Motor nicht anspringt, weil der Tank leer oder die Kraftstoffpumpe defekt ist). Wie sollte man eine solche Diagnose denn mit der "berühmten Glaskugel" bewerkstelligen?

Das ist dann - zugegebenermaßen - irgendwann auch mal "Unlust" beim eigentlich Antwortwilligen ... es macht eben auch keinen Spaß, immer wieder auf diese Punkte hinweisen zu müssen. Ich habe es bisher nur ganz, ganz selten erlebt, daß jemand tatsächlich zuviel über sein Problem geschrieben hätte (wenn das so war, ging es meist auch in die falsche Richtung oder eine Sackgasse bei den eigenen Überlegungen) ... ich hatte die Ansätze in #1 ja bereits "gelobt" und meiner Verwunderung darüber Ausdruck verliehen, warum man (konkret Du) diese Ansätze dann nicht weiter verfolgt.

Am Beginn - als auch Du noch in eine, eher gewöhnungsbedürftige Richtung unterwegs warst, die Du dann ja korrigiert hast - hast Du viele Einzelheiten in den Bericht gepackt ... nur bezogen die sich eben immer auf ein anderes VPN-Szenario und zu dem, was Du jetzt umgesetzt hast und verwendest, steht praktisch alles, was Du an Informationen teilen möchtest, in #10. Schon #12 ist praktisch witzlos, weil das auch nur die Feststellung "Verbindung ist nicht aufgebaut" zeigt und untermauert ... ich halte es für unwahrscheinlich, daß jemand Deine Beobachtungen diesbezüglich in Frage stellt. Aber ob Du tatsächlich auch heute noch 1:1 die Konfiguration aus #10 verwendest und wie dabei der (erfolgreiche) Verbindungsaufbau im Protokoll aussieht (am besten auf beiden Seiten) und was im Protokoll steht, wenn die SAs nicht erneuert werden, das sind die eigentlichen Fragen und auf die gehst Du nun mal mit keinem weiteren Wort ein.

Du weißt selbst, WAS Du gemacht hast ... wenn Du von jemand anderem Hilfestellung bei einem Problem erwartest, mußt Du denjenigen aber an diesen Informationen teilhaben lassen (und das im Idealfall auch noch so, daß der das alles "an einer Stelle" hat - selbst wenn Du Dich 10x wiederholen mußt, notfalls reicht auch der Hinweis, daß etwas nicht verändert wurde - und sich nichts "zusammenreimen" muß, weil er es alles dem geschriebenen Wort entnehmen kann).
 
Hallo @Shirocco88 & @PeterPawn,

schade, dass keine telepatischen Verbindungen im Forum gibt, dann wäre der Informationsaustausch um einiges einfacher :)
Ich habe mich nochmal dran gesetzt:

Das Forum mag so lange logs nicht, daher hab ich sie in die Logs.txt gepackt.

Die ipsec.conf

Code: 
config setup
        uniqueids=no

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1

        # Anforderung Fritzbox
        ike=aes256-sha-modp1024!
        esp=aes256-sha1
        keyexchange=ikev1
        aggressive=yes

conn home
        left=46.111.222.14
        leftid=keyid:vserver
        leftsourceip=%config4
        leftauth=psk
        leftauth2=xauth
        leftfirewall=yes
        xauth_identity=vserver

        right=abcdefg.myfritz.net
        rightid=%any
        rightsubnet=192.168.178.0/24
        rightauth=psk
        auto=start

include /var/lib/strongswan/ipsec.conf.inc

die ipsec.secrets

Code: 
include /var/lib/strongswan/ipsec.secrets.inc

: PSK 9cccddeegggeevhx

vserver : XAUTH "S7244FJHfgvaaaaabbbbSV"

ein tcpdump -nni ens3 esp or icmp liefert natürlich nichts, da keine Verbindung vorhanden:

Code: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
11:06:49.833323 IP 84.46.16.40 > 46.111.222.14: ICMP host 84.46.16.40 unreachable - admin prohibited filter, length 36

nach einem ispec home up sieht ein ip xfrm policy gut aus:

Code: 
src 192.168.178.0/24 dst 192.168.178.201/32
        dir fwd priority 185664 ptype main
        tmpl src 84.46.16.40 dst 46.111.222.14
                proto esp reqid 2 mode tunnel
src 192.168.178.0/24 dst 192.168.178.201/32
        dir in priority 185664 ptype main
        tmpl src 84.46.16.40 dst 46.111.222.14
                proto esp reqid 2 mode tunnel
src 192.168.178.201/32 dst 192.168.178.0/24
        dir out priority 185664 ptype main
        tmpl src 46.111.222.14 dst 84.46.16.40
                proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0 ptype main
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main
src ::/0 dst ::/0
        socket in priority 0 ptype main
src ::/0 dst ::/0
        socket out priority 0 ptype main
 

Anhänge

  • logs.txt
    204.7 KB · Aufrufe: 5
Zuletzt bearbeitet:
vorab ne Frage, muß der tägliche IP-Wechsel beim VPN-Dial-In Server (Fritzbox) sein ?

Code: 
26.01.19 01:08:55 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 84.46.16.44, DNS-Server: 213.209.104.220 und 213.209.104.250, Gateway: 84.46.104.107, Breitband-PoP: ASR-POP107
26.01.19 01:08:51 Internetverbindung wurde getrennt.
26.01.19 01:08:51 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
26.01.19 01:08:47 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.


ist das wirklich notwendig ?

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.

das Fritzbox Event Log sagt, die VPN Tunnelverbindung war am 23.01.2019 von 01:54:30 Uhr bis 17:58:17 Uhr weg (Ursache: 3 IKE server):
Code: 
Fritzbox Event Log

23.01.19 17:58:17 VPN-Verbindung zu vserver [46.111.222.14] IKE SA: DH2/AES-256/SHA1 IPsec SA: ESP-AES-256/SHA1/LT-1200 wurde erfolgreich hergestellt.
23.01.19 17:51:54 Anmeldung an der FRITZ!Box-Benutzeroberfläche von IP-Adresse 2a04:4540:6b04:cf00:3884:7d25:acd8:16f4. [2 Meldungen seit 23.01.19 17:04:36]
SNIP
23.01.19 01:54:30 VPN-Verbindung zu vserver wurde getrennt. Ursache: 3 IKE server
23.01.19 01:54:29 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 46.59.202.8, DNS-Server: 213.209.104.220 und 213.209.104.250, Gateway: 84.46.104.107, Breitband-PoP: ASR-POP107
23.01.19 01:54:25 Internetverbindung wurde getrennt.
23.01.19 01:54:25 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
23.01.19 01:54:21 Die Internetverbindung wird kurz unterbrochen, um der Zwangstrennung durch den Anbieter zuvorzukommen.

@JJFF
PeterPawn schrieb:
die vollständigen Konfigurationsdateien
Zum Vergrößern anklicken....
ich kann die vpn.cfg für Fritzbox-User "vserver" in #19 nicht finden.
siehe Fritzbox Supportdaten.txt oder Fritzbox Sicherung/Export-Datei.


die Lifetimes (Fritzbox LT8h) passen nicht zu den Einstellungen in ipsec.conf:

Code: 
Fritzbox Support Daten

 ##### BEGIN SECTION vpn VPN

VPN avmike
SNIP
2019-01-24 01:53:34 avmike:< add(appl=dsld,cname=vserver,localip=46.59.209.25, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-24 09:37:13 avmike:< add(appl=dsld,cname=vserver,localip=46.59.178.199, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-25 01:09:53 avmike:< add(appl=dsld,cname=vserver,localip=149.233.150.188, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2019-01-26 01:08:55 avmike:< add(appl=dsld,cname=vserver,localip=84.46.16.44, remoteip=0.0.0.0, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x803f tunnel xauth cfgmode nat_t no_certsrv_server_auth)

JJFF schrieb:
Code: 
conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 533 (Mitglieder: 4, Gäste: 529)

Neueste Beiträge

Statistik des Forums

Themen
246,171
Beiträge
2,247,421
Mitglieder
373,714
Neuestes Mitglied
Panicmaker
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück