VPN, 7390, 7270, 7170, StrongSwan

wobei der erste Punkt (Host<->LAN mit XAuth) eigentlich nicht interessant ist in Deinem Fall.

Da es ja nun mal nicht geht, dass sich meine Fritte mit dem Vserver verbindet, habe ich nun doch den umgekehrten Weg versucht.
Nach "aptitude install vpnc" habe ich noch eine /etc/vpnc/fritzbox.conf erstellt:
Code:
IPSec gateway meindyndns.selfhost.bz

IKE DH Group dh2
#Perfect Forward Secrecy nopfs

IPSec ID meinname
IPSec secret geheim

NAT Traversal Mode force-natt

Xauth username meinname
Xauth password geheim
Code:
vpncfg {			// Diese Datei in die fritzbox importieren
        connections {
                enabled = yes;
                editable = yes;
                conn_type = conntype_user;
                name = "meinname";
                boxuser_id = 10;
                always_renew = yes;
                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.176.201;
                keepalive_ip = 0.0.0.0;
                remoteid {
                        key_id = "meinname";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "meinname";
                        passwd = "geheim";
                }
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.176.201;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip 0.0.0.0 0.0.0.0 192.168.176.201 255.255.255.255";
        }
        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";
}

// EOF

Verbindung wird dann erfolgreich hergestellt, aber irgendwie ist die Verbindung dann zu gut: Internettraffic vom Vserver wird komplett über die Fritzbox geleitet und von außen komme ich an meinen Vserver nicht mehr ran, nur per rescue-console. Eigentlich wollte ich bloß, dass der Vserver die Fritte erreicht und umgekehrt.

Nachtrag: Funktioniert wie ich will, wenn ich die Datei /etc/vpnc/vpnc-script lösche und "Script /etc/vpnc/fritzbox-script" in die fritzbox.conf einfüge.
Code:
#!/bin/sh
# /etc/vpnc/fritzbox-script
IPROUTE=/sbin/ip

case "$reason" in
  pre-init)
    ;;
  connect)
    INTERNAL_IP4_PREFIX=$(echo $INTERNAL_IP4_ADDRESS | sed -e's/\.[0-9]\+$//')
    $IPROUTE link set dev "$TUNDEV" up mtu 1024
    $IPROUTE addr add "$INTERNAL_IP4_ADDRESS/255.255.255.0" peer "$INTERNAL_IP4_ADDRESS" dev "$TUNDEV"
    $IPROUTE route replace "$INTERNAL_IP4_PREFIX.0/255.255.255.0" dev "$TUNDEV"
    $IPROUTE route flush cache
    ;;
  disconnect)
    $IPROUTE link set dev "$TUNDEV" down
    ;;
  *)
    echo "unknown reason '$reason'. Maybe vpnc-script is out of date" 1>&2
    exit 1
    ;;
esac
exit 0

Auf diesem Wege mehrere Verbindungen zu verschiedenen Fritzboxen aufzubauen, ist aber schwierig. Man müsste mehrere vpnc-instanzen mit verschiedenen Ports laufen lassen.

Nachtrag2:
Unter der Annahme, dass die von StrongSwan benötigten Kernelmodule in meinem Vserver fehlen, habe ich mich gefragt, warum ich ja nun mit vpnc einen VPN-Tunnel herstellen kann, mit StrongSwan jedoch nicht.
Beim intakten Tunnel mit vpnc ist mir (mit ifconfig) aufgefallen, dass ein tun-Device erstellt wird. Der erste Treffer in google mit "strongswan tun device" bringt einen auf diese Seite. Auch wenn mein Englisch nicht perfekt ist, habe ich den Inhalt der Seite so verstanden, dass StrongSwan auch ohne die Kernel-Module arbeiten kann, wenn man ihn vorher mit "./configure --enable-kernel-libipsec && make" kompiliert.
Und tatsächlich: die mit aptitude installierte Version hat das Plugin nicht. Meine gerade kompilierte Version (von dort ) dagegen schon.
Code:
root@psychomantis:~# ipsec start
Starting strongSwan 5.1.3 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!
root@psychomantis:~#
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-042stab084.3, i686):
  uptime: 2 seconds, since Jun 30 13:35:49 2014
  malloc: sbrk 503808, mmap 0, used 121208, free 382600
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey
sshkey pem fips-prf gmp xcbc cmac hmac attr [color=red]kernel-libipsec[/color] kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  84.200.w.x
  84.200.y.z
Connections:
      berlin:  84.200.w.x...meindyndns.selfhost.bz  IKEv1
      berlin:   local:  [84.200.w.x] uses pre-shared key authentication
      berlin:   remote: [meindyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.1.0/24 === 192.168.176.0/24 TUNNEL
Security Associations (0 up, 0 connecting):
  none
root@psychomantis:~#
Nach ipsec start taucht unter ifconfig sogar tatsächlich ein zusätzliches device auf:
Code:
root@psychomantis:~# ifconfig
ipsec0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
...
Der Verbindungsaufbaut gelingt zwar immer noch nicht, aber die Fehlermeldung sieht jetzt anders aus.
Code:
root@psychomantis:~# ipsec up berlin
initiating Main Mode IKE_SA berlin[1] to 92.74.g.h
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from 84.200.w.x[500] to 92.74.g.h[500] (220 bytes)
received packet: from 92.74.g.h[500] to 84.200.w.x[500] (148 bytes)
parsed ID_PROT response 0 [ SA N((24576)) V V ]
received XAuth vendor ID
received DPD vendor ID
generating ID_PROT request 0 [ KE No ]
sending packet: from 84.200.w.x[500] to 92.74.g.h[500] (196 bytes)
received packet: from 92.74.g.h[500] to 84.200.w.x[500] (180 bytes)
parsed ID_PROT response 0 [ KE No ]
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 84.200.w.x[500] to 92.74.g.h[500] (68 bytes)
received packet: from 92.74.g.h[500] to 84.200.w.x[500] (108 bytes)
parsed ID_PROT response 0 [ ID HASH N(INITIAL_CONTACT) ]
IKE_SA berlin[1] established between 84.200.w.x[84.200.w.x]...92.74.g.h[meindyndns.selfhost.bz]
scheduling reauthentication in 9798s
maximum IKE_SA lifetime 10338s
generating QUICK_MODE request 3252815784 [ HASH SA No ID ID ]
sending packet: from 84.200.w.x[500] to 92.74.g.h[500] (228 bytes)
received packet: from 92.74.g.h[500] to 84.200.w.x[500] (68 bytes)
parsed INFORMATIONAL_V1 request 917216112 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'berlin' failed
root@psychomantis:~#
Code:
#gestern endete diese Fehlermeldung so (zum Vergleich von oben hier eingefügt)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA berlin[1] established between 84.200.111.222[84.200.111.222]...188.105.24.8[meindyndns.selfhost.bz]
scheduling reauthentication in 9733s
maximum IKE_SA lifetime 10273s
allocating SPI failed: Invalid argument (22)
unable to get SPI for reqid {1}
allocating SPI from kernel failed
establishing connection 'berlin' failed
root@psychomantis:~#
 
Zuletzt bearbeitet:
parsed INFORMATIONAL_V1 request 917216112 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
NO_PROPOSAL_CHOSEN => kein Vorschlag ausgewählt, kein Angebot annehmbar

Die Gegenstelle kann in den (für Phase 2) angebotenen Verschlüsselungsverfahren (ist eine vereinfachte Zusammenfassung mehrerer Parameter) keines finden, was sie - ausgehend von ihrer eigenen Konfiguration - verwenden darf oder kennt.
Überprüfe phase2ss in der vpn.cfg auf der Box und - wo auch immer - die auf dem vServer konfigurierten Verfahren für Phase2.

Edit: Ich habe jetzt mal die oben verlinkte Anleitung bei strongSwan überflogen und dabei zumindest verstanden, daß mit diesem libipsec-Plugin der IPSec-Stack des Systems umgangen wird (also kein 'ip xfrm irgendwas') und die komplette Ver-/Entschlüsselung nunmehr im "Userland" läuft. Solange das ein halbwegs performanter vServer ist, fällt es vielleicht nicht weiter auf oder es ist in Deinem Fall auch egal, aber die ständigen Umschaltungen zwischen Kernelmode (beim Senden/Empfangen der "realen" Pakete) und Usermode (bei der weiteren Verarbeitung) dürfte nicht förderlich für den zu erzielenden VPN-Durchsatz sein.

Und diesen Satz "The resulting ESP packets will be sent over the UDP sockets the daemon uses for IKE traffic, which is why the plugin currently only works with UDP encapsulation (NAT-T) enabled." hast Du hoffentlich auch gelesen ? Dein Protokoll läßt jedenfalls nicht auf NAT-T schließen ... aber dazu habe ich schon vorher in diesem Thread alles gesagt, was meinerseits zu sagen war.
 
Zuletzt bearbeitet:
Ja, das mit NAT-T habe ich gelesen, aber vergessen in vpn.cfg einzutragen.
Trage ich da "use_nat_t = yes;" ein, dann kommt die Verbindung nicht zustande. Ändere ich beides auf aggressive, dann klappt es fast.
Das mit der höheren CPU-Last wegen "Userland" ist nebensächlich: über diesen Tunnel wird nur etwas VoIP-Traffic durchgehen und keine MB/s.
Code:
                ...
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = yes;
                ...
                phase2ss = "esp-all-all/ah-all/comp-all/no-pfs";
                ...
Code:
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	charondebug=ike

conn berlin
	aggressive=yes
	keyexchange=ikev1
	left=84.200.w.x
	leftsubnet=192.168.1.0/24
	ike=des-aes-sha1-sha2
	esp=aes-des-sha1-sha2
        right=meindyndns.selfhost.bz
	[email protected]
	rightsubnet=192.168.176.0/24
	authby=psk
        auto=route
Code:
root@psychomantis:~# ipsec up berlin
initiating Aggressive Mode IKE_SA berlin[2] to 92.74.g.h
generating AGGRESSIVE request 0 [ SA KE No ID V V V V ]
sending packet: from 84.200.w.x[500] to 92.74.g.h[500] (332 bytes)
received packet: from 92.74.g.h[500] to 84.200.w.x[500] (530 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH N((24576)) V V V V V NAT-D NAT-D NAT-D NAT-D NAT-D ]
received XAuth vendor ID
received DPD vendor ID
received NAT-T (RFC 3947) vendor ID
received draft-ietf-ipsec-nat-t-ike-03 vendor ID
received unknown vendor ID: a2:26:6f:c1:24:40:0f:56:34:ff:37:db:2b:78:c4:1h
local host is behind NAT, sending keep alives
remote host is behind NAT
IKE_SA berlin[2] established between 84.200.w.x[84.200.w.x]...92.74.g.h[meindyndns.selfhost.bz]
scheduling reauthentication in 10135s
maximum IKE_SA lifetime 10675s
generating AGGRESSIVE request 0 [ NAT-D NAT-D HASH ]
sending packet: from 84.200.w.x[4500] to 92.74.g.h[4500] (92 bytes)
generating QUICK_MODE request 2708273787 [ HASH SA No ID ID ]
sending packet: from 84.200.w.x[4500] to 92.74.g.h[4500] (172 bytes)
received packet: from 92.74.g.h[4500] to 84.200.w.x[4500] (76 bytes)
queueing TRANSACTION request as tasks still active
received packet: from 92.74.g.h[4500] to 84.200.w.x[4500] (156 bytes)
parsed QUICK_MODE response 2708273787 [ HASH SA No ID ID ]
error installing route with policy 192.168.1.0/24 === 192.168.176.0/24 out
error installing route with policy 192.168.1.0/24 === 192.168.176.0/24 out
unable to install IPsec policies (SPD) in kernel
generating INFORMATIONAL_V1 request 2727492940 [ HASH N(NO_PROP) ]
sending packet: from 84.200.w.x[4500] to 92.74.g.h[4500] (68 bytes)
establishing connection 'berlin' failed
root@psychomantis:~#
 
Zuletzt bearbeitet:
Ja, das mit NAT-T habe ich gelesen, aber vergessen in vpn.cfg einzutragen.
Teilweise falsche Baustelle ... wobei Du da in den Aussagen etwas schwankst.

Trage ich da "use_nat_t = yes;" ein, dann kommt die Verbindung nicht zustande.
Wenn eine IPSec-Verbindung NAT-T (NAT-Traversal) benutzt, wird für die Verbindung der Gegenstellen nicht UDP auf Port 500 und ESP verwendet, sondern nur noch UDP auf Port 4500. Ergo, wenn nur eine Seite NAT-T annimmt, werden sie schwerlich miteinander reden können.
Ändere ich beides auf aggressive, dann klappt es fast.
Ich muß mir mal - nicht böse sein - etwas Luft machen. Sollte es wirklich einen Erfolg bringen, wenn Du ständig wieder an anderen Ecken eine Einstellung änderst, wirst Du vielleicht einen temporären Gewinn daraus ziehen, aber beim nächsten Mal genauso herumprobieren, wenn Du die Ursache nicht kennst, warum es auf einmal doch funktionierte. Und wenn ich mit "herumprobieren" falsch liege, würde mich wirklich mal der Grund für die Entscheidung zum Wechsel auf "aggressive mode" interessieren ... Phase1 klappt doch und damit gibt es primär keinen Grund, an Phase1 erst einmal etwas zu drehen - jedenfalls solange nicht, bis man einen Grund dafür benennen kann.

Das mit der höheren CPU-Last wegen "Userland" ist nebensächlich: über diesen Tunnel wird nur etwas VoIP-Traffic durchgehen und keine MB/s.
Dachte ich mir schon, das mit dem Asterisk stand ja auch mal irgendwo ...

So, zurück zur Konfiguration:
1. Du mußt also beim strongSwan die Einstellung finden, mit der er der Gegenstelle mitteilt, daß er auch NAT-T beherrscht.
2. Solange Du nicht "echte" dynamische Gegenstellen verbinden willst (siehe Erläuterung zu DynDNS und "main mode" vs. "aggressive mode" einige Posts vorher), spricht nichts gegen den "main mode" und Du solltest Dich auf eine Konfigurationsvariante festlegen, sonst kann Dir niemand mehr folgen.
3. Das Protokoll des strongSwan spricht eigentlich dafür, daß Du beim Umkonfigurieren auch noch etwas anderes verstellt hast. Im Widerspruch zur Dokumentation auf der strongSwan-Seite zur libipsec wird hier in Phase2 wieder versucht, die Kernel-Mechanismen des IPSec-Stacks (ip xfrm policy und ip xfrm state) anzusprechen:
Code:
error installing route with policy 192.168.1.0/24 === 192.168.176.0/24 out
error installing route with policy 192.168.1.0/24 === 192.168.176.0/24 out
unable to install IPsec policies (SPD) in kernel
Wenn ich die Dokumentation bei strongSwan richtig verstanden habe, soll das aber mit TUN/TAP-Device und "normaler" Route arbeiten, wenn man das libipsec-Plugin benutzt. Da dann auch die Ver- und Entschlüsselung im Userland laufen soll, sehe ich den Zusammenhang zur "Security Policy Database" (SPD) des Kernels nicht so richtig.

Irgendwas stimmt hier also meiner Meinung nach nicht ...

Edit: Ich wäre Dir auch wirklich dankbar (genauer, ich mache die weitere Beschäftigung mit dem Thema für mich davon abhängig), wenn Du die erwähnten Protokolle des avmike als Anhang dazu packen würdest. IPSec ist eine bidirektionale Verbindung und die Probleme können an beiden Enden auftreten. Bestes Beispiel ist der letzte Roundtrip ... das vorletzte Problem lag im Zusammenspiel beider Seiten, das letzte dürfte ziemlich sicher in einer Fehlkonfiguration auf dem Server liegen; das Ergebnis ist dasselbe, die Ursachen - vermutlich - nicht.
 
Zuletzt bearbeitet:
Bin mir nicht sicher, ob ich weiter gekommen bin.
StrongSwan mit libipsec zu kompilieren scheint auf jeden Fall was zu bringen. Kompiliere ich es ohne, kommt die Verbindung nicht zustande.
Mit kernel-libipsec sieht mir das hier nach einer abgeschlossenen phase2.
Code:
2014-07-01 23:47:13 avmike:< add(appl=dsld,cname=V-Server,localip=188.105.g.h, remoteip=84.200.w.x, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/no-pfs p1mode=2 keepalive_ip=0.0.0.0 flags=0x48001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2014-07-01 23:47:13 avmike:new neighbour V-Server:  nat_t
2014-07-01 23:47:13 avmike:mainmode V-Server: selected lifetime: 3600 sec(no notify)
2014-07-01 23:47:13 avmike:V-Server remote peer supported XAUTH
2014-07-01 23:47:13 avmike:V-Server remote peer supported DPD
2014-07-01 23:47:13 avmike:V-Server remote peer supported NAT-T RFC 3947
2014-07-01 23:47:13 avmike:mainmode V-Server: add SA 1
2014-07-01 23:47:13 avmike:V-Server: switching to NAT-T (Initiator)
2014-07-01 23:47:13 avmike:V-Server: Warning: source changed from 84.200.w.x:500 to 84.200.w.x:4500
2014-07-01 23:47:13 avmike:V-Server: Phase 1 ready
2014-07-01 23:47:13 avmike:V-Server: local is behind a nat
2014-07-01 23:47:13 avmike:V-Server: remote is behind a nat
2014-07-01 23:47:13 avmike:V-Server: start waiting connections
2014-07-01 23:47:13 avmike:V-Server: Phase 2 starting (start waiting)
2014-07-01 23:47:13 avmike:V-Server
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2014-07-01 23:47:13 avmike:V-Server: Phase 2 ready
2014-07-01 23:47:13 avmike:< cb_sa_created(name=V-Server,id=1,...,flags=0x00032101)
2014-07-01 23:47:13 avmike:V-Server: start waiting connections
2014-07-01 23:47:13 avmike:V-Server: NO waiting connections
2014-07-01 23:47:14 avmike:V-Server
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2014-07-01 23:47:23 avmike:>>>4500 nat-t-keepalive[84.200.w.x:4500]
Code:
root@psychomantis:~# ipsec start
Starting strongSwan 5.1.3 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-042stab084.3, i686):
  uptime: 57 seconds, since Jul 01 23:46:36 2014
  malloc: sbrk 524288, mmap 0, used 142648, free 381640
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 5
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-libipsec kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  84.200.w.x
  84.200.y.z
Connections:
      berlin:  84.200.w.x...%any  IKEv1/2
      berlin:   local:  [84.200.w.x] uses pre-shared key authentication
      berlin:   remote: [meindyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.1.0/24 === 192.168.176.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      berlin[1]: ESTABLISHED 20 seconds ago, 84.200.w.x[84.200.w.x]...188.105.g.h[meindyndns.selfhost.bz]
      berlin[1]: IKEv1 SPIs: 8d8cd04dcbecf3ad_i 4d1f2ad8d7328237_r*, pre-shared key reauthentication in 2 hours
      berlin[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-042stab084.3, i686):
  uptime: 10 minutes, since Jul 01 23:46:37 2014
  malloc: sbrk 524288, mmap 0, used 142528, free 381760
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-libipsec kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  84.200.w.x
  84.200.y.z
Connections:
      berlin:  84.200.w.x...%any  IKEv1/2
      berlin:   local:  [84.200.w.x] uses pre-shared key authentication
      berlin:   remote: [meindyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.1.0/24 === 192.168.176.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      berlin[1]: ESTABLISHED 9 minutes ago, 84.200.w.x[84.200.w.x]...188.105.247.229[meindyndns.selfhost.bz]
      berlin[1]: IKEv1 SPIs: 8d8cd04dcbecf3ad_i 4d1f2ad8d7328237_r*, pre-shared key reauthentication in 2 hours
      berlin[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
root@psychomantis:~# ifconfig
ipsec0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
...
Code:
vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "V-Server";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 84.200.w.x;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "meindyndns.selfhost.bz";
                }
                remoteid {
                        ipaddr = 84.200.w.x;
                }
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheim";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no; // bei yes wird kein Tunnel aufgebaut
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.176.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip any 192.168.1.0 255.255.255.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";
}


// EOF
Code:
# /etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	charondebug=ike

conn berlin
	left=84.200.w.x
	leftsubnet=192.168.1.0/24
	ike=des-aes-sha1-sha2
	esp=aes-des-sha1-sha2
	[email protected]
	rightsubnet=192.168.176.0/24
	authby=psk
        auto=route

Tja. Der Tunnel ist also nun stabil aufgebaut, aber ich habe noch kein einzigen Byte durch diesen durchbekommen.
Wie ernst meint es avmike mit der fehlerhaften Paketlänge?
Den Tunnel kann in dieser Konfiguration nur die Fritzbox aufbauen (Vserver nicht), aber das passt schon so.
Bin ich hier echt der erste Mensch, der versucht StrongSwan auf einem Vserver laufen zu lassen?
Kann mir eventuell jemand posten, was "route" liefert?
 
Zuletzt bearbeitet:
Schaut so aus, als wäre ich etwas weiter gekommen. Konfiguration wie im Post über diesem, mit einzigem Unterschied: Zeile "leftsourceip=%config" hinzugefügt.
Code:
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-042stab084.3, i686):
  uptime: 12 minutes, since Jul 04 00:51:10 2014
  malloc: sbrk 524288, mmap 0, used 157096, free 367192
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 8
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey 
sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-libipsec kernel-netlink resolve socket-default stroke updown xauth-generic
Listening IP addresses:
  84.200.w.x
  84.200.y.z
Connections:
      berlin:  84.200.w.x...meindyndns.selfhost.bz,0.0.0.0/0,::/0  IKEv1
      berlin:   local:  [84.200.w.x] uses pre-shared key authentication
      berlin:   remote: [meindyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.1.0/24 === 192.168.176.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      berlin[2]: ESTABLISHED 8 minutes ago, 84.200.w.x[84.200.w.x]...188.99.g.h[meindyndns.selfhost.bz]
      berlin[2]: IKEv1 SPIs: 3861dc639e928674_i 6e627331c0fa3951_r*, pre-shared key reauthentication in 45 minutes
      berlin[2]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      berlin{3}:  INSTALLED, TUNNEL, ESP in UDP SPIs: e1c8171a_i 6611c90c_o
      berlin{3}:  AES_CBC_256/HMAC_SHA1_96, 1428 bytes_i (17 pkts, 66s ago), 2656 bytes_o (35 pkts, 1s ago), rekeying in 7 minutes
      berlin{3}:   192.168.1.0/24 === 192.168.176.0/24
root@psychomantis:~#
Code:
root@psychomantis:~# ifconfig
ipsec0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.1.1  P-t-P:192.168.1.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1
          RX packets:20 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1680 (1.6 KB)  TX bytes:4440 (4.4 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
...
Wenn ich pinge, ändert sich die Zahl von RX bytes und TX bytes, aber Antwort kommt keine zurück.
Irgendwie glaube ich, es fehlt nur noch irgendeine Kleinigkeit, aber ich verstehe nicht was. Ideen?
 
Keine Ideen, aber tut es ein Plan vielleicht auch ?

Als erstes würde ich mir hier mal die Protokoll-Optionen zu Gemüte führen und versuchen, dem kräftigen Schwan einige zusätzliche Informationen zu entlocken. Wenn ich die Dokumentation richtig verstehe, bringt die Zeile
Code:
config setup
	charondebug=ike
eigentlich überhaupt nichts, da das Standard-Loglevel für alle Komponenten bei 1 liegt.
Auch ist der aktuelle Status der IPSec-Verbindungen sicherlich nicht uninteressant, aber die Protokolle, wie es zu diesem Status kommt, sind in der Regel informativer.

Wenn auf der AVM-Seite immer noch Längenfehler auftreten, kann das folgende Ursachen haben:
1. falscher Aufbau von verschlüsselten Paketen (sollte kein Problem sein, wenn beide Seiten in demselben Modus arbeiten)
2. falsche SA, die dann zur fehlerhaften Entschlüsselung der Nutzdaten-Header führt

Eine korrekte VPN-Verbindung (in diesem Falle seitens einer FB (Initiator) zu einem Linux-Server mit racoon) sieht im AVM-Protokoll so aus:
Code:
2014-07-04 02:27:09 avmike:Source: Warning: source changed from 0.0.0.0:500 to 85.x.y.z:500
2014-07-04 02:27:09 avmike:mainmode Source: selected lifetime: 3600 sec(no notify)
2014-07-04 02:27:09 avmike:mainmode Source: add SA 1
2014-07-04 02:27:09 avmike:Source remote peer supported XAUTH
2014-07-04 02:27:09 avmike:Source remote peer supported NAT-T RFC 3947
2014-07-04 02:27:09 avmike:Source remote peer supported DPD
2014-07-04 02:27:09 avmike:Source: sending embedded inital contact message (0,85.x.y.z,0.0.0.0)
2014-07-04 02:27:09 avmike:Source: switching to NAT-T (Initiator)
2014-07-04 02:27:09 avmike:Source: Phase 1 ready
2014-07-04 02:27:09 avmike:Source: current=0.0.0.0 new=85.x.y.z:4500
2014-07-04 02:27:09 avmike:Source start_vpn_keepalive already running
2014-07-04 02:27:09 avmike:Source: no valid sa, reseting initialcontactdone flag
2014-07-04 02:27:09 avmike:Source: local is behind a nat
2014-07-04 02:27:09 avmike:Source: remote is behind a nat
2014-07-04 02:27:09 avmike:Source: sending initial contact message
2014-07-04 02:27:09 avmike:Source: start waiting connections
2014-07-04 02:27:09 avmike:Source: Phase 2 starting (start waiting)
2014-07-04 02:27:09 avmike:Source: Phase 2 ready
2014-07-04 02:27:09 avmike:< cb_sa_created(name=Source,id=1,...,flags=0x00032101)
2014-07-04 02:27:09 avmike:Source stop_vpn_keepalive to 192.168.a.1
2014-07-04 02:27:09 avmike:Source start_keepalive_timer 3540 sec
2014-07-04 02:27:09 avmike:Source: start waiting connections
2014-07-04 02:27:09 avmike:Source: NO waiting connections
2014-07-04 02:27:19 avmike:>>>4500 nat-t-keepalive[85.x.y.z:4500]
Stimmt also weitgehend mit Deinem Protokoll überein, aber ich sehe da keine "Längenfehler" in irgendwelchen IPSec-Paketen ... also wird wohl wirklich etwas in Deiner Konfiguration nicht stimmen; unabhängig von dem, was da strongSwan auf dem vServer auch anzeigt.

Was man braucht, ist ein ausführlicheres Protokoll zumindest auf der Seite, wo man es beeinflussen kann und die dazu passenden Informationen von der anderen Seite (also der Box). Daß da die RX- und TX-Zähler hochlaufen, ist sicherlich eine interessante Anekdote, aber wie wäre es denn mal mit einem Packetdump, damit man die Pakete dann auch sehen kann ?

Wenn es weiter mit mehr oder weniger wildem Probieren laufen soll, sieh Dir vielleicht mal "lefthostaccess" an, das könnte in Deiner Situation eine Ursache sein (also die Firewall, die mit den Paketen nichts anfangen kann, weil sie die Adressen gar nicht kennt und diese dann verwirft). Vielleicht hat Dein vServer aber auch gar keine iptable-Chains ?
Das weiterhin andauernde unsystematische Probieren unterstelle ich einfach mal, da ansonsten die nunmehr neue Einstellung "leftsourceip=%config" mir vollkommen unerklärlich ist. Lt. Dokumentation dient sie zum Pull der lokalen Netzwerkeinstellungen vom Peer ("If the value is one of the synonyms %config, %cfg, %modeconfig or %modecfg, an address (from the tunnel address family) is requested from the peer.").
Warum die Fritz!Box dem vServer jetzt im Config-Mode eine Adresse zuweisen sollte, verstehe ich absolut nicht mehr. Wenn diese Einstellung jemals eine funktionierende VPN-Verbindung ermöglichen sollte (solange sie nicht einfach nur ignoriert wird), wäre ich mehr als erstaunt ...

Und damit bin ich dann wieder beim Dozieren ... aber: Wie willst Du ohne systematische Vorgehensweise bei einem IPSec-VPN (da gibt es nun mal mehr als einen möglichen Parameter zum Probieren und die möglichen Permutationen aller Einstellungen mag ich mir gar nicht vorstellen) jemals zu einem sinnvollen Ergebnis gelangen ? Wenn Du einen Schritt vorwärts gemacht hast (das in #48 sah ja danach aus), reißt Du hinterher wieder alles ein. Ich wäre schon schwer überrascht, wenn Du den kompletten Zustand aus #48 gesichert hättest und den auf Zuruf wiederherstellen könntest.

So macht das - jedenfalls mir - einfach keinen Spaß mehr. Kaum hat man einen möglichen Zipfel des Problems erhascht (und ggf. auch mal an Deiner Stelle - eigentlich wäre das in meinen Augen nun einmal Deine Aufgabe - in irgendwelchen Dokumentationen nach Anhaltspunkten gesucht), schon machst Du die nächste Baustelle auf, weil Du beim Herumprobieren auf ein anderes Problem gestoßen bist. Ich bin ein Gemütsmensch ... aber wenn das nicht ganz schnell sehr systematisch wird, bin ich hier raus. Sorry.

Edit: Wo Du Deine Auswahl der Proposals her hast, würde mich auch mal interessieren.
Code:
ike=des-aes-sha1-sha2
esp=aes-des-sha1-sha2
Ich kann mir beim besten Willen nicht vorstellen, daß das moderne strongSwan 5 wirklich das uralte und unsichere DES unterstützt. Insofern wird diese Einstellung wohl im besten Falle wegen eines Syntaxfehlers ignoriert. Aber auch hier zeigt sich dann wieder das Fehlen jeder Protokolldatei überdeutlich ... solche Probleme würden darin sicherlich auftauchen.
 
Zuletzt bearbeitet:
Du hast Recht. Da mich meine Try&Error - Methode bisher nicht zum Erfolg geführt hat, habe ich die Methode mal mit deiner kombiniert. Spricht ja nichts dagegen sich die Logs genauer anzuschauen. Ich habe die Konfiguration aus #48 wiederhergestellt (habe sie zwar nicht gespeichert, aber im #48 steht sie ja) und von da wieder angefangen zu graben. In den logs stehen ja aussagekräftige Dinge drin - habe ich festgestellt. So arbeite ich weiter. Mit einigen Tricks habe ich mittlerweile hinbekommen, dass der V-Server sich bei der Fritzbox anmelden kann (umgekehrt noch nicht) und Ping geht in beide Richtungen. Bei Phase 1 steht dabei im ike.log wieder dieser Paketlängenfehler, bei Phase 2 jedoch nicht. Daraus schließe ich, dass irgendwelche Paketlängenfehler im ike.log keinesfalls ignoriert werden können. Ich bleibe dran.
Weißt du was das heißen könnte?
Code:
2014-07-05 00:18:39 avmike:lokale ID-Information matched nicht mit empfangener ID
#kommt, wenn ich mask bei phase2remoteid auf 255.255.255.255 setze
@ PeterPawn: Danke nochmal für deinen Plan. Die Methode aus try&error + Doku lesen + logs auswerten hat sich als verdammt wirkungsvoll erwiesen.
Ich präsentiere hiermit funktionierende Konfigs.
Code:
vpncfg {
		connections {
				enabled = yes;
				conn_type = conntype_lan;
				name = "V-Server";
				always_renew = yes;
				reject_not_encrypted = no;
				dont_filter_netbios = yes;
				localip = 0.0.0.0;
				local_virtualip = 0.0.0.0;
				remoteip = 84.200.y.z;
				remote_virtualip = 192.168.1.1;
				localid {	fqdn = "dyndns.selfhost.bz";	}
				remoteid {	ipaddr = 84.200.y.z;	}
				mode = phase1_mode_idp;
				phase1ss = "all/all/all";
				keytype = connkeytype_pre_shared;
				key = "geheim";
				cert_do_server_auth = no;
				use_nat_t = yes;
				use_xauth = no;
				use_cfgmode = no;
				phase2localid {
					ipnet {	ipaddr = 192.168.176.0;
							mask = 255.255.255.0;	}
				}
				phase2remoteid {
					ipnet {	ipaddr = 192.168.1.0;
							mask = 255.255.255.0;	}	
				}
				phase2ss = "esp-all-all/ah-all/comp-all/no-pfs";
				accesslist = "permit ip any 192.168.1.0 255.255.255.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";
}

// EOF
Code:
# /usr/local/etc/ipsec.conf - strongSwan IPsec configuration file

config setup
	uniqueids=no
#	charondebug="ike 2, knl 2, cfg 2, mgr 2, chd 2, dmn 2, esp 2, lib 2, tnc 2"

conn berlin
	keyexchange=ikev1
	left=84.200.y.z
	leftsubnet=192.168.1.0/24
	#leftsourceip=192.168.1.1
	ike=aes256-sha-modp1024!	#Ausrufezeichen sind wichtig
	esp=3des-md5!
	[email protected]
	right=%dyndns.selfhost.bz
	rightsubnet=192.168.176.0/24
	authby=psk
        auto=add
Code:
# /usr/local/etc/ipsec.secrets
: PSK geheim
Code:
# cat /tmp/ike.log
2014-07-05 04:08:57 avmike:mainmode V-Server: selected lifetime: 3600 sec(no notify)
2014-07-05 04:08:57 avmike:V-Server remote peer supported XAUTH
2014-07-05 04:08:57 avmike:V-Server remote peer supported DPD
2014-07-05 04:08:57 avmike:V-Server remote peer supported NAT-T RFC 3947
2014-07-05 04:08:58 avmike:mainmode V-Server: add SA 1
2014-07-05 04:08:58 avmike:V-Server: switching to NAT-T (Initiator)
2014-07-05 04:08:58 avmike:V-Server: Warning: source changed from 84.200.y.z:500 to 84.200.y.z:4500
2014-07-05 04:08:58 avmike:V-Server: Phase 1 ready
2014-07-05 04:08:58 avmike:V-Server: local is behind a nat
2014-07-05 04:08:58 avmike:V-Server: remote is behind a nat
2014-07-05 04:08:58 avmike:V-Server: start waiting connections
2014-07-05 04:08:58 avmike:V-Server: Phase 2 starting (start waiting)
2014-07-05 04:08:58 avmike:V-Server: Phase 2 ready
2014-07-05 04:08:58 avmike:< cb_sa_created(name=V-Server,id=1,...,flags=0x00032101)
2014-07-05 04:08:58 avmike:V-Server: start waiting connections
2014-07-05 04:08:58 avmike:V-Server: NO waiting connections
2014-07-05 04:09:08 avmike:>>>4500 nat-t-keepalive[84.200.y.z:4500]
# ping -c2 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=24.374 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=24.364 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 24.364/24.369/24.374 ms
#
Code:
root@psychomantis:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 2.6.32-042stab084.3, i686):
  uptime: 9 minutes, since Jul 05 04:08:48 2014
  malloc: sbrk 520192, mmap 0, used 149880, free 370312
  worker threads: 7 of 16 idle, 5/0/4/0 working, job queue: 0/0/0/0, scheduled: 4
  loaded plugins: charon aes des rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey
sshkey fips-prf gmp xcbc cmac hmac attr kernel-libipsec kernel-netlink resolve socket-default stroke updown
Listening IP addresses:
  84.200.y.z
  192.168.1.1
Connections:
      berlin:  84.200.y.z...dyndns.selfhost.bz,0.0.0.0/0,::/0  IKEv1
      berlin:   local:  [84.200.y.z] uses pre-shared key authentication
      berlin:   remote: [dyndns.selfhost.bz] uses pre-shared key authentication
      berlin:   child:  192.168.1.0/24 === 192.168.176.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
      berlin[1]: ESTABLISHED 9 minutes ago, 84.200.y.z[84.200.y.z]...188.104.g.h[dyndns.selfhost.bz]
      berlin[1]: IKEv1 SPIs: 4c9cbd8ae5e3d5e4_i 9903a6a6ca526fb8_r*, pre-shared key reauthentication in 2 hours
      berlin[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
      berlin{1}:  INSTALLED, TUNNEL, ESP in UDP SPIs: d9986d98_i e38ff3ea_o
      berlin{1}:  3DES_CBC/HMAC_MD5_96, 420 bytes_i (5 pkts, 539s ago), 420 bytes_o (5 pkts, 539s ago), rekeying in 33 minutes
      berlin{1}:   192.168.1.0/24 === 192.168.176.0/24
root@psychomantis:~# ping -c2 192.168.176.1
PING 192.168.176.1 (192.168.176.1) 56(84) bytes of data.
64 bytes from 192.168.176.1: icmp_seq=1 ttl=64 time=24.6 ms
64 bytes from 192.168.176.1: icmp_seq=2 ttl=64 time=24.4 ms

--- 192.168.176.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 24.454/24.544/24.634/0.090 ms
root@psychomantis:~#
So funktioniert das, wenn ich nach "ipsec start" noch "ip addr add 192.168.1.1 dev ipsec0" mache. Danach kann sowohl der Vserver die Verbindung zur Fritzbox starten, als auch umgekehrt. Füge ich ipsec0 keine IP-Adresse hinzu, kommt der irgendwo weiter oben beschriebene Fehler "unable to install IPsec policies (SPD) in kernel". Abhilfe bringt "leftsourceip=192.168.1.1". Dann sieht man aber wieder diese Paketlängenfehler, obwohl trotzdem alles funktioniert. Das i-Tüpfelchen wäre jetzt also noch ohne "ip addr add ..." auszukommen und keine Paketlängenfehler sehen.
Code:
...
2014-07-05 04:23:42 avmike:V-Server: switching to NAT-T (Initiator)
2014-07-05 04:23:42 avmike:V-Server: Warning: source changed from 84.200.y.z:500 to 84.200.y.z:4500
2014-07-05 04:23:42 avmike:V-Server: Phase 1 ready
2014-07-05 04:23:42 avmike:V-Server: local is behind a nat
2014-07-05 04:23:42 avmike:V-Server: remote is behind a nat
2014-07-05 04:23:42 avmike:V-Server: start waiting connections
2014-07-05 04:23:42 avmike:V-Server: Phase 2 starting (start waiting)
2014-07-05 04:23:42 avmike:V-Server
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2014-07-05 04:23:42 avmike:V-Server: start waiting connections
2014-07-05 04:23:42 avmike:V-Server: NO waiting connections
2014-07-05 04:23:42 avmike:V-Server: Phase 2 ready
2014-07-05 04:23:42 avmike:< cb_sa_created(name=V-Server,id=2,...,flags=0x00032101)
2014-07-05 04:23:42 avmike:V-Server: start waiting connections
2014-07-05 04:23:42 avmike:V-Server: NO waiting connections
2014-07-05 04:23:52 avmike:>>>4500 nat-t-keepalive[84.200.y.z:4500]
# ping -c2 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=24.588 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=24.386 ms

--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 24.386/24.487/24.588 ms
#
Code:
#das sehe ich im syslog, wenn ich diese Paketlängenfehler im ike.log sehe: 
...
Jul  5 04:43:45 psychomantis charon: 13[CFG]  config: 192.168.176.0/24, received: 192.168.176.0/24 => match: 192.168.176.0/24
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting traffic selectors for us:
Jul  5 04:43:45 psychomantis charon: 13[CFG]  config: 192.168.1.0/24, received: 192.168.1.0/24 => match: 192.168.1.0/24
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   protocol mismatch, skipping
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable INTEGRITY_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   no acceptable ENCRYPTION_ALGORITHM found
Jul  5 04:43:45 psychomantis charon: 13[CFG] selecting proposal:
Jul  5 04:43:45 psychomantis charon: 13[CFG]   proposal matches
Jul  5 04:43:45 psychomantis charon: 13[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, IPCOMP:, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_MD5_96/NO_EXT_SEQ, ESP:AES_CBC/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ, ESP:DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
Jul  5 04:43:45 psychomantis charon: 13[CFG] configured proposals: ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
Jul  5 04:43:45 psychomantis charon: 13[CFG] selected proposal: ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
...

PeterPawn, wie schaut im ike.log erfolgreiches rekeying aus?
Die Verbindung steht, rekeying klappt alles, aber bei jedem rekeying kommt ein Paketlängenfehler, obwohl es sich nicht auf die Verbindung auswirkt.
 
Zuletzt bearbeitet:
wie schaut im ike.log erfolgreiches rekeying aus?
Ich verspreche Dir, ich sehe es mir bei Gelegenheit an ... aber im Moment passt es gerade wirklich nicht. ;)

Bis Donnerstag abend hast Du eine Antwort ... versprochen.
 
Hallo PeterPawn,

würde mich auch interessieren, wie erfolgreiches Rekeying aussieht. Ich sehe beim Rekeying immer nur
Code:
Aug  3 14:06:40 08[IKE] <9001|4> unable to reauthenticate in CHILD_SA REKEYING state, delaying for 14s
aber erfolgreich ist es nie. Der Tunnel wird dann irgendwann einfach neu aufgebaut...
 
Nun ist etwas Zeit vergangen und Anleitungen zu avm2swan gibt es wie Sand am Meer.
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):
Code:
vpncfg {    
    connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "vserver";
                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;
    //          [COLOR=red]remote_virtualip = 192.168.170.1;[/COLOR]  // die IP, die das interface ipsec0 im Vserver bekommt
    //          remoteip = 123.45.67.89;                                        //entweder remoteip
                remotehostname = "dyndns.meinvserver.dynip.org";                //oder remotehostname
                keepalive_ip = 0.0.0.0;
                localid {     fqdn = "abcdefg123456.myfritz.net";    }
                remoteid {    fqdn = "dyndns.meinvserver.dynip.org";    }       //entweder fqdn
    //          remoteid {    ipaddr = 123.45.67.89;    }                       //oder ipaddr
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "sehrsehrsehrgeheim";
                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 {    ipaddr = 192.168.170.1;    }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.170.0 255.255.255.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";
        }

Code:
root@psychomantis:~# cat /usr/local/etc/ipsec.conf
config setup
conn %default
 left=dyndns.meinvserver.dynip.org   #entweder so, oder IP des Vservers hier eintragen
 leftsubnet=192.168.170.1/32
 leftsourceip=192.168.170.1
 ike=aes256-sha-modp1024
 esp=aes192-sha1-modp1024!
 ikelifetime=3600s
 keylife=3600s
 authby=secret
 auto=add


conn avm2swan
 right=abcdefg123456.myfritz.net
 [email protected]
 rightsubnet=192.168.178.0/24
root@psychomantis:~#
Code:
root@psychomantis:~# cat /usr/local/etc/ipsec.secrets
%any %any : PSK sehrsehrsehrgeheim
root@psychomantis:~#

Und nur nach dem Eingeben von "ifconfig ipsec0 192.168.170.1" funktioniert die Verbindung dann auch tatsächlich.
Frage: Warum akzeptiert strongswan meine "leftsourceip=192.168.170.1" in der Einstellung nicht? Das interface ipsec0 müsste doch eigentlich von alleine die IP bekommen, ohne dass ich es explizit vergeben muss.
Nachtrag/Antwort auf die Frage: remote_virtualip muss gesetzt werden (oben in rot editiert).
Nachtrag2: reauthentication und rekeying funktioniert auch wie es soll, aber am Morgen ist die Verbindung weg und über myfritz kann ich die beiden Fritzboxen auch nicht mehr erreichen (nur lokal vor Ort). Irgendwas stimmt also noch nicht.
Nachtrag3: remote_virtualip wieder auf 0.0.0.0 setzen und manuell "ifconfig ipsec0 192.168.170.1" im Vserver ausführen. Dann funktioniert alles und man kann im Log der Fritzbox beobachten wie sie die VPN-Verbindung genau ein mal verliert: bei der DSL-Zwangstrennung.
 
Zuletzt bearbeitet:
[FONT=&amp]Habe jetzt mal eine andere Frage: hat AVM irgendwas in VPN von der Firmware 06.30 zu 06.50 verändert?

Habe hier nämlich eine 6810er Fritzbox mit der Firmware 06.30 erfolgreich im Einsatz gehabt. Diese Fritzbox hat zu meiner 7490er zu Hause (VDSL) und zu meinem Linux-Vserver (StrongSWAN) immer brav eine VPN-Verbindung aufgebaut und auch gehalten. [/FONT]

[FONT=&amp]Nun habe ich die 6810er gegen eine 6840er mit der Firmware 06.50 getauscht. Die VPN-Konfiguration wurde weitestgehend unverändert gelassen (myfritz.net-Name angepasst). [/FONT]
[FONT=&amp]Nun ist es so, dass der VPN-Tunnel direkt nach dem Verbinden hergestellt wird und eine Zeit lang auch steht, aber danach nicht mehr. Im Vserver ist laut "ipsec statusall" alles gut, aber die Fritzbox ist über den VPN-Tunnel nicht pingbar. Nach einer Zeit dann wieder doch pingbar. Dann wieder doch nicht usw. In meiner 7490er kommt irgendwann "dead peer detection", dann "timeout", dann "Verbindung ... wurde erfolgreich hergestellt", aber pingbar ist die Gegenstelle dann immer noch nicht. Manchmal dann auch doch - da habe ich noch keine Regelmäßigkeit sehen können. [/FONT]
[FONT=&amp]
Ich kann keinen Fehler finden. Die VPN-Verbindung wird natürlich von der 6840er Fritzbox aufgebaut (diese LTE-Boxen haben ja meistens keine von außen erreichbare IPs). Am Vserver und an der 7490er wurde so gut wie nichts verändert (myfritz-Namen angepasst). Die funktionieren ja nur als Responder. Ideen? [/FONT]
 
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.