FritzBox als VPN client für Cyberghost

[n3mo]

Hallo,

ich versuche meine Fritzbox als VPN Client bei CyberGhost anzumelden und den gesamten Traffic zu tunneln. Die FritzBox hängt hinter einem anderen Router der das Internet bereitstellt. Dort ist die FritzBox als DMZ host eingerichtet, das scheint auch zu funktionieren, ich kann die FritzBox-Oberfläche über die öffentliche IP des anderen Routers erreichen.
Von CyberGhost habe ich Zugangsdaten für eine VPN Verbindung mittels IPsec erhalten:
Server, Nutzername, Passwort, Pre-shared secret.

Damit habe ich mir eine config-datei erstellt:

/*
 * C:\fritzbox.cfg
 * Fri Feb 29 20:44:09 2008
 */

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "CyberGhost";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                remotehostname = "******";
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "******";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
			xauth {
				valid = yes;
				username = "******";
				passwd = "******";
			}
                use_cfgmode = yes;
                phase2ss = "esp-all-all/ah-all/comp-all/no-pfs";
                accesslist = "reject udp any any eq 53", 
                             "reject udp any any eq 500", 
                             "reject udp any any eq 4500", 
                             "permit ip any any";
        }

}


// EOF

Ich kann mich anscheinend erfolgreich einloggen. Die Anzeige in der Fritzboxoberfläche ist grün und der Ereignis-Monitor meldet "VPN-Verbindung zu CyberGhost wurde erfolgreich hergestellt." (Verfälsche ich die Zugangsdaten klappt es nicht)

Sobald die VPN-Verbindung steht, kann ich keine Internetseiten mehr ansurfen. Gibt es einen Fehler in meiner config? Ich möchte allen Internetverkehr über die VPN Verbindung routen. Das Netz des Routers mit Internet ist 192.168.1.0, das der Fritzbox 192.168.188.0.

 

[PeterPawn]

Was sagt denn ein Paket-Mitschnitt auf der "Routing-Schnittstelle" und der "1. Internetverbindung"?

Für ein auf der Routing-Schnittstelle auftauchendes Paket mit externem Ziel sollte auf der 1. Internetverbindung kein Klartext-Paket zu sehen sein und stattdessen ein entsprechendes IPSec-Paket (UDP 4500 oder ESP) an den Anbieter. Geht so ein Paket raus, sollte ja auch eine entsprechende Antwort vom Anbieter irgendwann eintreffen und nach Decapsulation auf der Routing-Schnittstelle wieder im Klartext sichtbar sein.

Nach der "accesslist" wird ja alles, was nicht DNS und IPSec (mit und ohne NAT-T) ist, durch den Tunnel geschickt. Ich weiß nicht, was da zwischen dem Anbieter und Deiner Box bzgl. NAT-T ausgehandelt wird (schau doch mal in die ike.log) und auch nicht genau, ob das FRITZ!OS unter "permit ip any any" auch ESP-Pakete subsummiert (das wäre ja auch IP-Traffic, wie TCP oder UDP), aber wenn da kein NAT-T verwendet wird und die letzte Regel auch ESP in den Tunnel stopfen würde, kämen auf der 1. Internet-Verbindung keine ESP-Pakete vorbei.

In Abhängigkeit von dem verwendeten PSK (ist der tatsächlich spezifisch für den Kunden-Account oder für alle/mehrere Kunden gleich?) ist das aber auch keine wirklich sichere Verbindung. Ohne PFS in P2 müßte eine nachträgliche Entschlüsselung aufgezeichneten Verkehrs möglich sein - wenn ich mich nicht gerade fundamental irre. Beim "aggressive mode" ist dann auch die Sicherheit des IKE in P1 direkt von der Stärke (und Einmaligkeit) des PSK abhängig, dort wird dann der Hash-Wert der Identitäten (da geht der PSK ein) im Klartext übertragen und nicht noch einmal selbst verschlüsselt. Deshalb findet sich auch oft die Empfehlung, "aggressive mode" und PSK in Kombination generell zu vermeiden ... bei ausreichend starkem PSK nicht unbedingt problematisch, aber wenn ein VPN-Anbieter einen gemeinsamen PSK für mehrere Kunden verwendet, ist da eben von echter Vertraulichkeit nicht mehr unbedingt auszugehen. Andererseits sind diese Anbieter ja in der überwiegenden Zahl der Fälle auch nicht zum Schutz der Inhalte der Kommunikation gedacht als vielmehr zur Verschleierung des Ursprungs und spätestens dort wird ja dann der verschlüsselte Verkehr ohnehin wieder entschlüsselt.

Je nachdem, wie der Anbieter beim DNS arbeitet, kann sich auch aus "remotehostname" ein Problem ergeben. Kommt da eine "round-robin"-Verfahren zum Einsatz (DNS geht ja nicht über den Tunnel) und läuft die TTL der ursprünglichen Antwort beim Verbindungsaufbau ab, so daß die Box tatsächlich eine neue Abfrage macht (sie prüft zyklisch - m.E. alle 120 Sekunden - die Adresse des Peers, um DynDNS-Anschlüsse auf beiden Seiten einer Verbindung zu ermöglichen), baut sie die bestehende Verbindung ab und mit der dann gelieferten Adresse neu auf, wenn sich diese Adresse von der gerade verwendeten unterscheidet.

tl;dr:
Als erste Diagnose einen Packet-Dump anfertigen und suchen, ob der Verkehr tatsächlich zum Anbieter geht und von dort etwas zurück kommt. Wenn man da nicht unbedingt gleich "permit ip any any" nimmt, sondern etwas Selektiveres für das Ziel, kann man das ggf. besser verfolgen.

 

[PantaRhei]

Hallo n3mo,
ergänzend zu den Inputs von PeterPawn wären für eine eine Analyse wären folgende Inputs hilfreich:
FritzBox-Type:
Firmware-Version:

Ich kann mich anscheinend erfolgreich einloggen. Die Anzeige in der Fritzboxoberfläche ist grün und der Ereignis-Monitor meldet "VPN-Verbindung zu CyberGhost wurde erfolgreich hergestellt."

ich hatte mal bei einer FB7170 erlebt, dass VPN-Connection eine "Grün" Flagge zeigte und die Verbindung war dennoch nicht ordnungsgemäß aufgebaut.
Um hier Licht ins Dunkel zu bringen helfen die VPN-Logfiles (http://fritz.box/support.lua)

folgende Abschnitte aus supportdata File bereitstellen:

##### BEGIN SECTION vpn VPN
VPN avmike
...
VPN assocs
...
VPN connections
...
##### END SECTION vpn




##### BEGIN SECTION vpn_cfg /var/flash/vpn.cfg
...
##### END SECTION vpn_cfg

Am Besten noch vorher Bitte die Cyberghost-VPN-Connection einmal neu starten, d.h. aktivieren, ca. 60 sek VPN-Connection laufen lassen, mit Client testen und dann VPN-Connection wieder deaktivieren.
Hintergrund: dann haben wir den Verbindungsaufbau sauber im Logfile.

PantaRhei

 

[n3mo]

Vielen Dank für eure Hilfe. Trotz meines Versuchs euren Ratschlägen zu folgen und mir mittels packet-dump und Logfile genauer anzuschauen was passiert konnte ich keinen Fortschritt erzielen.

Ich habe mittlerweile mit Hilfe von Freetz, OpenVPN auf die Box gebracht. Die Dokumenation ist besser als bei AVMs IPsec Lösung und CyberGhost stellt auch für dieses Protokoll Zugangsdaten bereit.
Ich kann die VPN-Verbindung auch herstellen. Wenn ich dann per telnet auf der Box eine ping-Anfrage an eine Internet-IP mache, funktioniert diese auch. Aber leider funktioniert das pingen von keinem Gerät im Netzwerk der FritzBox (nur dann wenn kein VPN aufgebaut wurde)
Der Grund liegt vermutlich daran das ich von Cyberghost nur eine Lizenz für ein Gerät habe. Ist es möglich den Verkehr im FB-Netzwerk so zu routen das auf CyberGhost-Seite nur der Verkehr eines Gerätes zu sehen ist?

Viele Grüße,

Nemo

 

[n3mo]

Achja, meine Box ist eine 7270v3 mit FRITZ!OS 06.06

 

[PeterPawn]

Trotz meines Versuchs euren Ratschlägen zu folgen und mir mittels packet-dump und Logfile genauer anzuschauen was passiert konnte ich keinen Fortschritt erzielen.

Wie sahen denn die Ergebnisse dabei aus?

CyberGhost stellt auch für dieses Protokoll Zugangsdaten bereit.

Wenn ich das richtig lese, hast Du PPTP noch nicht probiert. Braucht in Freetz m.W. auch bloß einen neuen Kernel ...

Wenn Du dann wieder an der Stelle angelangt bist, wo Du Dich auf einen Zugangsweg festlegen willst, wäre es vermutlich hilfreich, wenn Du - abgesehen von solchen Nebensächlichkeiten wie konkreten Informationen, wie Du das derzeit konfiguriert hast - auch mal das FRITZ!Box-Modell und die Firmware-Version erwähnen würdest EDIT: ok, die Angabe von Modell und Version ist inzwischen vorhanden.

Dann noch auf wilde Spekulationen verzichtet ("Der Grund liegt vermutlich daran das ich von Cyberghost nur eine Lizenz für ein Gerät habe.") und an deren Stelle einfach die verwendete OpenVPN-Konfiguration nebst der aktuellen "brctl show"-Ausgabe bei aktivierter OpenVPN-Verbindung in einem CODE-Block gesetzt ... dann steigen die Chancen, daß man Dir helfen könnte, gewaltig. Kommt dann noch der Versuch hinzu, sich tatsächlich in die Grundlagen von VPNs zu vertiefen, ist der Erfolg nahezu unausweichlich. Auch da würde man aber vermutlich mit einem Packet-Dump bei Problemen nachsehen müssen, ob die VPN-Pakete denn tatsächlich auf dem gewünschten Weg die FRITZ!Box verlassen und Antworten aus dem Internet wie erwartet eintreffen.

Ich bin mir nicht ganz sicher, ob es so eine richtig gute Idee war, auf OpenVPN zu setzen, auch wenn die "Dokumenation" besser sein mag. Was hast Du denn von dieser Dokumentation unter dem Gesichtspunkt "TUN vs. TAP" (genauer eigentlich L2-Bridge vs. Routing) verstanden? Und noch viel wichtiger, was hast Du eingestellt? Das wäre zwar durch die bereits erwähnten Dateien/Kommandos und deren Ausgabe auch zu klären, aber es sollte nur noch einmal aufzeigen, daß diese Nachfragen nicht nur auf reiner Neugierde basieren. Auf der anderen Seite ist eine OpenVPN-Konfiguration, mit der der gesamte Verkehr über die VPN-Verbindung geroutet wird, meines Wissens schon mehrfach hier thematisiert worden, welchen dieser Threads (http://bfy.tw/3TPD) hast Du denn bisher gelesen und was hast Du daraus für Deine eigene Konfiguration für Erkenntnisse gezogen?

Bei den derzeit verfügbaren Informationen wäre auch die Empfehlung, die FRITZ!Box um 90 Grad in der Horizontalen zu drehen und es erneut zu versuchen, irgendwie zu begründen.

Das mag alles übertrieben sarkastisch klingen ... aber die Vermutung, daß Dir da das "Sitzfleisch" für eine echte Suche nach einer Lösung fehlt, ist vielleicht angesichts des sofortigen Umschwenkens auf OpenVPN (und die nach Deiner Ansicht bessere Dokumentation hat zumindest nicht dazu geführt, daß die Fragen im letzten Absatz "mehr Substanz" hätten) nicht von der Hand zu weisen. Da mußt Du Dir dann (im übertragenen Sinne) schon die Frage gefallen lassen, was jetzt passieren würde, wenn Dich jemand bei der Einrichtung von OpenVPN unterstützen will und Dir das dann auch wieder zu kompliziert wird. Die Möglichkeiten auf Deiner Seite sind vielfältig ... vom erwähnten PPTP bei CyberGhost bis zur Verwendung eines anderen Routers anstelle der FRITZ!Box. Man sollte also (bzw. würde gerne) als "Diskussionsteilnehmer" zumindest eine Vorstellung haben können, ob sich die Investition von eigener Zeit und Schreibarbeit in diesen Thread lohnt oder ob man es lieber lassen sollte.

Das soll auch nicht heißen, daß OpenVPN automatisch eine schlechte Wahl wäre oder IPSec oder PPTP ... aber es ist schon ein gewaltiger Unterschied zwischen IPSec, IPSec/L2TP, OpenVPN und PPTP (und den Systemen, die diese Lösungen nutzen können). Wenn Du ständig die "Technologie" wechselst und dabei nicht sehr genau die Unterschiede kennst, bist Du mit Analogie-Schlüssen zu anderen VPN-Lösungen ganz schnell auf dem Holzweg. Daher ist es für Anfänger eine recht schlechte Idee, einfach unbekümmert zu probieren und zum nächsten Ansatz zu wechseln, wenn es auf Anhieb nicht funktionieren will. Ein VPN ist kein Spielzeug oder irgendetwas, was man "mal nebenbei" konfiguriert und wer eine "schlüsselfertige Lösung" haben will, sollte zu einer Hardware-Lösung (z.B. ShellFire) greifen.

 

[n3mo]

Hallo PeterPawn,

welche Verbindungsart würdest du mir denn empfehlen IPsec oder OpenVPN?

Wie sahen denn die Ergebnisse dabei aus?

Die reiche ich gleich nach.

und an deren Stelle einfach die verwendete OpenVPN-Konfiguration nebst der aktuellen "brctl show"-Ausgabe bei aktivierter OpenVPN-Verbindung in einem CODE-Block gesetzt ...

Folgend mein cfg-File. Es ist von CyberGhost generiert, ich habe dort nur die Pfadangaben zu Zertifikaten und Login-Daten eingegeben.

client
remote 4-de.cg-dialup.net 443
dev tun 
proto udp
auth-user-pass /tmp/flash/openvpn/login.data


resolv-retry infinite 
redirect-gateway def1
persist-key
persist-tun
nobind
cipher AES-256-CBC
auth MD5
ping 5
ping-exit 60
ping-timer-rem
#explicit-exit-notify 2
script-security 2
remote-cert-tls server
route-delay 5
tun-mtu 1500 
fragment 1300
mssfix 1300
verb 4
comp-lzo


ca /tmp/flash/openvpn/ca.crt

cert /tmp/flash/openvpn/box.crt

key /tmp/flash/openvpn/box.key

root@fritz:/var/mod/root# brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.246511e56363       no              eth0
                                                        ath0
hotspot         8000.246511e56363       no
guest           8000.246511e56363       no

 

[Riverhopper]

Hallo n3mo, hallo PeterPawn,
Sorry, dass ich hier mich hier "einklinke";

CyberGhost bietet doch IPsec-IKEv1 mit Xauth:
siehe https://support.cyberghostvpn.com/i...le/View/799/0/ipsec-fur-android-konfigurieren
sowie: https://support.cyberghostvpn.com/i...rticle/View/819/0/ipsec-fur-ios-konfigurieren
Und das ist doch genau was die FritzBox kann.

Lösungsvorschlag analog zu http://www.ip-phone-forum.de/showthread.php?t=283214&p=2137244&viewfull=1#post2137244
d.h. bei FritzBox statt LAN2LAN-Config eine Site2Host-Config verwenden, hier arbeitet FB als VPN-Router und macht NAT/Masquerading für den Tunnel-Outbound-Traffic (conntype=out)


Datei /var/flash/vpn.cfg müsste somit für CyberGhost-IPsec-IKEv1 so aussehen:

meta { encoding = "utf-8"; }

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_out;            /* Changed */
                name = "CyberGhost";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = no;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 95.141.28.56;        /* hamburg-s02-i01.cg-dialup.net */
                remote_virtualip = 0.0.0.0;
                remotehostname = "";
                keepalive_ip = 8.8.8.8;
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";        /* ggf anpassen */
                keytype = connkeytype_pre_shared;
                key = "CyberGhost";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "[COLOR=#0000ff]<Your_Xauth_UserName>[/COLOR]";
                        passwd = "[COLOR=#0000ff]<Your_Xauth_password>[/COLOR]";
                }
                use_cfgmode = yes;
                phase2remoteid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-all/comp-all/no-pfs";          /* ggf anpassen */
                accesslist = "permit ip [COLOR=#0000ff]192.168.xxx.yyy[/COLOR] 255.255.255.255 any",   /* anpassen */
                             "permit ip any 10.0.0.0 255.0.0.0";
        }
}

statt 192.168.xxx.yyy ist eine IP-Adresse eines Testrechners aus deinem LAN zu verwenden

Sollte es Probleme geben, so wären Logfiles wie in #3 beschrieben (Alternativ telnet und "cat /var/tmp/ike.log" verwenden) erforderlich.

LG Riverhopper

EDIT: Tippfehler bei "key" korrigiert
EDIT2: Hinweis telnet und "cat /var/tmp/ike.log" eingefügt
EDIT3: Semikolon in Zeile 19 der vpn.cfg eingefügt; Hinweis aus #10

 

[PeterPawn]

Ich denke, es dürfte mit OpenVPN am Ende problematisch werden, wenn der Anbieter Dir nur eine einzelne IP-Adresse zuweist, weil man bei der FRITZ!Box nicht problemlos per iptables ein zusätzliches NAT auf diese einzelne vom Anbieter zugewiesene IP-Adresse machen kann. Beim AVM-IPSec macht das der dsld dann für Dich (also das NAT), denn die vom Anbieter zugewiesene IP-Adresse wird von der FRITZ!Box wie eine zusätzliche externe IP-Adresse am WAN-Anschluß behandelt.

Für OpenVPN bräuchte es dann wohl noch "iptables" mit CT für NAT - meines Wissens bei aktueller Firmware ein ziemlich hoffnungsloses Unterfangen. Das ist dann wieder auf einem RasPi hinter der FRITZ!Box besser untergebracht.

Prinzipiell hätte die OpenVPN-Konfiguration aber (meiner Meinung nach, das kann man auch anders sehen) einige Schwächen, so würde ich "persist-tun" weglassen, das gibt zumindest an einem Anschluß mit Zwangstrennung absehbar Probleme, wenn der Anbieter mehr als ein Gateway unter einem DNS-Namen bereitstellt. Der Sicherheitsgewinn ist (ohne die Privilegien zu droppen) ohnehin nicht vorhanden, da stört die Option nur, weil sie das automatische Abräumen alter Routen beim Abbau der Verbindung (bzw. beim Schließen des tun-Devices) unterbindet und dann ggf. für eine geänderte (öffentliche) Gateway-Adresse nicht die notwendige Routing-Ausnahme eingetragen wird und damit auch der Verkehr zum neuen Gateway weiterhin über den alten (nicht mehr funktionierenden) Tunnel gehen soll. In Kombination mit "ping-exit" (was ja bei nicht funktionierender Verbindung die OpenVPN-Instanz ohnehin beendet), sehe ich auch nicht, was da "persist-tun" oder "persist-key" überhaupt bringen soll - meiner Meinung nach ist das nur dann sinnvoll, wenn die Instanz eben nicht beendet wird (z.B. mit ping-restart anstelle von ping-exit).

Wofür "script-security 2" notwendig sein soll, wenn gar keine "user-defined scripts" in der Konfiguration zu sehen sind, wäre die nächste Frage - 1 für "route" oder "ifconfig" ist ohnehin Standard. "ping-timer-rem" ist meines Wissens bei einem Client genauso fragwürdig.

Mein persönliches Fazit: In Deinem Szenario glaube ich nicht daran, daß OpenVPN auf der FRITZ!Box eine passende Lösung ist, jedenfalls dann nicht, wenn Dir der Anbieter nur eine einzelne IP-Adresse zuordnet und nicht ein kleines Subnetz, was dann auf den Clients entsprechend konfiguriert werden kann. Die einzelne Adresse bräuchte NAT, das macht auf neuer Firmware Probleme bis hin zum "geht gar nicht". Ich weiß nicht, wie CyberGhost da arbeitet, bei einer L2-Bridge hätte ich mir noch vorstellen können, daß sämtlicher Verkehr vom Client (natürlich nur IP auf L3) auf dem VPN-Server selbst durch ein passendes NAT gejagt wird. Nach der Ausgabe von "brctl show" ist das aber keine L2-Bridge zwischen dem OpenVPN-Interface und dem LAN/WLAN - damit fällt diese Möglichkeit ohnehin aus (sie wäre auch unwahrscheinlich, weil das beim Provider entsprechende Ressourcen bindet).

@Riverhopper:
Da gibt es keinen Grund "sich zu entschuldigen" ... das ist ein offenes Forum, wo jeder seine Meinung schreiben und seine Tipps geben kann und soll. Ich glaube ja auch nicht daran, daß OpenVPN mit CyberGhost auf einer FRITZ!Box funktionieren würde und würde selbst auch weiterhin alle Bemühungen auf die Client2LAN-Konfiguration der FRITZ!Box konzentrieren - genau wegen des NAT-Problems. Mit Deiner "accesslist" als pauschalem Vorschlag gehe ich nicht ganz konform, solange nicht geklärt ist, daß CyberGhost tatsächlich auch ein Transport-Netz mit 10/8 oder kleiner verwendet. Die andere Form (alles von 192.168.xxx.yyy immer in den Tunnel) hat zumindest den Vorteil, daß die Box selbst sich gar keine Gedanken darum machen muß, wie sie DNS-Namen auflöst oder welche Daten nun schon verschlüsselt sind und damit direkt über "dev dsl" gehen müssen ohne weitere Transformationen. Solange die FRITZ!Box selbst jetzt nicht auch nur durch den Tunnel arbeiten soll, ist das sogar die elegantere Lösung, weil auch ohne VPN-Verbindung trotzdem noch diverse Funktionen der Box selbst (von DynDNS bis Push-Mail) funktionieren, was ansonsten nicht der Fall wäre.

 

[n3mo]

Also dann IPsec ;-)

Ich habe es nun mit der cfg nach Riverhopper (Achtung in Zeile 19 fehlt ein Semikolon) versucht mit dem einzigen Unterschied reject_not_encrypted = yes;

meta { encoding = "utf-8"; }

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_out;
                name = "CyberGhost";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = yes;
                dont_filter_netbios = no;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 95.141.28.56;
                remote_virtualip = 0.0.0.0;
                remotehostname = "";
                keepalive_ip = 8.8.8.8;
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "CyberGhost";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "****";
                        passwd = "****";
                }
                use_cfgmode = yes;
                phase2remoteid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2ss = "esp-all-all/ah-all/comp-all/no-pfs";
                accesslist = "permit ip 192.168.188.23 255.255.255.255 any",
                             "permit ip any 10.0.0.0 255.0.0.0";
        }
}

Im Netz der FB hat mein Rechner die Adresse 192.168.188.23, DHCP ist aus. Mit dieser config erhalte ich auch einen grünen Button im GUI der Box, aber ich kann nicht surfen.

In meinem supportdata-file befindet sich kein "#### BEGIN SECTION vpn"?

Das log-file /var/tmp/ike.log hat folgenden Inhalt:

2015-12-28 11:22:33 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 11:22:33 avmike:new neighbour CyberGhost:  nat_t
2015-12-28 11:22:35 avmike:CyberGhost: Warning: source changed from 0.0.0.0:500 to 95.141.28.117:500
2015-12-28 11:22:35 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 11:22:35 avmike:mainmode CyberGhost: add SA 1
2015-12-28 11:22:35 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 11:22:35 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 11:22:35 avmike:CyberGhost remote peer supported DPD
2015-12-28 11:22:35 avmike:CyberGhost: sending embedded inital contact message (0,95.141.28.117,0.0.0.0)
2015-12-28 11:22:35 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 11:22:35 avmike:CyberGhost: Phase 1 ready
2015-12-28 11:22:35 avmike:CyberGhost: current=0.0.0.0 new=95.141.28.117:4500
2015-12-28 11:22:35 avmike:CyberGhost: no valid sa, reseting initialcontactdone flag
2015-12-28 11:22:35 avmike:CyberGhost: local is behind a nat
2015-12-28 11:22:35 avmike:CyberGhost: remote is behind a nat
2015-12-28 11:22:35 avmike:CyberGhost: sending initial contact message
2015-12-28 11:22:35 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 11:22:35 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 11:22:36 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 11:22:36 avmike:CyberGhost: start waiting connections
2015-12-28 11:22:36 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 11:22:36 avmike:CyberGhost: Phase 2 ready
2015-12-28 11:22:36 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00032301)
2015-12-28 11:22:36 avmike:CyberGhost: start waiting connections
2015-12-28 11:22:36 avmike:CyberGhost: NO waiting connections
2015-12-28 11:22:46 avmike:>>>4500 nat-t-keepalive[95.141.28.117:4500]
2015-12-28 11:23:48 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 11:23:48 avmike:FreeIPsecSA: spi=d9a361da            protocol=3 iotype=1
2015-12-28 11:23:48 avmike:FreeIPsecSA: spi=1db72de             protocol=3 iotype=2
2015-12-28 11:23:48 avmike:mainmode CyberGhost: del SA 1
2015-12-28 15:54:15 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 15:54:16 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 15:54:16 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 15:58:41 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 15:58:41 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 15:58:41 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 15:58:56 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 15:58:56 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 15:58:56 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 15:58:56 avmike:CyberGhost remote peer supported DPD
2015-12-28 15:58:57 avmike:mainmode CyberGhost: add SA 1
2015-12-28 15:58:57 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 15:58:57 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 15:58:57 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 15:58:57 avmike:CyberGhost: Phase 1 ready
2015-12-28 15:58:57 avmike:CyberGhost: local is behind a nat
2015-12-28 15:58:57 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 15:58:57 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 15:58:57 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 15:58:57 avmike:CyberGhost: start waiting connections
2015-12-28 15:58:57 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 15:58:57 avmike:CyberGhost: Phase 2 ready
2015-12-28 15:58:57 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 15:58:57 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 15:58:57 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 15:58:57 avmike:CyberGhost: start waiting connections
2015-12-28 15:58:57 avmike:CyberGhost: NO waiting connections
2015-12-28 15:59:07 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:02:24 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:02:24 avmike:FreeIPsecSA: spi=8d834db2            protocol=3 iotype=1
2015-12-28 16:02:24 avmike:FreeIPsecSA: spi=15b6447             protocol=3 iotype=2
2015-12-28 16:02:24 avmike:mainmode CyberGhost: del SA 1
2015-12-28 16:02:38 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 16:02:38 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 16:02:38 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 16:02:58 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 16:02:58 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 16:02:58 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 16:02:58 avmike:CyberGhost remote peer supported DPD
2015-12-28 16:02:59 avmike:mainmode CyberGhost: add SA 1
2015-12-28 16:02:59 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 16:02:59 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 16:02:59 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:02:59 avmike:CyberGhost: Phase 1 ready
2015-12-28 16:02:59 avmike:CyberGhost: local is behind a nat
2015-12-28 16:02:59 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:02:59 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:02:59 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:02:59 avmike:CyberGhost: start waiting connections
2015-12-28 16:02:59 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 16:02:59 avmike:CyberGhost: Phase 2 ready
2015-12-28 16:02:59 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 16:02:59 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 16:02:59 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 16:02:59 avmike:CyberGhost: start waiting connections
2015-12-28 16:02:59 avmike:CyberGhost: NO waiting connections
2015-12-28 16:03:09 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:06:26 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:06:26 avmike:FreeIPsecSA: spi=f8c85d07            protocol=3 iotype=1
2015-12-28 16:06:26 avmike:FreeIPsecSA: spi=5e773b              protocol=3 iotype=2
2015-12-28 16:06:26 avmike:mainmode CyberGhost: del SA 1
2015-12-28 16:07:03 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 16:07:03 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 16:07:03 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 16:07:15 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 16:07:15 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 16:07:15 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 16:07:15 avmike:CyberGhost remote peer supported DPD
2015-12-28 16:07:15 avmike:mainmode CyberGhost: add SA 1
2015-12-28 16:07:15 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 16:07:15 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 16:07:15 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:07:15 avmike:CyberGhost: Phase 1 ready
2015-12-28 16:07:15 avmike:CyberGhost: local is behind a nat
2015-12-28 16:07:15 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:07:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:07:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:07:16 avmike:CyberGhost: start waiting connections
2015-12-28 16:07:16 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 16:07:16 avmike:CyberGhost: Phase 2 ready
2015-12-28 16:07:16 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 16:07:16 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 16:07:16 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 16:07:16 avmike:CyberGhost: start waiting connections
2015-12-28 16:07:16 avmike:CyberGhost: NO waiting connections
2015-12-28 16:07:26 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:09:19 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:09:19 avmike:FreeIPsecSA: spi=799e49d2            protocol=3 iotype=1
2015-12-28 16:09:19 avmike:FreeIPsecSA: spi=256e3bb             protocol=3 iotype=2
2015-12-28 16:09:19 avmike:mainmode CyberGhost: del SA 1
2015-12-28 16:13:02 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 16:13:02 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 16:13:02 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 16:13:07 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 16:13:07 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 16:13:07 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 16:13:07 avmike:CyberGhost remote peer supported DPD
2015-12-28 16:13:08 avmike:mainmode CyberGhost: add SA 1
2015-12-28 16:13:08 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 16:13:08 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 16:13:08 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:13:08 avmike:CyberGhost: Phase 1 ready
2015-12-28 16:13:08 avmike:CyberGhost: local is behind a nat
2015-12-28 16:13:08 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:13:08 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:13:08 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:13:08 avmike:CyberGhost: start waiting connections
2015-12-28 16:13:08 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 16:13:08 avmike:CyberGhost: Phase 2 ready
2015-12-28 16:13:08 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 16:13:08 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 16:13:08 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 16:13:08 avmike:CyberGhost: start waiting connections
2015-12-28 16:13:08 avmike:CyberGhost: NO waiting connections
2015-12-28 16:13:18 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:14:38 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:14:38 avmike:FreeIPsecSA: spi=5beabc07            protocol=3 iotype=1
2015-12-28 16:14:38 avmike:FreeIPsecSA: spi=8bc3a72             protocol=3 iotype=2
2015-12-28 16:14:38 avmike:mainmode CyberGhost: del SA 1
2015-12-28 16:15:41 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 16:15:41 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 16:15:41 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 16:16:15 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 16:16:15 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 16:16:15 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 16:16:15 avmike:CyberGhost remote peer supported DPD
2015-12-28 16:16:16 avmike:mainmode CyberGhost: add SA 1
2015-12-28 16:16:16 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 16:16:16 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 16:16:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:16:16 avmike:CyberGhost: Phase 1 ready
2015-12-28 16:16:16 avmike:CyberGhost: local is behind a nat
2015-12-28 16:16:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:16:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:16:16 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:16:16 avmike:CyberGhost: start waiting connections
2015-12-28 16:16:16 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 16:16:16 avmike:CyberGhost: Phase 2 ready
2015-12-28 16:16:16 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 16:16:16 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 16:16:16 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 16:16:16 avmike:CyberGhost: start waiting connections
2015-12-28 16:16:16 avmike:CyberGhost: NO waiting connections
2015-12-28 16:16:26 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:16:32 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:16:32 avmike:FreeIPsecSA: spi=2e50ac38            protocol=3 iotype=1
2015-12-28 16:16:32 avmike:FreeIPsecSA: spi=aee796a             protocol=3 iotype=2
2015-12-28 16:16:32 avmike:mainmode CyberGhost: del SA 1
2015-12-28 16:17:03 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 16:17:03 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 16:17:03 avmike:CyberGhost start_vpn_keepalive 8.8.8.8
2015-12-28 16:17:20 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 16:17:20 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 16:17:20 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 16:17:20 avmike:CyberGhost remote peer supported DPD
2015-12-28 16:17:20 avmike:mainmode CyberGhost: add SA 1
2015-12-28 16:17:20 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 16:17:20 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 16:17:20 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:17:20 avmike:CyberGhost: Phase 1 ready
2015-12-28 16:17:20 avmike:CyberGhost: local is behind a nat
2015-12-28 16:17:20 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:17:20 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:17:21 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 16:17:21 avmike:CyberGhost: start waiting connections
2015-12-28 16:17:21 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 16:17:21 avmike:CyberGhost: Phase 2 ready
2015-12-28 16:17:21 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 16:17:21 avmike:CyberGhost stop_vpn_keepalive to 8.8.8.8
2015-12-28 16:17:21 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 16:17:21 avmike:CyberGhost: start waiting connections
2015-12-28 16:17:21 avmike:CyberGhost: NO waiting connections
2015-12-28 16:17:31 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 16:18:17 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 16:18:17 avmike:FreeIPsecSA: spi=a73d61d3            protocol=3 iotype=1
2015-12-28 16:18:17 avmike:FreeIPsecSA: spi=22b8d8              protocol=3 iotype=2
2015-12-28 16:18:17 avmike:mainmode CyberGhost: del SA 1

Packetmitschnitte habe ich auch angefertigt, weiß aber nicht so recht wie die in den Beitrag fügen soll.

Edit: 192.168.1.21 ist die Adresse der FB im Netzwerk des DSL-Routers der über lan 1 das Internet bereitstellt.

Viele Grüße, Nemo

 

[n3mo]

Hier nochmal ein sauberer Mitschnitt von gerade:

root@fritz:/var/mod/root# cat /var/tmp/ike.log
2015-12-28 16:58:48 avmike:CyberGhost: NO waiting connections
2015-12-28 16:58:58 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 17:00:37 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 17:00:37 avmike:FreeIPsecSA: spi=dfe1370a            protocol=3 iotype=1
2015-12-28 17:00:37 avmike:FreeIPsecSA: spi=38373c              protocol=3 iotype=2
2015-12-28 17:00:37 avmike:mainmode CyberGhost: del SA 1
2015-12-28 17:00:51 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=95.169.183.219 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 17:00:51 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 17:00:51 avmike:CyberGhost start_vpn_keepalive 95.169.183.219
2015-12-28 17:01:37 avmike:mainmode CyberGhost: selected lifetime: 3600 sec(no notify)
2015-12-28 17:01:37 avmike:CyberGhost remote peer supported XAUTH
2015-12-28 17:01:37 avmike:CyberGhost remote peer supported NAT-T RFC 3947
2015-12-28 17:01:37 avmike:CyberGhost remote peer supported DPD
2015-12-28 17:01:37 avmike:mainmode CyberGhost: add SA 1
2015-12-28 17:01:37 avmike:CyberGhost: switching to NAT-T (Initiator)
2015-12-28 17:01:37 avmike:CyberGhost: Warning: source changed from 95.141.28.56:500 to 95.141.28.56:4500
2015-12-28 17:01:37 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 17:01:37 avmike:CyberGhost: Phase 1 ready
2015-12-28 17:01:37 avmike:CyberGhost: local is behind a nat
2015-12-28 17:01:37 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 17:01:37 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 17:01:38 avmike:CyberGhost
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-12-28 17:01:38 avmike:CyberGhost: start waiting connections
2015-12-28 17:01:38 avmike:CyberGhost: Phase 2 starting (start waiting)
2015-12-28 17:01:38 avmike:CyberGhost: Phase 2 ready
2015-12-28 17:01:38 avmike:< cb_sa_created(name=CyberGhost,id=1,...,flags=0x00012301)
2015-12-28 17:01:38 avmike:CyberGhost stop_vpn_keepalive to 95.169.183.219
2015-12-28 17:01:38 avmike:CyberGhost start_keepalive_timer 3540 sec
2015-12-28 17:01:38 avmike:CyberGhost: start waiting connections
2015-12-28 17:01:38 avmike:CyberGhost: NO waiting connections
2015-12-28 17:01:48 avmike:>>>4500 nat-t-keepalive[95.141.28.56:4500]
2015-12-28 17:02:01 avmike:< cb_sa_deleted(name=CyberGhost,id=1,what=3)
2015-12-28 17:02:01 avmike:FreeIPsecSA: spi=5e3e6793            protocol=3 iotype=1
2015-12-28 17:02:01 avmike:FreeIPsecSA: spi=6aa35ed             protocol=3 iotype=2
2015-12-28 17:02:01 avmike:mainmode CyberGhost: del SA 1

 

[PeterPawn]

mit dem einzigen Unterschied reject_not_encrypted = yes;

Was versprichst Du Dir davon?

http://avm.de/service/vpn/praxis-ti...-verbindung-von-fritzbox-zu-fritzbox-lan-lan/

Zwar ist dort vermutlich tatsächlich gemeint, daß nicht verschlüsselter Verkehr nicht mehr erlaubt ist ... wie sich das aber auf die UDP-Pakete mit dem IPSec-Payload selbst auswirkt, ist m.W. unklar. Für mich ist das ein Relikt aus der Zeit, wo die FRITZ!Box noch als Client für den "AVM Remote-Access-Server" gedacht war.

Ansonsten sieht das für mich - trotz aller grünen LEDs - so aus, als wenn da eben genau das vermutete Problem auftritt ... nach dem Aufbau der Verbindung versucht der avmike ein (IPSec-)KeepAlive (das ist an dieser Stelle DPD und nicht einfach ein ICMP-"echo request" wie bei "keepalive_ip") an den VPN-Server zu senden, da kommt vermutlich keine Antwort (weil das Paket eigentlich unverschlüsselt zu übertragen wäre) und die Verbindung wird abgebaut (könnte irgendwie mit dem "dead" in DPD zu tun haben).

Ansonsten hast Du es auch vollkommen falsch verstanden ... ich habe kein Verlangen, mich in fremde Packet-Dumps zu vertiefen. Mein Vorschlag war von Beginn an, daß Du selbst diese Mitschnitte anfertigst und entsprechend nach markanten Paketen suchst. Wenn auf dem PC 192.168.188.23 zum Testzeitpunkt nichts anderes läuft, sollte ein "ping" oder "traceroute" zu einem Internet-Host auf der "Routing-Schnittstelle" als einzelnes ICMP-Paket noch im Klartext zu sehen sein, aus diesem Paket muß auf der "1. Internet-Verbindung" ein Paket an UDP 4500 werden, mit der Zieladresse des VPN-Servers. Geht das so über die Leitung, muß zwangsläufig vom Server auf der "1. Internet-Verbindung" auch wieder eine Antwort kommen. Diese sollte nach der Entschlüsselung dann wieder als ICMP-Paket mit einer Antwort oder einer passenden Fehlermeldung auf der "Routing-Schnittstelle" erscheinen und in der Folge an den PC gesendet werden. Irgendwo da klemmt es vermutlich ... aber das kriegt man mit etwas Anstrengung anhand der vorstehenden Beschreibung sicherlich selbst heraus. Je nachdem, was das dann konkret ist, sind die Ursachen sicherlich andere.

Mit dem "reject_not_encrypted=yes" bzw. mit einer VPN-Verbindung, wo eine SA immerhin ganze 60 Sekunden "lebt", brauchst Du aber wohl gar nicht erst mit dem Mitschnitt anfangen. Erst wenn das DPD auf der Transport-Seite klappt (das gehört eigentlich noch zum IKE bzw. arbeitet mit den dort verwendeten öffentlichen Adressen), kann auch der verschlüsselte Payload auf der anderen Seite irgendwie ankommen (so er denn überhaupt gesendet wird, was ja noch zu beweisen wäre).

 

[n3mo]

Was versprichst Du Dir davon?

Wenn ich das nicht mache, kann ich bei aktivem VPN surfen. Aber unverschlüsselt mit der IP meines DSL-Providers.

Wenn auf dem PC 192.168.188.23 zum Testzeitpunkt nichts anderes läuft, sollte ein "ping" oder "traceroute" zu einem Internet-Host auf der "Routing-Schnittstelle" als einzelnes ICMP-Paket noch im Klartext zu sehen sein, aus diesem Paket muß auf der "1. Internet-Verbindung" ein Paket an UDP 4500 werden, mit der Zieladresse des VPN-Servers. Geht das so über die Leitung, muß zwangsläufig vom Server auf der "1. Internet-Verbindung" auch wieder eine Antwort kommen.

Das werde ich dann bei Gelegnehit mal versuchen nachzuvollziehen.

 

[Riverhopper]

Hallo zusammen,

Rechner ... Adresse 192.168.188.23 ... kann nicht surfen.

hierzu fehlen mir Details

Frage: Um was für ein Rechner/Betriebssystem handelt es sich bei dem Gerät mit IP=192.168.188.23 ?
Ist hier eine Firewall ggf. aktiv ?
Hintergrund: es gab neulich hier im IPPF ein Problem mit VPN und KIS-Firewall.

Der Vorschlag von PeterPawn mit traceroute und Paket-Mitschnitt gibt sicherlich weiteren Aufschluß;

C:\> tracert www.cyberghostvpn.com
Routenverfolgung zu www.cyberghostvpn.com.cdn.cloudflare.net [162.159.240.233] über maximal 30 Abschnitte:

  1     1 ms     1 ms    <1 ms  fritz.box [192.168.155.1]
  2   159 ms     2 ms     1 ms  ISP-Netz
  3    11 ms    12 ms    13 ms  ISP-Netz
  4    10 ms     8 ms    10 ms  ISP-Netz
  5    13 ms    14 ms    15 ms  ISP-Netz
  6    15 ms    18 ms    21 ms  ISP-Netz
  7    18 ms    17 ms    26 ms  84.116.190.2
  8    16 ms    19 ms    17 ms  213.46.179.62.aorta.net [213.46.179.62]
  9    18 ms    18 ms    23 ms  ffm-bb1-link.telia.net [62.115.138.74]
 10    16 ms    19 ms    17 ms  ffm-b1-link.telia.net [62.115.116.160]
 11    20 ms    16 ms    18 ms  cloudflare-ic-311709-ffm-b1.c.telia.net [213.248.85.26]
 12    20 ms    18 ms    16 ms  162.159.240.233

Ablaufverfolgung beendet.
C:\>

Ich denke hier erhalten wir auch weitere Inputs zu Transfernetz 10.0.0.0/8 und Acceslist
in Screenshot http://www.ip-phone-forum.de/attachment.php?attachmentid=85101&d=1451213252
und Traceroute-Output https://support.cyberghostvpn.com/i.../Article/View/456/185/how-to-create-a-tracert
ist dieses Netz enthalten, ggf. ist Anpassung der accesslist wie PeterPawn in #9 schreibt erforderlich.

LG Riverhopper

EDIT: traceroute-Befehl inkl. Output auf Windows-Semantik "tracert" angepasst

 

[PeterPawn]

Wenn ich das nicht mache, kann ich bei aktivem VPN surfen. Aber unverschlüsselt mit der IP meines DSL-Providers.

Dann hast Du wohl schon da ein Konfigurationsproblem, denn die FRITZ!Box dürfte nicht ein einziges (IP-)Paket von der 192.168.188.23 unverschlüsselt auf ihren WAN-Anschluß lassen, wenn eine "accesslist" mit "permit ip 192.168.188.23 255.255.255.255 any" aktiv ist. Schon das wäre echt mysteriös ... eigentlich kann ich mir das nur so erklären, daß dann eben der fragliche PC eine andere (IPv4-)Adresse verwendet oder ein anderes Protokoll (z.B. IPv6), wobei Du davon noch gar nichts geschrieben hast. Allerdings würde vermutlich ein "reject_not_encrypted=yes" tatsächlich auch IPv6-Verkehr blockieren (könnte man glatt mal testen, wenn es einen nur interessieren würde), der mit der AVM-Implementierung ohnehin nicht per VPN übertragen werden kann (den aber vermutlich CyberGhost auch nicht unterstützen würde). Da läge es dann aber näher, IPv6 einfach abzuschalten (so es aktiv ist) - aber Du wirst schon wissen, was Du da machst. Für mich greift da nach dem Einrichten einer SA und dem Aktivieren des Tunnels schon das Senden von DPDs ins Leere ... aber das muß beileibe nicht stimmen.

 

[n3mo]

... wenn eine "accesslist" mit "permit ip 192.168.188.23 255.255.255.255 any" aktiv ist. Schon das wäre echt mysteriös ...

Ich habe festegestellt das die Subnetzmaske des Netztes der FB 255.255.255.0 ist, wenn ich das in die accesslist der cfg eintrage, erhalte ich keinen grünen Button. D.h. der Verkehr wird auch nicht getunnelt. Wenn ich das richtig verstehe bringt es dann auch nichts wenn ich mir tracerout und Packetmitschnitt anschaue wie die Pakete geroutet werden.

Das einzige was bei einem Verbindungsaufbau in das log-file geschrieben wird:

2015-12-28 23:14:37 avmike:< add(appl=dsld,cname=CyberGhost,localip=192.168.1.21, remoteip=95.141.28.56, p1ss=all/all/all, p2ss=esp-all-all/ah-all/comp-all/no-pfs p1mode=2 keepalive_ip=8.8.8.8 flags=0x9019 tunnel xauth cfgmode nat_t no_certsrv_server_auth)
2015-12-28 23:14:37 avmike:new neighbour CyberGhost:  localvirtualip-needed nat_t
2015-12-28 23:14:37 avmike:CyberGhost start_vpn_keepalive 8.8.8.8

oder ein anderes Protokoll (z.B. IPv6), wobei Du davon noch gar nichts geschrieben hast.

Frage: Um was für ein Rechner/Betriebssystem handelt es sich bei dem Gerät mit IP=192.168.188.23 ?
Ist hier eine Firewall ggf. aktiv ?

Ist ein Win 8.1 Rechner mit Windows-firewall, IPv6 ist deaktiviert. In der FB ist die Unterstützung für IPv6 deaktiviert, der Router der das Internet bereitstellt hat aber eine IPv6-Adresse, da kann ich nicht deaktivieren.

 

[PeterPawn]

Es steht zwar bestimmt schon irgendwo, aber noch einmal zur Erläuterung, was "accesslist" überhaupt macht ... damit werden die Pakete "selektiert", die per IPSec verschlüsselt zur Gegenstelle gehen. Wenn da also "permit ip 192.168.188.23 255.255.255.255 any" steht, dann heißt das Folgendes: Jedes IP-Paket, dessen Quelladresse nach dem "logischen UND" mit lauter Einsen (das ist der Hintergrund der 255.255.255.255) den Wert 192.168.188.23 hat, geht - unabhängig von der Zieladresse, eben für das Ziel "any" - durch den Tunnel zu der betreffenden Gegenstelle. Wenn da also jemand auf die Idee kommt, ein Statement "permit ip 192.168.188.23 255.255.255.0 any" einzutragen, dann kann das eigentlich kein einziges Paket selektieren (und wird es vermutlich auch nicht tun), weil das letzte Byte der Adresse einfach nicht 23 sein kann, wenn man es zuvor mit dem Wert "0" per "boolean AND" verknüpft hat. Ein solches Statement ergibt also keinen Sinn - es würde mich schon schwer verwundern, wenn AVM etwas anderes implementiert hätte, als ich versucht habe zu beschreiben. Das ist allerdings auch nicht auszuschließen ... aber es würde gegen vieles "verstoßen", was ansonsten im Netzwerkbereich so programmiert und implementiert wurde.

Wenn Du die vorstehenden Erläuterungen dann auf den zweiten Eintrag in "accesslist" anwendest, besagt die Regel "permit ip any 10.0.0.0 255.0.0.0" auch nichts anderes, als daß jedes Paket von einer beliebigen Absenderadresse (any) an eine IP-Adresse, deren Wert nach der (byteweisen) UND-Verknüpfung mit der angegebenen Maske (das sind 8 Einser-Bits und 24 Nullen) das Resultat 10.0.0.0 ergibt (wo also der erste Adressteil von Beginn an 10 war, alle anderen Bits werden durch das UND mit 0 ja gelöscht), ebenfalls in diesen Tunnel geschickt wird.

Was die FRITZ!Box aus dem Tunnel heraus erreicht, kann das lokale System nicht beeinflussen, das entscheidet die Gegenstelle. Bei der AVM-Implementierung kann sich die lokale Box auch nicht gegen Pakete von der anderen Seite "wehren" ... das ist keine Firewall, die da mit diesen Regeln umgesetzt wird, das ist (soweit man das von außen und ohne Quelltexte sagen kann) nur eine Auswahl von Paketen - mit derselben Syntax, wie sie bei Cisco's IOS für solche Listen auch verwendet wird.

Also - Dein Ansinnen, da eine Maske von 255.255.255.0 einzutragen oder überhaupt nur in Erwägung zu ziehen, solange die Adresse davor im letzten Tupel nicht ebenfalls eine 0 enthält, macht nur sehr wenig Sinn - vorausgesetzt meine Erläuterung stimmt. Bisher paßte so ziemlich alles, was ich vom AVM-IPSec gesehen habe, zu dieser Erläuterung ... ich wäre recht überrascht, wenn sich das jetzt plötzlich ändert.

Ich bin mir angesichts Deiner Einlassungen auch nicht so ganz sicher, ob Du die Konsequenzen Deiner Änderungen jeweils überblickst und dann auftretende Probleme und Fehler auch immer der richtigen Ursache zuschreibst (oder doch die Ergebnisse durcheinander wirfst), wenn Du doch mehr oder weniger "nur probierst".

Dann bleibe ich dabei, daß Du mit einer ShellFire-Box ggf. besser bedient bist, daran kannst Du nicht so viel verkonfigurieren.

EDIT: Wenn man sich die ShellFire-Box mit 2 Jahren Subscription ansieht, sind das auch nur ca. 5 EUR/Monat und Du kriegst noch die Hardware dazu ... bei CyberGhost zahlst Du auch mehr als 4 EUR pro Monat bei jährlicher Bezahlung bzw. 5 EUR (4,99) bei monatlicher Berechnung und da ist keine fertig konfigurierte Box dabei, in die Du bloß noch Deine Account-Daten eintragen mußt EDIT: nach der Beschreibung nicht einmal das, keine Ahnung, wie die authentifiziert wird.

Wenn man das vergleicht, kann man diese Lösung ja anderen nur ans Herz legen - auch wenn ich nicht weiß, welchen Durchsatz die schafft, aber so sehr weit ist das sicherlich nicht von einer MIPS-basierten FRITZ!Box entfernt (ich vermute irgendeinen ARM-Prozessor in der ShellFire-Box).

 

[n3mo]

Die Regeln der accesslist habe ich nicht durchblickt. Leider immer noch nicht.

Wenn ich mich mit OpenVPN mit dem host 4-de.cg-dialup.net verbinde, und mit der FB selbst eine traceroute zu der öffentlichen IP 109.68.230.138 mache ist der erste Punkt:

root@fritz:/var/mod/root# traceroute 109.68.230.138
traceroute to 109.68.230.138 (109.68.230.138), 30 hops max, 38 byte packets
 1  10.129.0.1 (10.129.0.1)  39.113 ms  38.879 ms  39.010 ms

Bzgl IPsec, was würde das für meine accesslist bedeuten?

"permit ip any 10.129.0.0 255.255.0.0"?

 

[PeterPawn]

Diese Frage kann man pauschal nicht beantworten ... es gibt - ohne weitere Erklärungen, was Du damit erreichen willst - eigentlich keinen Grund für diesen Eintrag, solange dort nicht irgendjemand einen Dienst auf einem Host aus 10.129.0.0/16 benutzen will (Routing ist kein Dienst in diesem Sinne).

Sollte dort z.B. ein DNS-Server zu finden sein, den man nutzen möchte, müßte man wohl etwas in dieser Richtung zusätzlich konfigurieren, denn der Absender einer solchen Anfrage von der FRITZ!Box als "DNS-Proxy" wäre ja nicht die 192.168.188.23, sondern die Box selbst mit ihrer Adresse, so daß die erste Regel für die Pakete von der 192.168.188.23 nicht greifen würde.

Gibt es hingegen eine Regel "permit ip any any" wie in #1, braucht es diesen Zusatz nicht - dann benötigt man wohl eher andere Regeln, die einigen Verkehr aus dem Tunnel heraushalten.

Mehr als die Erneuerung des Tipps, doch einfach mal den Netzwerkverkehr zu analysieren (unter den ausführlich erklärten Aspekten), fällt mir da auch nicht mehr ein ... und derartige Wiederholungen brauchen spätere Leser vermutlich wieder nicht.

Damit halte ich mich jetzt hier raus, bis "Butter bei die Fische" gegeben wurde und es um einen konkreten Fehler geht - zaubern kann keiner hier und das alles immer selbst komplett durchzuspielen, um anderen den Test zu ersparen, macht auch nur bedingt Sinn.