Kein Datentransfer - IPSEC VPN zwischen Fritzbox und strongSwan

[realriot]

Hi,
es gibt so unendlich viele Howto-Dokumente und Forum-Artikel zu dem Thema, wie eine Fritzbox mit einem strongSwan VPN verbunden werden kann. Letztendlich habe ich die Verbindung zwischen meiner 7490 und meinem VPS auf dem strongSwan läuft durch den Artikel http://www.ip-phone-forum.de/showthread.php?t=272161 hinbekommen.

Konstrukt:
- Lokales Netz hinter der Fritzbox
- Virtuelle IP auf dem vServer

ip addr add 192.168.0.1/24 dev eth0

Server: Syslog nach dem Start von strongSwan

strongswan stop/waiting
strongswan start/running
Jan 26 14:34:59 VPS charon: 00[DMN] signal of type SIGINT received. Shutting down
Jan 26 14:34:59 VPS charon: 00[IKE] closing CHILD_SA fritzbox{1} with SPIs ccd016f9_i (128 bytes) 9f855a80_o (336 bytes) and TS 192.168.0.0/24 === 192.168.2.0/24
Jan 26 14:34:59 VPS charon: 00[IKE] sending DELETE for ESP CHILD_SA with SPI ccd016f9
Jan 26 14:34:59 VPS charon: 00[ENC] generating INFORMATIONAL_V1 request 2876694620 [ HASH D ]
Jan 26 14:34:59 VPS charon: 00[NET] sending packet: from <öffentliche ip des VPS>[500] to <öffentliche ip fritzbox>[500] (76 bytes)
Jan 26 14:34:59 VPS charon: 00[IKE] deleting IKE_SA fritzbox[1] between <öffentliche ip des VPS>[<öffentliche ip des VPS>]...<öffentliche ip fritzbox>[<dyndns hostname der fritzbox>]
Jan 26 14:34:59 VPS charon: 00[IKE] sending DELETE for IKE_SA fritzbox[1]
Jan 26 14:34:59 VPS charon: 00[ENC] generating INFORMATIONAL_V1 request 2090100533 [ HASH D ]
Jan 26 14:34:59 VPS charon: 00[NET] sending packet: from <öffentliche ip des VPS>[500] to <öffentliche ip fritzbox>[500] (92 bytes)
Jan 26 14:35:00 VPS charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.1.2, Linux 3.16.0-29-generic, x86_64)
Jan 26 14:35:00 VPS charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jan 26 14:35:00 VPS charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jan 26 14:35:00 VPS charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jan 26 14:35:00 VPS charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jan 26 14:35:00 VPS charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jan 26 14:35:00 VPS charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jan 26 14:35:00 VPS charon: 00[CFG]   loaded IKE secret for %any %any
Jan 26 14:35:00 VPS charon: 00[LIB] loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity xauth-generic addrblock
Jan 26 14:35:00 VPS charon: 00[LIB] unable to load 5 plugin features (5 due to unmet dependencies)
Jan 26 14:35:00 VPS charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jan 26 14:35:00 VPS charon: 00[JOB] spawning 16 worker threads
Jan 26 14:35:00 VPS charon: 04[CFG] received stroke: add connection 'fritzbox'
Jan 26 14:35:00 VPS charon: 04[CFG] added configuration 'fritzbox'
Jan 26 14:35:01 VPS CRON[2701]: (asterisk) CMD ([ -e /var/www/html/freepbx/admin/modules/dashboard/scheduler.php ] && /var/www/html/freepbx/admin/modules/dashboard/scheduler.php)
Jan 26 14:35:01 VPS charon: 06[NET] received packet: from <öffentliche ip fritzbox>[500] to <öffentliche ip des VPS>[500] (658 bytes)
Jan 26 14:35:01 VPS charon: 06[ENC] parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
Jan 26 14:35:01 VPS charon: 06[IKE] received XAuth vendor ID
Jan 26 14:35:01 VPS charon: 06[IKE] received DPD vendor ID
Jan 26 14:35:01 VPS charon: 06[IKE] received NAT-T (RFC 3947) vendor ID
Jan 26 14:35:01 VPS charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jan 26 14:35:01 VPS charon: 06[ENC] received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Jan 26 14:35:01 VPS charon: 06[IKE] <öffentliche ip fritzbox> is initiating a Aggressive Mode IKE_SA
Jan 26 14:35:01 VPS charon: 06[CFG] looking for pre-shared key peer configs matching <öffentliche ip des VPS>...<öffentliche ip fritzbox>[<dyndns hostname der fritzbox>]
Jan 26 14:35:01 VPS charon: 06[CFG] selected peer config "fritzbox"
Jan 26 14:35:01 VPS charon: 06[ENC] generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V ]
Jan 26 14:35:01 VPS charon: 06[NET] sending packet: from <öffentliche ip des VPS>[500] to <öffentliche ip fritzbox>[500] (388 bytes)
Jan 26 14:35:01 VPS charon: 07[NET] received packet: from <öffentliche ip fritzbox>[500] to <öffentliche ip des VPS>[500] (140 bytes)
Jan 26 14:35:01 VPS charon: 07[ENC] parsed AGGRESSIVE request 0 [ HASH NAT-D NAT-D N(INITIAL_CONTACT) ]
Jan 26 14:35:01 VPS charon: 07[IKE] IKE_SA fritzbox[1] established between <öffentliche ip des VPS>[<öffentliche ip des VPS>]...<öffentliche ip fritzbox>[<dyndns hostname der fritzbox>]
Jan 26 14:35:01 VPS charon: 07[IKE] scheduling reauthentication in 13686s
Jan 26 14:35:01 VPS charon: 07[IKE] maximum IKE_SA lifetime 14226s
Jan 26 14:35:01 VPS charon: 09[NET] received packet: from <öffentliche ip fritzbox>[500] to <öffentliche ip des VPS>[500] (2108 bytes)
Jan 26 14:35:01 VPS charon: 09[ENC] parsed QUICK_MODE request 895277431 [ HASH SA No KE ID ID ]
Jan 26 14:35:01 VPS charon: 09[ENC] generating QUICK_MODE response 895277431 [ HASH SA No KE ID ID ]
Jan 26 14:35:01 VPS charon: 09[NET] sending packet: from <öffentliche ip des VPS>[500] to <öffentliche ip fritzbox>[500] (316 bytes)
Jan 26 14:35:02 VPS charon: 10[NET] received packet: from <öffentliche ip fritzbox>[500] to <öffentliche ip des VPS>[500] (60 bytes)
Jan 26 14:35:02 VPS charon: 10[ENC] parsed QUICK_MODE request 895277431 [ HASH ]
Jan 26 14:35:02 VPS charon: 10[IKE] CHILD_SA fritzbox{1} established with SPIs c2906947_i b4654228_o and TS 192.168.0.0/24 === 192.168.2.0/24
Jan 26 14:35:02 VPS charon: 12[NET] received packet: from <öffentliche ip fritzbox>[500] to <öffentliche ip des VPS>[500] (92 bytes)
Jan 26 14:35:02 VPS charon: 12[ENC] parsed INFORMATIONAL_V1 request 96996794 [ HASH N(DPD) ]
Jan 26 14:35:02 VPS charon: 12[ENC] generating INFORMATIONAL_V1 request 3730443924 [ HASH N(DPD_ACK) ]
Jan 26 14:35:02 VPS charon: 12[NET] sending packet: from <öffentliche ip des VPS>[500] to <öffentliche ip fritzbox>[500] (92 bytes)

Server: /etc/ipsec.conf

# https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

# Add connections here.
conn fritzbox
        aggressive=yes
        left=<öffentliche IP des VPS>
        leftsubnet=192.168.0.0/24
        #
        ike=aes256-sha-modp1024
        esp=aes256-sha1-modp1024
        #
        right=<dyndns hostname der fritzbox>
        rightid=@<dyndns hostname der fritzbox>
        rightsubnet=192.168.2.0/24
        #
        ikelifetime=4h
        keylife=1h
        #
        authby=secret
        auto=add

Server: /etc/ipsec.secrets

%any %any : PSK "<eigener PSK>"

Fritzbox: /var/flash/vpn.cfg

                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "<öffentliche ip des VPS>";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <öffentliche IP des VPS>;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 192.168.0.1;
                localid {
                        fqdn = "<dyndns hostname der fritzbox>";
                }
                remoteid {
                        ipaddr = <öffentliche ip des VPS>;
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<eigener PSK>";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.2.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.0.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.0.0 255.255.255.0";

Mit ist das Sicherheitsrisiko bzgl. dem aggressive-mode bewusst und wird bis zur Problemlösung ersteinmal hingenommen.

Server Kommando: ipsec statusall

Status of IKE charon daemon (weakSwan 5.1.2, Linux 3.16.0-29-generic, x86_64):
  uptime: 8 minutes, since Jan 26 14:02:30 2015
  malloc: sbrk 2433024, mmap 0, used 362400, free 2070624
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints pkcs1 pkcs7 pkcs8 pkcs12 pem openssl xcbc cmac hmac ctr ccm gcm attr kernel-netlink resolve socket-default stroke updown eap-identity xauth-generic addrblock
Listening IP addresses:
  <öffentlich ip des VPS>
Connections:
    fritzbox:  <öffentliche IP des VPS>...<dyndns hostname der fritzbox>  IKEv1/2
    fritzbox:   local:  [<öffentliche IP des VPS>] uses pre-shared key authentication
    fritzbox:   remote: [<dyndns hostname der fritzbox>] uses pre-shared key authentication
    fritzbox:   child:  192.168.0.0/24 === 192.168.2.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
    fritzbox[1]: ESTABLISHED 8 minutes ago, <öffentliche IP des VPS>[<öffentliche IP des VPS>]...<öffentliche ip fritzbox>[<dyndns hostname der fritzbox>]
    fritzbox[1]: IKEv1 SPIs: 3bac5513ed8004e6_i 959a25fca2ec0c68_r*, pre-shared key reauthentication in 3 hours
    fritzbox[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    fritzbox{1}:  INSTALLED, TUNNEL, ESP SPIs: c5e0e51c_i fd34ae19_o
    fritzbox{1}:  AES_CBC_256/HMAC_SHA1_96, 128 bytes_i (1 pkt, 524s ago), 0 bytes_o, rekeying in 38 minutes
    fritzbox{1}:   192.168.0.0/24 === 192.168.2.0/24

Wenn ich nun vom Server die interne IP der Fritzbox pinge (192.168.2.1) gibt es keine Antwort. Auch andersrum vom lokalen Netz hinter der Fritzbox in Richtung Server bleibt eine Antwort aus.

Server: tcpdump -nni eth0 esp or icmp
Es fehlt anscheinend die Antwort zurück...

14:18:38.745642 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ESP(spi=0xc5e0e51c,seq=0xbc), length 132
14:18:38.745642 IP 192.168.2.4 > 192.168.0.1: ICMP echo request, id 19620, seq 1, length 64
14:18:39.752964 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ESP(spi=0xc5e0e51c,seq=0xbd), length 132
14:18:39.752964 IP 192.168.2.4 > 192.168.0.1: ICMP echo request, id 19620, seq 2, length 64
14:18:40.763950 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ESP(spi=0xc5e0e51c,seq=0xbe), length 132
14:18:40.763950 IP 192.168.2.4 > 192.168.0.1: ICMP echo request, id 19620, seq 3, length 64

Pinge ich vom VPS einen Host im LAN der Fritzbox kommt dort nichteinmal ein ICMP request an.
Schaue ich mir mit tcpdump auf dem VPS an, was passiert:

14:21:33.362499 IP <öffentliche IP des VPS> > <öffentliche ip fritzbox>: ESP(spi=0x3136f45e,seq=0x6), length 132
14:21:33.396429 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ICMP host <öffentliche ip fritzbox> unreachable - admin prohibited filter, length 36
14:21:34.363757 IP <öffentliche IP des VPS> > <öffentliche ip fritzbox>: ESP(spi=0x3136f45e,seq=0x7), length 132
14:21:34.397694 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ICMP host <öffentliche ip fritzbox> unreachable - admin prohibited filter, length 36
14:21:35.364965 IP <öffentliche IP des VPS> > <öffentliche ip fritzbox>: ESP(spi=0x3136f45e,seq=0x8), length 132
14:21:35.399465 IP <öffentliche ip fritzbox> > <öffentliche IP des VPS>: ICMP host <öffentliche ip fritzbox> unreachable - admin prohibited filter, length 36

Hoffe, dass ich genügend Informationen geben konnte dass mir ggf. jemand einen Tipp geben kann, was hier falsch läuft.

Viele Grüße
Sascha

 

[PeterPawn]

Überprüfe mal bitte noch auf dem VPS (die sind halt immer etwas kritischer, vor allem wenn sie mit Virtuozzo oder OpenVZ - also mit einem Basis-Container - arbeiten und man keine volle Kontrolle über den IP-Stack kriegt), ob da tatsächlich vom strongSwan auch die Transform-Sets richtig initialisiert werden.

ip xfrm state
ip xfrm policy

Der strongSwan nimmt ja die IPSec-Encapsulation nicht selbst vor, das erledigen die Transform-Tables des Linux-Kernels ... deshalb braucht es auch den passenden iptables-Eintrag für eine IPSec-Verbindung. Mit diesem Eintrag werden die Transformationen erst aktiviert - der Verkehr wird praktisch über diese zusätzlichen "Manipulationen" umgeleitet.

Wenn ich nun vom Server die interne IP der Fritzbox pinge (192.168.2.1) gibt es keine Antwort. Auch andersrum vom lokalen Netz hinter der Fritzbox in Richtung Server bleibt eine Antwort aus.
Server: tcpdump -nni eth0 esp or icmp
Es fehlt anscheinend die Antwort zurück...

Das darunter stehende Protokoll enthält ja die Requests der FRITZ!Box und es fehlen die Antworten des Servers. Daher würde ich erst einmal darauf tippen, daß da kein ICMP-Request von 192.168.2.4 erlaubt ist und die iptables - die greifen erst nach dem tcpdump - das abblocken. Ansonsten müßte wenigstens das "echo reply" von 192.168.0.1 zu sehen sein. Wenn das Protokoll tatsächlich von Server stammt, ist das Entschlüsseln des ESP-Pakets ja offenbar erfolgreich gewesen, denn der enthaltene Ping-Request ist ja sichtbar.

Es kann also nicht nur an der fehlenden Verschlüsselung auf dem Rückweg liegen, auch wenn da offenbar immer noch etwas nicht stimmt, denn die Antwort der FRITZ!Box paßt auch nicht. Da würde ich eher ein Mißverständnis bei den verwendeten Ports vermuten, wobei es natürlich auch sein kann, daß der avmike bzw. die IPSec-Implementierung mit "host unreachable" antwortet ... das ist aber eher unwahrscheinlich.

Um da etwas wirklich zu sehen, müßtest Du mit "-vv" (und ggf. mit "-X", wenn der Paketinhalt auch noch interessant wäre) die Protokollierung etwas ausführlicher gestalten. Warum die FRITZ!Box bei Paketen mit ESP-Inhalt sich ihrerseits sperrt, ist tatsächlich merkwürdig, wenn sie nicht anstelle von UDP/500 + ESP lieber nur UDP/4500 (für NAT-T) machen will, dann erwartet sie natürlich keinen Traffic in ESP-Paketen (was das reject erklären würde). Das würde ich zwar aus dem strongSwan-Syslog auch nicht herauslesen, aber ein Blick in die Datei /var/tmp/ike.log der FRITZ!Box gibt die definitive Auskunft.

Und bitte auch noch eine halbwegs komplette "iptables-save"-Ausgabe, wenn Du selbst dort nichts finden solltest (ist halt blöd, wenn dann Deine Firewall-Konfiguration offengelegt wird, aber erstens ist auch da eine sichere Konfiguration nicht gefährdet, wenn jemand anderes sie kennt und zweitens braucht es schon wirklich die richtige Reihenfolge der Regeln, wenn man etwas nachvollziehen will im Trockentest) - und beim Maskieren ist es für den Leser leichter, wenn Du einfach die Adresse des VPS durch 1.1.1.1 und die der Box durch 2.2.2.2 o.ä. ersetzt, dann verwirren die spitzen Klammer rundherum nicht. Eine einmalige Erklärung als "Legende" reicht dann auch aus, um die Bedeutung zu unterscheiden und das Format bleibt sichtbar erhalten.

 

[realriot]

Hi,

danke für Dein Feedback. Beim Schreiben meiner Frage habe ich mir einige Zeit gelassen und im Hintergrund unbeaufsichtigt meine letzte Konfig laufen lassen. Nach einigen Minuten fing die Verbindung auf einmal an zu laufen... (seltsam???)

Da fiel mir ein, dass ich über ein derartiges Problem schonmal gelesen habe. Und zwar im Zusammen mit dem "rekeying". Ich kann durch die Konfiguration der "margintime" ein schnelles rekeying bewirken (zum Testen). Es lässt sich quaso reproduzieren, dass nach diesem Prozess die Verbindung steht. Untereinander ist jegliche Kommunikation möglich.

Nur was mache ich falsch, dass erst der "rekeying" Prozess greifen muss damit die Verbindung läuft?

VG
Sascha

 

[realriot]

1.1.1.1 = VPS Server mit strongSwan (öffentliche IP)
2.2.2.2 = Fritzbox (öffentliche IP)

Auf dem Testsystem habe ich die FW komplett disabled:

# Generated by iptables-save v1.4.21 on Mon Jan 26 16:41:47 2015
*nat
:PREROUTING ACCEPT [5:446]
:INPUT ACCEPT [5:446]
:OUTPUT ACCEPT [3:204]
:POSTROUTING ACCEPT [3:204]
COMMIT
# Completed on Mon Jan 26 16:41:47 2015
# Generated by iptables-save v1.4.21 on Mon Jan 26 16:41:47 2015
*mangle
:PREROUTING ACCEPT [667:273461]
:INPUT ACCEPT [667:273461]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [350:40897]
:POSTROUTING ACCEPT [350:40897]
COMMIT
# Completed on Mon Jan 26 16:41:47 2015
# Generated by iptables-save v1.4.21 on Mon Jan 26 16:41:47 2015
*raw
:PREROUTING ACCEPT [664:271595]
:OUTPUT ACCEPT [354:41793]
COMMIT
# Completed on Mon Jan 26 16:41:47 2015
# Generated by iptables-save v1.4.21 on Mon Jan 26 16:41:47 2015
*filter
:INPUT ACCEPT [664:271595]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [356:42185]
COMMIT
# Completed on Mon Jan 26 16:41:47 2015

Fritzbox: ike.log

2015-01-26 16:39:27 avmike:mainmode 1.1.1.1: selected lifetime: 3600 sec(no notify)
2015-01-26 16:39:27 avmike:mainmode 1.1.1.1: add SA 60
2015-01-26 16:39:27 avmike:1.1.1.1 remote peer supported XAUTH
2015-01-26 16:39:27 avmike:1.1.1.1 remote peer supported DPD
2015-01-26 16:39:27 avmike:1.1.1.1 remote peer supported NAT-T RFC 3947
2015-01-26 16:39:27 avmike:1.1.1.1: sending embedded inital contact message (0,1.1.1.1,1.1.1.1)
2015-01-26 16:39:27 avmike:1.1.1.1: Phase 1 ready
2015-01-26 16:39:27 avmike:1.1.1.1: start waiting connections
2015-01-26 16:39:27 avmike:1.1.1.1: Phase 2 starting (start waiting)
2015-01-26 16:39:27 avmike:1.1.1.1: Phase 2 ready
2015-01-26 16:39:27 avmike:< cb_sa_created(name=1.1.1.1,id=575,...,flags=0x00002101)
2015-01-26 16:39:27 avmike:1.1.1.1 stop_vpn_keepalive to 192.168.0.1
2015-01-26 16:39:27 avmike:1.1.1.1 start_keepalive_timer 3540 sec
2015-01-26 16:39:27 avmike:1.1.1.1: start waiting connections
2015-01-26 16:39:27 avmike:1.1.1.1: NO waiting connections

ip xfrm state

src 1.1.1.1 dst 2.2.2.2
        proto esp spi 0x1bf2abc0 reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xdaf404101c37ba1fc7a6fd7ff80598c1a12c5e89 96
        enc cbc(aes) 0x92fbe80b334004f25d13f12c251423665bbb784fda2567cd219df9ddc59c369a
src 2.2.2.2 dst 1.1.1.1
        proto esp spi 0xc384ba2b reqid 1 mode tunnel
        replay-window 32 flag af-unspec
        auth-trunc hmac(sha1) 0xe83e00a0628377c2249eba896ac2b2a13fefcd8e 96
        enc cbc(aes) 0xd97438e6ace382af8101ec91c471c69587b05678c03fd55444c76403a5542859

ip xfrm policy

src 192.168.2.0/24 dst 192.168.0.0/24
        dir fwd priority 1859
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 192.168.0.0/24
        dir in priority 1859
        tmpl src 2.2.2.2 dst 1.1.1.1
                proto esp reqid 1 mode tunnel
src 192.168.0.0/24 dst 192.168.2.0/24
        dir out priority 1859
        tmpl src 1.1.1.1 dst 2.2.2.2
                proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0

Ist da ggf. eine Phase noch nicht "komplett"? Weil wie gesagt kann ich auf dem VPS ja schon pings sehen, aber nach einem rekey funktioniert das dann komplett...

 

[realriot]

Netter Hinweis im strongSwan Wiki: https://wiki.strongswan.org/issues/661#note-13

esp=aes192-sha1-modp1024!

Damit bekomme ich sofort eine Verbindung hergestellt. Frage: Warum? aes256 passt doch auch zu den der Fritzbox angegebenen proposals, oder?

Fritzbox received proposals:

ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, IPCOMP:, ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ, ESP:DES_CBC/HMAC_MD5_96/MODP_1024/NO_EXT_SEQ

 

[Basti.G]

Oh Mann ... ein einziger Post und du löst damit gleich mein 3 Jahre altes Problem!
Wieso die FB ein aes256 in der Phase 2 anbietet aber dann nicht akzeptiert, kapier ich auch nicht.

Mit exakt den gleichen Einstellungen lässt sich bei mir übrigens Phase 1 auf Main Mode (phase1_mode_idp) umstellen und der weakSwan wieder zum strongSwan umkonfigurieren.

Damit erst mal genug, wo ist jetzt hier der "Danke" Button?

 

[realriot]

Ich bin von einem Netcup vServer auf einen physikalischen Server bei Hetzner umgezogen. Gleiche Konfiguration, gleiches OS, kein Transfer möglich.

"ip xfrm state" zeigt mir nichts an....
Auf der FRITZ!Box wird mir ein IKE Fehler 2027 angezeigt.

Keine Ahnung warum, es dieses Mal nicht funktioniert.