[Gelöst] Shrew Client: Kein VPN mehr.

musv · 7 Jun 2017

Guten Vormittag,

wie üblich beginnt die Beschreibung damit, dass ich "eigentlich" nichts geändert hab und das Problem seit ein paar Tagen aus dem Nichts aufgetaucht ist.

Kurzbeschreibung
Meine Fritzbox 7490 (FW: 6.83) ist per DynDNS erreichbar. Auf der FB ist VPN eingerichtet (Clients). Mit meinem Smartphone kann ich mich noch per VPN verbinden und zugreifen. Vom Arbeitsrechner aus kann ich noch den Tunnel aufbauen, aber weder Ping noch ssh funktionieren. Smartphone und Arbeitsrechner befinden sich dabei jedoch im gleichen Netz. Zum Einsatz auf dem Arbeitsrechner kommt Fedora 25 mit ike-2.2.1. In der Fritzbox wird mir die Verbindung als aufgebaut angezeigt (Grüner Punkt beim Status).

Logs

Code:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:1
b:auth-mutual-psk:1234jaderstehthierdrin4321
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-pfsgroup:2
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
s:client-ip-addr:192.168.109.80
s:client-ip-mask:255.255.255.0
n:client-dns-auto:0
n:client-dns-suffix-auto:1
s:network-host:meingeheimesnetz.dd-dns.de
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:client-dns-addr:127.0.0.1,192.168.109.1
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-client-data:[email protected]
s:ident-server-type:address
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:deflate
s:policy-level:auto
s:policy-list-include:192.168.109.0 / 255.255.255.0

Heimnetz ist 192.168.109.0/24, der Arbeitsrechner bekommt korrekterweise die IP 192.168.109.85 zugewiesen. Allerdings kann ich die Rechner/Fritzbox im Heimnetz weder anpingen, noch auf die Fritzboxoberfläche per VPN zugreifen.

traceroute gibt mir nur Sterne aus:

Code:

 traceroute nas.meingeheimesnetz.de
traceroute to nas.meingeheimesnetz.de (192.168.109.11), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
…
28  * * *
29  * * *
30  * * *

Die Routingtabelle:

Code:

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.214.11.94    0.0.0.0         UG    0      0        0 wlan0
10.214.11.92    0.0.0.0         255.255.255.252 U     0      0        0 wlan0
87.177.55.75    10.214.11.94    255.255.255.255 UGH   0      0        0 wlan0
192.168.109.0   192.168.109.85  255.255.255.0   UG    0      0        0 tap0
192.168.109.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

Ich komm per wlan0 über die Verbindung ins große weite Netz, ich kann den VPN-Tunnel aufbauen. Aber ich kann nicht auf die Rechner im VPN zugreifen. Wo kann ich noch ansetzen, um den Fehler zu finden?

mecir · 7 Jun 2017

nach https://avm.de/service/vpn/tipps-tr...-shrew-soft-vpn-client-einrichten-windows-10/ sollte s:client-ip-addr:192.168.109.0 sein, versuch das mal.

musv · 7 Jun 2017

Danke. Hab's geändert. Geht aber leider trotzdem nicht. Da

Code:

n:client-addr-auto:1

gesetzt war, wurde die IP sowieso (richtig) zugewiesen.

Shirocco88 · 7 Jun 2017

musv schrieb:

Die Routingtabelle:

Code:

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.214.11.94    0.0.0.0         UG    0      0        0 wlan0
10.214.11.92    0.0.0.0         255.255.255.252 U     0      0        0 wlan0
87.177.55.75    10.214.11.94    255.255.255.255 UGH   0      0        0 wlan0
192.168.109.0   192.168.109.85  255.255.255.0   UG    0      0        0 tap0
192.168.109.0   0.0.0.0         255.255.255.0   U     0      0        0 tap0

Wozu ist die Hostroute ?

Code:

87.177.55.75    10.214.11.94    255.255.255.255 UGH   0      0        0 wlan0

dieses Ziel ist doch schon in Defaultroute enthalten.

- - - Aktualisiert - - -

musv schrieb:
traceroute gibt mir nur Sterne aus:

Code:

traceroute nas.meingeheimesnetz.de traceroute to nas.meingeheimesnetz.de (192.168.109.11), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * … 28 * * * 29 * * * 30 * * *

Frage: ist auf dem Arbeitsrechner eine Firewall aktiv ? oder im Netzwerk 10.214.11.92/30 ?
Arbeitsrechner:/# iptables -L

mecir · 7 Jun 2017

meine Konfiguration weicht in mehreren Punkten ab, kannst Du mal probieren, nach der verlinkten Anleitung zunächst einen Eintrag zu erstellen, der den gesamten Traffic über das VPN leitet (das ist meine Konfiguration), und dann - falls auch diese nicht funktioniert - die Konfig nochmal zu posten damit ich das mit meiner vergleiche? Ich kann gerade leider nicht den umgekehrten Test durchführen.

musv · 8 Jun 2017

Shirocco88 schrieb:
Wozu ist die Hostroute ?

Code:

87.177.55.75 10.214.11.94 255.255.255.255 UGH 0 0 0 wlan0

dieses Ziel ist doch schon in Defaultroute enthalten.

Eigentlich schon. Die Konfiguration hab ich mit dem qikea erstellt. Die Redundanz mal dahingestellt ist das die Route zum Aufruf meiner DynDNS-IP (87.177.xxx.xxx).

mecir schrieb:
meine Konfiguration weicht in mehreren Punkten ab, kannst Du mal probieren, nach der verlinkten Anleitung zunächst einen Eintrag zu erstellen, der den gesamten Traffic über das VPN leitet (das ist meine Konfiguration), und dann - falls auch diese nicht funktioniert - die Konfig nochmal zu posten damit ich das mit meiner vergleiche? Ich kann gerade leider nicht den umgekehrten Test durchführen.

Wo finde ich denn Deine Config?

Update:
Hab gestern noch mal die Fritzbox neugestartet, heute meinen Arbeitsrechner neu gestartet. Da ich auf dem Arbeitsrechner meine Heimnetzrechner in die /etc/hosts eingetragen hab, hab ich auch mal die DNS-Auflösung per VPN deaktiviert. Meine Config sieht jetzt so aus:

Code:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:0
b:auth-mutual-psk:1234jaderstehthierdrin4321
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-pfsgroup:2
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
n:client-dns-auto:1
n:client-dns-suffix-auto:1
s:client-dns-addr:127.0.0.1,192.168.109.1
s:network-host:meingeheimesnetz.dd-dns.de
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-client-data:[email protected]
s:ident-server-type:address
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:deflate
s:policy-level:auto
s:policy-list-include:192.168.109.0 / 255.255.255.0

Und jetzt wird's interessant:

Code:

traceroute nas
traceroute to nas (192.168.109.11), 30 hops max, 60 byte packets
 1  nas (192.168.109.11)  44.842 ms  46.351 ms  48.153 ms
 2  nas (192.168.109.11)  50.146 ms  53.905 ms  55.608 ms

ping nas
PING nas (192.168.109.11) 56(84) bytes of data.
64 bytes from nas (192.168.109.11): icmp_seq=1 ttl=63 time=86.1 ms
64 bytes from nas (192.168.109.11): icmp_seq=2 ttl=63 time=19.4 ms

Das geht also problemlos.

Hingegen hängt:

Code:

ssh nas

Log ich mich über meine dd-dns.de-Adresse ein, dann klappt's:

Code:

ssh meingeheimesnetz.dd-dns.de -p 1234
X11 forwarding request failed on channel 0
Last login: Thu Jun  8 08:47:59 2017 from xxx.xxx.xxx.xxx

Von da aus, kann ich dann sogar meinen Arbeitsrechner (192.168.109.85) anpingen:

Code:

(auf der NAS)
ping 192.168.109.85
PING 192.168.109.85 (192.168.109.85) 56(84) bytes of data.
64 bytes from 192.168.109.85: icmp_seq=1 ttl=63 time=16.3 ms
64 bytes from 192.168.109.85: icmp_seq=2 ttl=63 time=19.0 ms

Wiederrum klappt curl auf den Port 80 meines Arbeitsrechners (192.168.109.85, auf dem ein Webserver läuft) nicht:

Code:

auf der NAS
 curl 192.168.109.85 80

curl: (7) Failed to connect to 192.168.109.85 port 80: Die Wartezeit für die Verbindung ist abgelaufen
curl: (7) Failed to connect to 192.168.109.85 port 80: Die Wartezeit für die Verbindung ist abgelaufen

Und laut Fritzbox-Log (fritzbox/system/support.lua) ist die VPN verbindung aufgebaut:

Code:

VPN: [email protected] connected since 2017-06-08 08:36:41 (setup time 43998 secs)
     localvirtualip 0.0.0.0 dns1 0.0.0.0 dns2 0.0.0.0

Im Fritzbox-Log (Fritzbox -> System -> Ereignisse

Code:

VPN-Verbindung zu [email protected] wurde erfolgreich aufgebaut.

Also Fazit:

VPN wird aufgebaut, Ping funktioniert, traceroute findet das Ziel.
Ports 80, 22, 21 (und vermutlich noch alle anderen) werden geblockt

Also irgendwie wird innerhalb der aufgebauten VPN-Verbindung so ziemlich alles außer Ping geblockt, die VPN-Verbindung selbst aber problemlos aufgebaut. Da ich über meine DynDNS-Adresse von außen per ssh auf mein Heimnetz komm, wird vom Arbeitsnetz aus selbst nichts geblockt. Ich bin ratlos. Vor allem, weil bis vor ein paar Tagen alles noch problemlos funktionierte.

PeterPawn · 8 Jun 2017

Je nachdem, wie ernsthaft Du das Problem angehen willst, bräuchte man für die Diagnose nun mal die Daten von der FRITZ!Box und davon ist hier bisher (mit Ausnahme von drei spärlichen Zeilen in #6) praktisch gar nichts zu sehen.

Benötigt wird sowohl die verwendete VPN-Konfiguration für diese Verbindung als auch das "ike.log" direkt nach dem Restart einer Box mit anschließendem Verbindungsversuch durch den Client. Das klingt (zumindest anhand der Beschreibung der Fehler) nach einer falschen VPN-Konfiguration in der FRITZ!Box ... auch wenn das nicht zur Versicherung passen würde, daß es bisher lief (wie lange eigentlich?) und nun plötzlich und unerwartet nicht mehr will.

Aber schon eine IP-Adresse für den Client, die auf .85 endet, kann eigentlich nicht mit einer Standardkonfiguration einer FRITZ!Box zustande kommen - da muß also schon einiges "verstellt" worden sein und ohne diese ganzen Informationen ist so eine "Fehlersuche" (wenn man fröhliches Raten überhaupt so nennen sollte) nur das Stochern im Nebel und das Finden des Basisproblems reine Glückssache.

- - - Aktualisiert - - -

~~PS: Wenn das Ping vom NAS zum Rechner tatsächlich an den VPN-Client gehen würde, paßt die RTT dort aber absolut nicht zu dem, was in der Gegenrichtung angezeigt wird.~~
Komisch, das erste Ping-Paket vom PC zum NAS braucht > 80 ms und danach geht es in weniger als 20?

musv · 8 Jun 2017

PeterPawn schrieb:
Je nachdem, wie ernsthaft Du das Problem angehen willst, bräuchte man für die Diagnose nun mal die Daten von der FRITZ!Box und davon ist hier bisher (mit Ausnahme von drei spärlichen Zeilen in #6) praktisch gar nichts zu sehen.

Was genau? Das System-Log? Da müsste ich dann einige Sachen umändern, die öffentliche Angaben enthalten.

Benötigt wird sowohl die verwendete VPN-Konfiguration für diese Verbindung als auch das "ike.log" direkt nach dem Restart einer Box mit anschließendem Verbindungsversuch durch den Client.

Danke, das iked.log hatte ich noch gar nicht auf dem Schirm. Ich werd da mal nachforschen, ob ich was find.

Aber schon eine IP-Adresse für den Client, die auf .85 endet, kann eigentlich nicht mit einer Standardkonfiguration einer FRITZ!Box zustande kommen

Ich nutz einen eigenen DHCP-Server, der auf meiner NAS läuft. Die IP-Range für VPN-Clients beginnt da ab 192.168.109.80. Die für meinen Arbeitsrechner ist mit .85 festgelegt.

~~PS: Wenn das Ping vom NAS zum Rechner tatsächlich an den VPN-Client gehen würde, paßt die RTT dort aber absolut nicht zu dem, was in der Gegenrichtung angezeigt wird.~~
Komisch, das erste Ping-Paket vom PC zum NAS braucht > 80 ms und danach geht es in weniger als 20?

Geht über Wlan und ist teilweise fragil. Deswegen ist der erste Ping etwas höher.

PeterPawn · 8 Jun 2017

Der eigene DHCP-Server interessiert für das VPN der FRITZ!Box normalerweise niemanden ... deshalb schrieb ich ja, daß Du da schon einiges an Einstellungen ändern mußt, damit es zu so einer Adresse überhaupt kommen kann. Wenn das tatsächlich eine Verbindung mit "conntype_user" ist, sollte auch in der Statuszeile im GUI die IP-Adresse des Clients stehen, die er aus Sicht der FRITZ!Box hat (und da gibt es keine Zuordnungen per DHCP, damit hat also auch der DHCP-Server auf dem NAS absolut kein "Mitspracherecht") - wenn das tatsächlich die .85 sein sollte, wurde entweder die VPN-Konfiguration "von Hand gemacht" (das kann man auch nicht erkennen) oder die DHCP-Einstellungen der FRITZ!Box (und auch wenn der DHCP-Server dort abgestellt ist, beeinflussen die weiterhin die VPN-Zuteilungen) wurden geändert (davon steht auch nichts dort).

Wie auch immer ... bei allem Verständnis für den Schutz der "Privatsphäre" - die Faktenlage wäre halt mit "dünn" noch maßlos übertrieben bewertet (auch der eigene DHCP-Server kam ja erst "nachträglich"). Ich muß leider auch konstatieren, daß die schwierigsten "Patienten" immer die sind, die das eigentlich alles selbst können wollen (was durchaus ein sehr lobenswertes Bestreben ist), aber damit im Fehlerfall auch wie vernagelt sind und an den vollkommen falschen Stellen suchen und erst einmal davon überzeugt werden müssen, daß sie (vermutlich, dafür fehlen einfach zu viele Infos) den falschen Baum verbellen.

Das geht hier schon damit los, daß mal eben zwei verschiedene "Clients" fürs VPN "erwähnt" werden (1x Linux-PC, 1x Smartphone) ... für "VPN-Kenner" ist es zwar selbstverständlich, daß dann auch für jeden Client ein eigener VPN-Eintrag existieren muß (in den allermeisten Szenarien jedenfalls) und trotzdem kann es bereits an so billigen Problemen scheitern, daß da zwei Geräte um denselben Eintrag kämpfen. Dann wäre es auch wieder kein Wunder, wenn zwar auf "ping" (also ICMP-Echo/-Reply) reagiert wird (das kann schließlich fast jedes Gerät), wenn da aber der andere Client verbunden ist und auf dem läuft eben kein Webserver auf Port 80, dann wäre das Fehlerbild auch das oben beschriebene.

Ich will auch niemandem eigene Netzwerkkompetenzen absprechen ... aber gerade dann sollte man auch wissen, daß andere nur helfen können, wenn sie wirklich alle Fakten auch kennen und dazu gehört dann die ausführliche Beschreibung - mit Konfigurationsdateien und Protokollen. Die VPN-Konfiguration würde hier eben sofort zeigen, ob die Vermutung mit dem "geteilten" Account richtig ist oder nicht bzw. ob das tatsächlich eine "conntype_user"-Verbindung ist (wobei es für ein Smartphone schon eine solche sein müßte und das soll ja funktionieren).

Das "Weglassen" von (vermutlich) irrelevanten Informationen (aus der eigenen Sicht) ist eben genau die "Krankheit" der "Halb-Admins" - man muß sicherlich nicht noch den Stromanbieter benennen und im Gegensatz zu vielen anderen fehlt in #1 weder das Modell noch der Typ oder die OS-Version der Box noch das OS, auf dem der Client läuft. Aber das war es dann auch schon fast - es kommt noch die Konfiguration des VPN-Clients (das ist ja gar kein Log, auch wenn da "Logs" drüber steht) und das zeigt doch schon sehr deutlich, daß Du das Problem eben eher auf der Client-Seite vermutest.

Die gesamten Infos zum VPN auf dieser FRITZ!Box sind nun mal extrem spärlich in diesem Thread (wobei gerade auch eine "setup time" von mehr als 12 Stunden für mich etwas komisch aussieht, aber auch da fehlt einfach das "Fleisch" zur Beurteilung der Situation) ... dabei arbeitet das VPN dort eben ausschließlich auf L3, damit kommen L2-Broadcasts gar nicht an und es funktioniert weder DHCP noch ARP, weil die beide auf L2-BC-Adressen setzen.

Also gibt es für ARP eine andere Lösung (die FRITZ!Box gibt sich als Besitzer der IP-Adresse des Clients im LAN aus - das nennt sich dann Proxy-ARP) und DHCP funktioniert in diesem Zusammenhang gar nicht. Wenn der VPN-Client seine Adresse von der FRITZ!Box kriegt, hat das mit DHCP nichts zu tun - das ist der "config mode" als IPSec-Erweiterung (von Cisco) und die IP-Adresse des Clients wird bereits in der VPN-Konfigurationsdatei festgelegt.

Das muß man zwar alles nicht aus dem Stand wissen, aber es ist hier auch mehrfach beschrieben. Wenn man also eine "Fehlerbeschreibung" zu einem VPN-Problem abgibt, dann sollte man da auch alle Umstände erwähnen, die in diese Gemengelage hineinspielen könnten ... das betrifft nur mit sehr geringer Wahrscheinlichkeit das WLAN, die DECT-Basis oder die Telefonie-Funktionen, aber zu 100% eben alle Informationen zur Konfiguration des LAN (und dazu gehört mehr als Segment und Maske) und des VPN.

So, das reicht jetzt auch ... es ist garantiert nicht nur die pure Neugierde oder gar "Beschäftigungstherapie" (in der Hoffnung, daß dabei das Problem vergessen wird oder sich von selbst erledigt), wenn immer wieder nach vollständigen Informationen gefragt wird - abgesehen davon hat sicherlich auch schon so mancher beim Niederschreiben seines Problems dann erkannt, wo er seinen Denkfehler (aus lauter Voreingenommenheit) eigentlich hatte und dann die Lösung doch noch selbst gefunden.

musv · 16 Jun 2017

PeterPawn: Erstmal einen große Dank an Dich für die viele Zeit, die du Dir nimmst.

PeterPawn schrieb:
Ich muß leider auch konstatieren, daß die schwierigsten "Patienten" immer die sind, die das eigentlich alles selbst können wollen. …Wie auch immer ... bei allem Verständnis für den Schutz der "Privatsphäre" - die Faktenlage wäre halt mit "dünn" noch maßlos übertrieben bewertet.

Ja, ist nachvollziehbar. Leider hab ich halt von VPN überhaupt keine Ahnung. Und bis vor kurzem wusste ich noch nicht mal, wo ich die Logs dazu finden kann. Wobei die jetzt für mich auch nicht gerade aussagekräftig erscheinen. Das hat jetzt auch weniger mit Privatssphäre zu tun. Vielmehr ist das eher ein Zeit- und Organisationsproblem auf meiner Seite.

ich versuch mal, ob ich alle Infos, die irgendwie weiterhelfen, auf die Reihe krieg:

Die VPN-Konfiguration meiner Fritzbox:

Code:

           local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "lnetz.dd-dns.de";
                localid {
                        fqdn = "meingeheimesnetz.dd-dns.de";
                }
                remoteid {
                        fqdn = "lnetz.dd-dns.de";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.109.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.111.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.111.0 255.255.255.0";
        } {
                enabled = yes;
                conn_type = conntype_lan;
                name = "mnetz.dd-dns.de";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "mnetz.dd-dns.de";
                localid {
                        fqdn = "meingeheimesnetz.dd-dns.de";
                }
                remoteid {
                        fqdn = "mnetz.dd-dns.de";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.109.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.110.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.110.0 255.255.255.0";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.80;
                remoteid {
                        user_fqdn = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.109.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.80;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.80 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.81;
                remoteid {
                        key_id = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "[email protected]";
                        passwd = "1234";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.81;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.81 255.255.255.255", 
                             "permit ip any 192.168.109.82 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.82;
                remoteid {
                        key_id = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "[email protected]";
                        passwd = "1234";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.82;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.82 255.255.255.255", 
                             "permit ip any 192.168.109.83 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.83;
                remoteid {
                        key_id = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
                xauth {
                        valid = yes;
                        username = "[email protected]";
                        passwd = "1234";
                }
                use_cfgmode = yes;
                phase2localid {
                        ipnet {
                                ipaddr = 0.0.0.0;
                                mask = 0.0.0.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.83;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.83 255.255.255.255", 
                             "permit ip any 192.168.109.80 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.84;
                remoteid {
                        user_fqdn = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.109.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.84;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.84 255.255.255.255";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 192.168.109.85;
                remoteid {
                        user_fqdn = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "1234jaderstehthierdrin4321";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.109.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.109.85;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = 
                             "permit ip 192.168.109.0 255.255.255.0 192.168.109.85 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

Erklärungen dazu:

meingeheimesnetz = Mein Heimnetz: 192.168.109.0/24
lnetz = Fritzbox meiner Schwester: 192.168.111.0/24
mnetz = Fritzbox meiner Eltern: 192.168.110/24
192.168.109.80 = mein Notebook (OS: Gentoo, Shrew Client 2.2.1 bestückt. Ist aber im Moment nicht konfiguriert)
192.168.109.81 = mein Smartphone (VPNCilla, = o.g. Smartphone funktioniert korrekt - auch über das Wlan meines Arbeitgebers, an dem der problematische Arbeitsrechner hängt. Das Wlan ist insofern erwähnenswert, da dadurch irgendwelche Firewallrestriktionen ausgeschlossen werden können.)
192.168.109.82 = Smartphone meiner Frau (VPNCilla, Einwahl per VPN funktioniert, für Problematik hier irrelevant)
192.168.109.83 = Tablet meines Sohnemannes (VPNCilla, Einwahl per VPN funktioniert, für Problematik hier irrelevant)
192.168.109.84 = Rechner meiner Schwägerin, Arch Linux + Shrew Client. Einwahl per VPN funktinioiniert(e) problemlos. Allerdings wohnt sie sehr weit weg und hat den Rechner aus Hausbaugründen vom Netz abgestöpselt. Ich hatte den Rechner seit 5 Monaten nicht mehr in Betrieb.
192.168.109.85 = mein Arbeitsrechner, das Problemtier, um das es hier geht, OS: Fedora 25, Shrew Client: 2.2.1

Jetzt noch die ~/.ike/sites/meingeheimesnetz.dd-dns.de auf meinem Arbeitsrechner:

Code:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:0
b:auth-mutual-psk:U2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx==
n:phase1-dhgroup:2
n:phase1-keylen:256
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:256
n:phase2-pfsgroup:2
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:0
s:client-ip-addr:192.168.109.0
s:client-ip-mask:255.255.255.0
n:client-dns-auto:0
n:client-dns-suffix-auto:1
s:client-dns-addr:192.168.109.1
s:network-host:meingeheimesnetz.dd-dns.de
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk
s:ident-client-type:ufqdn
s:ident-client-data:[email protected]
s:ident-server-type:address
s:phase1-exchange:aggressive
s:phase1-cipher:aes
s:phase1-hash:sha1
s:phase2-transform:esp-aes
s:phase2-hmac:sha1
s:ipcomp-transform:deflate
s:policy-level:auto
s:policy-list-include:192.168.109.0 / 255.255.255.0

General: Local Host - Address Method: Use virtual adapter and assigned address, [x] obtain automatically
Name Resolution: [ ] Enable DNS. Hab die Namensauflösung in die /etc/hosts eingetragen.

Versuch ich mich mit qikec -a -r arbeitsrechner.dd-dns.de zu verbinden, bekomm ich in /var/log/iked.log (auf dem Client):

Code:

17/06/16 08:14:05 !! : invalid private netmask, defaulting to 255.255.255.0
17/06/16 08:14:15 !! : config packet ignored ( config already mature )
17/06/16 08:14:35 !! : config packet ignored ( config already mature )

Dazu meine aktuelle Client-Netzwerkonfiguration. Wlan0 bekomm ich per DHCP konfiguriert. Tap0 wird per VPN konfiguriert. Da ich auf dem Client "automatisch beziehen" ausgewählt hab, kommt die Config von meiner Fritzbox.

Code:

ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 84:16:f9:0e:5c:5b brd ff:ff:ff:ff:ff:ff
    inet 10.214.11.93/30 brd 10.234.11.95 scope global dynamic wlan0
       valid_lft 43254sec preferred_lft 43254sec
    inet6 fe80::8616:f9ff:fe0e:5c5b/64 scope link 
       valid_lft forever preferred_lft forever
6: tap0: <BROADCAST,UP,LOWER_UP> mtu 1380 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether d2:83:70:cb:29:f8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.109.85/24 brd 192.168.109.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::d083:70ff:fecb:29f8/64 scope link 
       valid_lft forever preferred_lft forever

Code:

ip route show
default via 10.234.11.94 dev wlan0 
10.214.11.92/30 dev wlan0 proto kernel scope link src 10.214.11.93 
87.177.12.52 via 10.214.11.94 dev wlan0 proto static 
192.168.109.0/24 via 192.168.109.85 dev tap0 proto static 
192.168.109.0/24 dev tap0 proto kernel scope link src 192.168.109.85

Eine Firewall ist nicht aktiviert:

Code:

iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Es sind zwar IPv6-Adressen vergeben, IPv6 ist aber deaktiviert.

Code:

cat /etc/sysctl.d/20-disable_ipv6.conf 
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wlan0.disable_ipv6 = 1
net.ipv6.conf.tap0.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1

PeterPawn schrieb:
dabei arbeitet das VPN dort eben ausschließlich auf L3, damit kommen L2-Broadcasts gar nicht an und es funktioniert weder DHCP noch ARP, weil die beide auf L2-BC-Adressen setzen. Also gibt es für ARP eine andere Lösung (die FRITZ!Box gibt sich als Besitzer der IP-Adresse des Clients im LAN aus - das nennt sich dann Proxy-ARP) und DHCP funktioniert in diesem Zusammenhang gar nicht.

Hab ich jetzt nicht 100%-ig verstanden. Die Adressen sind, wie in obiger Config ersichtlich, statisch.

PeterPawn schrieb:
das betrifft […] aber zu 100% eben alle Informationen zur Konfiguration des LAN (und dazu gehört mehr als Segment und Maske) und des VPN.

Gut, was brauchst du noch?

PeterPawn · 16 Jun 2017

Wer oder was hat denn die diversen "accesslist"-Regeln für die VPN-Einträge mit "conntype_user" konfiguriert und wenn Du das "von Hand" warst, was wolltest Du damit erreichen bzw. was hast Du Dir dabei gedacht?

Am anderen Ende einer solchen Verbindung sitzt ein einzelner Client und das müßte schon eine sehr spezielle Software sein (praktisch ein Router, der in Richtung auf das FRITZ!Box-VPN dann Masquerading macht), damit da irgendeine Regel mit einer anderen Adresse als der des "eigentlichen" Ziels überhaupt Sinn ergibt ... und Du machst das hier gleich mehrfach. Damit verblüfft es mich schon, daß diese Verbindungen nach Deinen Worten ohne Probleme arbeiten sollen ... spätestens bei mehreren aktiven Clients dürfte das schwierig werden, weil die Reihenfolge der Selektoren dann vorgibt, welche Daten wohin gesendet werden sollen. Wie da die .81 bis .83 parallel über VPN funktionieren sollen, verstehe ich einfach nicht ... und irgendwie kann ich das auch nicht so richtig glauben, daß das reibungslos klappt.

So, wie die Einträge im Moment dort stehen (ohne jede Erklärung, was sie bewirken sollen), sind sie schlicht falsch und welche Effekte das dann hervorruft, kann man nur raten - es ist sicherlich auch nicht so schwer, die VPN-Protokolldaten aus den Support-Daten einer FRITZ!Box zu extrahieren.

Wobei das auch erst dann Sinn macht, wenn die Fehler in den o.a. "accesslist"-Einträgen alle beseitigt wurden ... ich rätsele immer noch, was dieses "Ring-Routing" zwischen .80 bis .83 eigentlich bewirken soll bzw. was man da so falsch verstanden haben könnte, daß etwas derartiges dabei herauskommt.

Auch wenn die "problematische" Verbindung hier die .85 sein soll (warum verwendet die denn nun keinen "cfgmode", habe ich das oben so falsch interpretiert?), sorgt der Rest (inkl. der "Unsauberkeiten" bei der Konfiguration) nur für Verwirrung. Für die Diagnose, was das Problem mit der .85 nun wirklich ist, würde ich alle anderen Verbindungen mal deaktivieren (dann werden auch die Proxy-ARP-Einträge und die Selektoren nicht erzeugt) und dann endlich(!) mal im VPN-Protokoll einer (frisch gestarteten) FRITZ!Box nach dem ersten Verbindungsversuch durch diesen PC nachsehen, was da nun wirklich passiert. Erst dann, wenn die Verbindung definitiv steht, lohnt es sich überhaupt, mit einem Paket-Mitschnitt weiter zu suchen, wo ggf. irgendwelche Pakete abbleiben könnten. In der Support-Datei stehen dann auch die restlichen Angaben zum VPN ... angefangen bei den - aus den "accesslist"-Einträgen generierten - Selektoren für die Daten, die über eine VPN-Verbindung gehen sollen.

musv · 19 Jun 2017

Du machst es mit Deiner "direkten" Art einem nicht ganz leicht. Nicht jeder ist so ein Profi und kann alle möglichen Logs ausgraben. Ich hab Dir 'ne PN geschickt mit den Logs, die ich noch auftreiben konnte. Ich hab bis auf ein Shrew-Client-VPN alle anderen VPNs aus der Fritzbox gelöscht und die Fritzbox neugestartet.

PeterPawn schrieb:
Wer oder was hat denn die diversen "accesslist"-Regeln für die VPN-Einträge mit "conntype_user" konfiguriert und wenn Du das "von Hand" warst, was wolltest Du damit erreichen bzw. was hast Du Dir dabei gedacht?

Hab die Access-List-Regeln jetzt korrigiert. Ich hatte die mal vor langer Zeit mit wine und dem Fritz-Fernzugang zusammengebastelt. Und als dann Rechner hinzukamen, hab ich die Sections kopiert und angepasst. Dabei sind mir offensichtlich ein paar Fehler passiert. Niemand ist perfekt.

PeterPawn schrieb:
und irgendwie kann ich das auch nicht so richtig glauben, daß das reibungslos klappt.

Es hat jahrelang reibungslos funktioniert.

PeterPawn schrieb:
warum verwendet die denn nun keinen "cfgmode",

Wurde so vom Fritz-Fernzugang konfiguriert.

PeterPawn schrieb:
Für die Diagnose, was das Problem mit der .85 nun wirklich ist, würde ich alle anderen Verbindungen mal deaktivieren]

Hab ich gemacht.

Ich hab jetzt mal Folgendes getestet. Da die Smartphone-Sections mit VPNCilla funktionieren, hab ich die mal extrahiert und versucht, mit dem Shrew Soft Client zu verbinden. Der Tunnel wird sofort aufgebaut. Aber auch da blockt jedweder Versuch, irgendwas über den Tunnel zu schicken.

Dann hab ich mal den Assistenten der Fritzbox verwendet, aber da komm ich beim Verbindungsversuch bis zu:

brining up tunnel…
negotitation timeout occured
tunnel disabled

PeterPawn schrieb:
(dann werden auch die Proxy-ARP-Einträge und die Selektoren nicht erzeugt)

Mit Proxy-ARP-Einträgen und Selektoren kann ich leider nichts anfangen.

Update:
Entweder darf ich keine PNs verschicken oder du willst keine erhalten. Damit lass ich das mit dem Fritzbox-Log. Ist mir zu unsicher, wenn die ganze Weltöffentlichkeit das sehen kann.

PeterPawn · 19 Jun 2017

Ich weiß zwar nicht, was Dich "an meiner Art" nun konkret stört ... aber das ist hier nun mal ein öffentlich einsehbares Forum und beim Versuch, Dir bei Deinem eigenen, ganz persönlichen Problem zu helfen, sollte - so ganz nebenbei - auch noch eine Möglichkeit für andere "abfallen", sich bei einem ähnlichen Problem hier etwas abzuschauen.

"Support" leiste ich grundsätzlich nur über das Forum ... und wenn Du mit einem vorhergehenden Hinweis auf vorhandene (und benötigte) Protokolle nichts anfangen kannst (so verstehe ich das "nicht jeder ist ein Profi" jedenfalls), dann hilft mit ziemlicher Sicherheit die Suchfunktion (entweder die des Forums oder auch Google mit der Beschränkung auf diese Site) weiter. Aus einer (hoffentlich hilfreichen) Antwort leitet sich noch keine Verpflichtung ab, das nun noch einmal alles haarklein zu erklären, was an anderen Stellen bereits mehrfach und aus (vermutlich) allen denkbaren Blickwinkeln beleuchtet wurde.

Bei aller "Hilfsbereitschaft" braucht es also auch eigene Initiative und wenn Du der Ansicht bist:

musv schrieb:
Mit Proxy-ARP-Einträgen und Selektoren kann ich leider nichts anfangen.

und diese Feststellung nicht zum Anlass nimmst, Dich an dieser Stelle dann "schlau zu machen" (auch das findet sich mehrfach hier im IPPF und "proxy ARP" habe ich selbst in #9 noch einmal "erklärt"), dann bin ich ohnehin der falsche Ansprechpartner.

Damit drücke ich Dir die Daumen, daß sich jemand anderes findet oder Du Dein Problem selbst in den Griff bekommst.

musv · 19 Jun 2017

PeterPawn schrieb:
Damit drücke ich Dir die Daumen, daß […] Du Dein Problem selbst in den Griff bekommst.

Ist soeben geschehen. Ich hab die Verbindung hinbekommen. Meine Vermutung war richtig.

Auf der AVM-Seite wird der Shrew Soft Client 2.2.2 empfohlen. Dummerweise gibt's für Linux nur die 2.2.1. aus dem Juni 2013. Warum meine (wenn auch leicht fehlerhafte Konfiguration) bis vor 2 Wochen noch tadellos funktionierte und dann plötzlich stoppte, weiß ich nicht. War vermutlich ein Linux-System-Update, wodurch der Shrew VPN Client dann irgendwie inkompatibel wurde. Das ist aber reine Spekulation.

Gestern hab ich dann wieder einige Stunden in die Fehlersuche investiert:

Support-Log durchwühlt: Da wird die Verbindung erfolgreich aufgebaut, keine Fehler. Datenverkehr ist allerdings Fehlanzeige.
Konfiguration über den Assistenten der Fritzbox-Weboberfläche zusammengeschraubt: Damit konnte ich nicht mal den Tunnel aufbauen.

Die Lösung war dann, den Shrew VPN Client in die Tonne zu treten und stattdessen VPNC einzusetzen.
https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-unter-linux-einrichten/
https://forum.ubuntuusers.de/topic/16-04-vpn-mit-fritzbox-so-funktioniert-es/

Den Networkmanager hab ich mir gespart. Der Aufruf von VPNC verlangt 5 Eingaben und schon steht die Verbindung. Die Unmengen an Konfigurationen, die der Shrew VPN Client mit sich brachte, konnte ich mir hier sparen.

Languages

Suche

Languages

Suche

[Gelöst] Shrew Client: Kein VPN mehr.

musv

Neuer User

mecir

Neuer User

musv

Neuer User

Shirocco88

Aktives Mitglied

mecir

Neuer User

musv

Neuer User

PeterPawn

IPPF-Urgestein

musv

Neuer User

PeterPawn

IPPF-Urgestein

musv

Neuer User

PeterPawn

IPPF-Urgestein

musv

Neuer User

PeterPawn

IPPF-Urgestein

musv

Neuer User

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums