[Gelöst] VPN-Tunnel für Internet Traffic ohne Zugriff aufs LAN

[andiling]

Soll/darf denn die Kommunikation untereinander möglich sein?

 

[t7490]

Benötigt wird die Kommunikation nicht. Ich habe es eben mal getestet und es geht wider Erwartens doch nicht.
Vermutlich routet die FB generell nicht von einem Tunnel Interface in ein anderes Tunnel Interface? Oder sind Setups bekannt wo Traffic von einem in den anderen Tunnel funktioniert?

 

[PeterPawn]

Oder sind Setups bekannt wo Traffic von einem in den anderen Tunnel funktioniert?

Ja, es gibt funktionierende Szenarien, wo ein entferntes Netz nur unter Vermittlung einer dritten FRITZ!Box erreichbar ist.

Allerdings sind das dann tatsächlich Tunnel-Mode-Connections (jeweils LAN-LAN zwischen den Boxen) und nicht - wie in Deinem Falle - Transport-Mode.

Ob es auch mit Transport-Mode theoretisch machbar wäre, würde ich sogar bejahen ... aber dann müssen natürlich die Clients alle die richtigen Routen haben, was bei Dir ja schon durch die unterschiedlichen Subnetze nicht automatisch passiert oder der Tunnel ist immer das Default-Gateway (ist das bei allen verwendeten Clients so?). Nach meinem Verständnis ist das von VPN-Client zu VPN-Client verschieden (gerade bei Smartphones/Tablets, wo man nicht mal kurz eine zusätzliche Route definieren kann) und so muß man sich jeden Fall einzeln anschauen.

Wenn die Clients ganz normal "192.168.117.xxx/24" kriegen würden (dann funktioniert auch die automatische Verwaltung der Verbindungen mit dem AVM-GUI), klappt zumindest mal das Routing und die Interface-Konfiguration automatisch und den Kontakt für den Rest des LAN zu einem VPN-Client (oder umgekehrt) kann man immer noch über die "accesslist" einschränken (das ist dann allerdings wieder Handarbeit). Leider annonciert die FRITZ!Box entweder für Transport-Mode keine Netzwerkmaske oder eine Maske mit /32 ... die Annahme dazu basiert auch auf einem Shrewsoft-Log, wo die Zeile

invalid private netmask - defaulting to 255.255.255.0

zu finden ist. Wenn ich das aber zusammen mit anderen Angaben richtig interpretiere, wird bei mir am Ende für das vnet-Interface die Konfiguration 192.168.xxx.201/24 gesetzt, was dann auch ohne spezielle Route den Traffic zum xxx-Netz richtigerweise über den Tunnel leitet (ist dann ja link-lokal zu diesem Adapter).

Ich habe mir jedenfalls mal die Routing-Tabelle von Windows mit aktiver VPN-Verbindung angesehen ... da verläßt sich der Shrewsoft-Client auf die Metrik-Angaben bei der Auswahl der richtigen Routen; ob das gleichzeitig die "Policies" sind und einfach alles am VPN-Adapter verschlüsselt wird (wenn eine passende SA existiert), weiß ich jedoch auch nicht.

Es wird eben einfach zur "normalen" Default-Route des Systems bei mir noch eine zweite Default-Route (ebenfalls link-lokal, mit der Client-IP des VPN als Interface-Adresse und) mit einer Metrik von 31 erzeugt (die "normale" hat 120) und damit ist klar, warum der Verkehr erst mal an den VPN-Adapter geht und nicht an das "normale" Interface. Die zweite temporäre Route (mit Metrik 21, also höher priorisiert als die erste) wird dann zum VPN-Gateway (also der FRITZ!Box) direkt über das Standard-Interface - aber eben als Host-Route - gelegt, damit wird der bereits verschlüsselte Verkehr - der ja jetzt die IP-Adresse der FRITZ!Box beinhaltet als Ziel - wieder an den richtigen (physikalischen) Adapter gesendet.

Aber auch das ist eben ein system- bzw. clientspezifisches Vorgehen und das muß noch lange nicht bei jeder VPN-Client-Software so sein. Ob und wie das Verwenden des Tunnels als Default-Gateway z.B. mit FRITZ!Fernzugang überhaupt möglich wäre (hat der eine passende Option?) wäre schon die nächste Frage - zumindest wenn man das VPN generell als Tunnel für alle Clients in unsicheren WLAN-Netzen verwenden will. Da FRITZ!Fernzugang keinen speziellen VPN-Adapter hat, an den man die Pakete routen könnte, muß das da ja etwas anders laufen ... spontan würde ich wieder auf eine "accesslist" tippen, anhand der die Software als Filter (so wird sie jedenfalls an das Interface gebunden) arbeitet.

Daß ich das "Verteilen" der VPN-Clients der FRITZ!Box über verschiedene Subnetze nicht für zielführend/sinnvoll halte, hatte ich - glaube ich jedenfalls - schon mal geschrieben. Warum ... weil das mehr oder weniger bei vielen Clients auch nur dann funktioniert, wenn da gar kein gezieltes Routing am VPN-Adapter stattfindet. Nach dem, was Du bisher an Konfigurationen hier gezeigt hast, kennen die Clients das Netz an der FRITZ!Box ja gar nicht und der Traffic geht nur durch den Tunnel, wenn ein Client den ohnehin als Default-Route verwendet. Wenn der Shrewsoft-Client den Adapter (steht als "Shrew Soft Virtual Adapter" in ipconfig) als 192.168.118.201/24 konfiguriert (kannst Du ja leicht prüfen), dann kriegt der ja ohne den Shrewsoft-Adapter als Default-Gateway nicht einmal eine Verbindung zur FRITZ!Box (unter 192.168.117.1) gebacken - egal, was in der "accesslist" der FRITZ!Box stehen mag - und würde ohne Default-Route nicht mal den DNS-Proxy der FRITZ!Box erreichen.

Bei einigen Clients (z.B. dem vom iOS) läßt sich das mit dem "alles durch den Tunnel" meines Wissens gar nicht gesondert einstellen ... da würde es mich ohnehin schon verblüffen, wenn überhaupt der gesamte Traffic durch den Tunnel geleitet werden kann.

Vielleicht hat ja jemand einen aktuellen iOS-Client bei der Hand und kann (z.B. über Tethering auf einem PC hinter dem iOS-Gerät) mal mit einem "traceroute"/"tracert" überprüfen, ob da tatsächlich der gesamte Verkehr verschlüsselt über die FRITZ!Box abgewickelt wird ... es spricht in meinen Augen einiges dagegen, ich könnte mir aber auch erklären, warum es doch so läuft. Nur ein "mal so, mal so"-Verhalten wäre etwas merkwürdig und eine Option gibt es eben m.W. nicht.

Was passiert denn im Moment bei Dir bei einem "ping" oder sogar einem "traceroute" von Client zu Client (und welche sind das)? Irgendwo muß der Traffic ja hängenbleiben - wenn er bis zur Box kommt, sollte er dort auch wieder den kompletten IP-Stack (inkl. Routing seitens der FRITZ!Box) passieren und tatsächlich bei einem anderen Client wieder aufschlagen ... dabei sind aber irgendwelche "accesslist"-Einstellungen bei Dir nicht berücksichtigt, nur die "normalen", die eigentlich nur aus "permit ip any 192.168.117.xxx 255.255.255.255" bestehen würden.

Alles andere, was Du da über die "accesslist" zu zaubern versuchst, ist mir zu anstrengend zum Mitdenken und ich staune - nach meinem bisherigen Verständnis - sogar ein wenig, wenn da überhaupt "reject"-Regeln wirken sollten ... es ist eben keine Firewall, da macht "reject" ja vielleicht in unseren Augen Sinn (und müßte dann als "normal weiterleiten" interpretiert werden), aber ein "Selektor", der sagt "Du kommst hier nicht rein." ist schon ein wenig merkwürdig (das ist dann ja eigentlich auch ein "Rejector" ).

Das kannte ich jedenfalls bisher so nicht (habe ich aber auch noch nie probiert, weil ich noch nie vor dem Problem stand) ... wenn ich mir die Zeichenketten in der Firmware, die mutmaßlich mit der VPN-Konfiguration - bzw. eher mit den Firewall-Regeln, denn nach meinem Verständnis hat da AVM die Syntax (die ja vmtl. ursprünglich sogar von Cisco stammt, aber auch bei AVM schon zu Zeiten des ISDN-MPR zu finden ist) da nur übernommen - im Zusammenhang stehen, dann würde ich dem Gefühl nach eher auf "deny" anstelle von "reject" setzen, wenn es überhaupt berücksichtigt wird (wie gesagt, nie getestet). Es ist nach meinem Verständnis schon ein Unterschied, ob ein Paket von A nach B mit "reject" komplett abgelehnt wird oder mit "deny" eben nicht für den Tunnel selektiert wird. Bei dem hier verwendeten Szenario ist das zwar wg. der /32-Maske für das "reject" noch kein großer Unterschied, wenn da mehrere Adressen betroffen sind, ist das ggf. schon wieder etwas anders.

Aber ich bin mir ja wie gesagt nicht einmal ganz sicher, ob das "reject" bei Dir überhaupt erforderlich ist oder wirksam wird.

Eine "Gegenprobe" (d.h. eine Verbindung ohne die zwei zusätzlichen Regeln (DNS + reject)) müßte ja dann volle Konnektivität zwischen dem Host und jedem beliebigen Client im LAN ergeben (auch bei den getrennten Subnetzen wie bei Dir) ... ohne die genaue Kenntnis, welche Clients (außer Shrewsoft) mit welchen Settings da am Ende verwendet werden (vor allem die resultierende Netzwerk-Konfiguration eines Shrewsoft-vnet-Adapters - s.o. - wäre mal interessant), ist das nur schwer einzuschätzen.

Wenn die Ursache für diese (gewollte) Nichterreichbarkeit des LAN am Ende in den unterschiedlichen Subnetzen liegt, bewirkt die Regel aber vielleicht gar nichts. Schon die Frage, ob/wie die FRITZ!Box da intern die Route zu den VPN-Hosts setzt und ob sie Proxy-ARP macht oder nicht (es ist ja eigentlich nicht erforderlich, ist ja alles nicht link-lokal - bei einer Adresse aus 192.168.117.0/24 für die Clients macht sie das aber so), kann den/einen entscheidenden Unterschied machen. An vielen Stellen ist das AVM-VPN eben eine Blackbox ... so ein Test ohne Gegenprobe kann leicht falsche Schlußfolgerungen suggerieren.

Bei LAN-LAN-Verbindungen (da sind unterschiedliche Subnetze ja praktisch Pflicht) richtet die Box jedenfalls keine Routen bei sich ein ... das fiel mir früher regelmäßig auf die Füße, weil bei mir eine Regel für 192.168.0.0/16 in Richtung LAN aktiv ist und die für VPN-Verbindungen zu 192.168.xxx.0/24-Netzen gezielt mit einer Route Richtung "dev dsl" überschrieben werden muß (ansonsten verläßt sich FRITZ!OS eben darauf, daß der Traffic für fremde Netze - alles, was nicht LAN ist - irgendwann schon auf "dev dsl" vorbeikommen wird. Wie das in der Auswertung einer fremden Netzwerk-Adresse für eine "Host-LAN"-Verbindung am Ende aussieht und was die Box daraus für Einstellungen macht, kannst Du nur selbst ermitteln.

BTW: Es gibt in der FRITZ!Box nicht mehrere Tunnel-Interfaces ... es gibt theoretisch nicht ein einziges. Der gesamte IPSec-Traffic läuft über "dev dsl", also das WAN-Interface.

 

[t7490]

Zu deinen Fragen bezüglich des Routings auf den Clients:
Bei allen von mir getesteten Client Systemen (Win8.1+ShrewSoft, IOS, Android 5.1) wird bei oben geposteter Config die Default Route in den VPN Tunnel gesetzt. Unter Windows lässt sich das wie du ja schon geschrieben hast relativ einfach in der Routing Tabelle prüfen. Das der Internet-Traffic der Smartphones auch über das Fritzbox VPN geroutet wird, erkennt man am besten indem man einen Packet Capture auf das Routing-Interface der Fritzbox macht. Hier kam sämlichter Internet Traffic von IOS und Android vorbei.
Die Routen (in dem Fall die Default-Route) für den VPN-Client werden von der Fritzbox im Config-Mode übergeben. Daher sollte das Routing auf allen Endgeräten gleich sein (vorrausgesetzt, dass die Geräte die Routen auch korrekt anwenden).

Zu deinen Fragen bezüglicher der ACL:
Ich bin ebenfalls zunächst von einem DENY (wie bei Cisco) in der ACL ausgegangen. In einer vpn.cfg die ich beim Testen mit dem AVM Tool erstellt hatte, waren aber REJECT statements in der acl, die das Tool generiert hat. Sonst wäre ich auch nicht darauf gekommen, das AVM reject statt deny verwendet.
Die ACL funktioniert definitiv so wie sie soll. Die Fritzbox beantwortet DNS-Anfragen der VPN-Clients aber lässt sich nicht anpingen oder anderweitig ansprechen. Das LAN ist ebenfalls nicht erreichbar. Der Internet-Traffic wird durch die Fritzbox geroutet. Also alle Einträge der ACL greifen.

Warum die VPN Clients aus den Unterschiedlichen Netzen nun nicht miteinader reden können, habe ich nicht weiter verfolgt, da die Kommunikation nicht erforderliche ist.
Da beide Clients jedoch eine Default-Route in den Tunnel haben, muss die FB irgendwie dazwischen funken. Das könnte man sicher noch genauer analysieren aber aktuell besteht das für mich kein Bedarf.

btw: Ein IPSec-VPN-Client verwendet genau wie ein Site2Site VPN den IPSec Tunnel-Mode. Der Transport-Mode ist da fehl am Platz.

 

[eisbaerin]

In einer vpn.cfg die ich beim Testen mit dem AVM Tool erstellt hatte, waren aber REJECT statements in der acl, die das Tool generiert hat.

Wie hast du das geschafft? Das ist mir noch nicht geglückt
Ich kenn' dort immer nur "permit".

 

[PeterPawn]

btw: Ein IPSec-VPN-Client verwendet genau wie ein Site2Site VPN den IPSec Tunnel-Mode. Der Transport-Mode ist da fehl am Platz.

Das stimmt natürlich ... der Shrewsoft-Client kann nicht mal Transport-Mode, andere Clients wie AnyConnect aber schon.

Schon um NAT-T überhaupt beim Peer anbieten zu können, muß ja der Tunnel-Mode verwendet werden ... manchmal ist man so in den eingefahrenen Gleisen gefangen, daß man gar nicht merkt, was man für einen Mist schreibt.

Am Ende weiß ich gar nicht, ob die AVM-Implementierung überhaupt den Transport-Mode (als Client oder als Gateway) beherrscht, auch ob sie tatsächlich bei passenden Settings in der ipsec.cfg mit "AH only" etwas anfangen könnte (manchmal reicht ja die Identität und man kann auf Verschlüsselung verzichten, z.B. beim Übertragen von Videos), interessiert mich schon etwas länger, da ich eine VPN-Verbindung habe, über die ich "Massendaten" in Form von Fernsehaufnahmen in der Familie weitergebe und da eine 7390 involviert ist, die schwer ins Keuchen kommt bei solchen Übertragungen.

Die Beobachtung zu den Routing-Tabellen bei der AVM-Implementierung bleibt aber gültig, auch im Tunnel-Mode wird da Proxy-ARP gemacht und die entsprechende Route zur Client-Adresse über "dev dsl" gesetzt, sonst kommt der Traffic nicht an den Transformationen an.

Aber das ist wohl der "eigentliche" Unterschied zwischen "conntype_user" und "conntype_lan" (und nicht meine Interpretation "conntype_user" == transport_mode) ... der eine Modus arbeitet mit Proxy-ARP und spezieller Route, weil ja die Adresse sonst Bestandteil des LAN wäre und die anderen Clients den Remote-Client nicht erreichen können (auch nicht als "Rückweg", wenn er etwas von ihnen will) und der andere Modus baut direkt darauf, daß das entfernte LAN "teilerfremd" zum LAN ist und ohnehin die Box selbst das Gateway ist, so daß da der Traffic implizit über "dev dsl" geht. Was mich mal interessieren würde (oder habe ich das überlesen), ist, wie die vom FRITZ!OS eingerichteten Routen am Ende aussehen, wenn man wie Du "fremde Netze" für die VPN-Clients verwendet.

Ob der Config-Mode damit auch noch direkt zusammenhängt (es gibt ja eigentlich eine gesonderte Option dafür), sollte man vielleicht auch erst einmal ausprobieren, ehe man es gedanklich immer automatisch mit der Notwendigkeit der Konfiguration einer IP-Adresse für den Client assoziiert.

Auch wie sich die Box als Client ggü. einem Firmen-VPN-Gateway tatsächlich verhält, habe ich nie wirklich getestet und immer "Client im Transport-Mode" assoziiert, was auch falsch sein dürfte. Auch das ist wohl ein LAN2LAN-VPN (ein schneller Test ergibt "conntype_out" und cfgmode=yes), denn die FRITZ!Box ist ja Router für die anderen Clients im LAN und kann selbst mit einer VPN-Verbindung gar nichts anfangen. Die beim Test entstandene Verbindung habe ich mir auch eben erst das erste Mal so richtig angesehen. Um wirklich zu ergründen, was diese Connection von LAN2LAN unterscheidet, muß ich wohl mal damit eine Verbindung zum racoon aufbauen und die Logs dann dort auch vergleichen, einfach weil man beim racoon das Loglevel steuern kann im Gegensatz zur FRITZ!Box.

Danke, daß Du mich endlich mal auf diesen Trugschluß mit dem Transport-Mode aufmerksam gemacht hast ... selbst mit Kenntnis des Unterschieds habe ich gar nicht weiter darüber nachgedacht und diesen Unsinn schon an einigen Stellen geäußert. Das verkneife ich mir in Zukunft ... auch wenn viele mit "site2host" sicherlich noch weniger anfangen können; die künftige Verwendung des conntype-Parameters von AVM zur Unterscheidung des "Verbindungszwecks" ist sicherlich eher zu empfehlen.

Wenn Du etwas experimentieren willst, das AVM-VPN kennt auch noch einen Typen "conntype_undefined" ... auch die Parameter für eine zertifikatsbasierte Authentifizierung (womit dann ja auch "main mode" in P1 trotz dynamischer Adresse möglich wäre, was der avmike wohl auch kann), sind vorhanden. Ich dachte mal, daß ich das fast gegen meinen racoon zum Laufen bekommen hätte (es war wohl eigentlich mal dazu gedacht, mit einem "AVM Access Server" zu verbinden); dann kam AVM mit Änderungen beim Handling des Boxzertifikats in der 06.20 um die Ecke und ich habe das irgendwie aus den Augen verloren, weil ich davon ausging, daß auch dafür das Box-Zertifikat verwendet werden würde/könnte und erst mal die Entwicklung abwarten wollte.

 

[t7490]

Wie hast du das geschafft? Das ist mir noch nicht geglückt
Ich kenn' dort immer nur "permit".

Keine Ahnung wie genau die Datei entstanden ist. Ich habe diverse Optionen durchgeklickt. Aber hier das original file, das generiert wurde.
Interessant ist auch, dass da neben dem VPN Profil mit den REJECT Commands auch noch ganz andere Config Sections drin gelandet sind, die wohl u.a. einige ICMP Parameter und NAT Table Timeouts manipulieren...

/*
 * C:\Users\xxx\AppData\Roaming\AVM\FRITZ!Fernzugang\fritzbox_domain_de\usernamed\vpnuser_usernamed.cfg
 * Sat Jun 27 17:12:30 2015
 */

version {
        revision = "$Revision: 1.30 $";
        creatversion = "1.1";
}


pwcheck {
}


datapipecfg {
        security = dpsec_quiet;
        icmp {
                ignore_echo_requests = no;
                destunreach_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                timeexceeded_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
                echoreply_rate {
                        burstfactor = 6;
                        timeout = 1;
                }
        }
        masqtimeouts {
                tcp = 15m;
                tcp_fin = 2m;
                tcp_rst = 3s;
                udp = 5m;
                icmp = 30s;
                got_icmp_error = 15s;
                any = 5m;
                tcp_connect = 6m;
                tcp_listen = 2m;
        }
        ipfwlow {
                input {
                }
                output {
                }
        }
        ipfwhigh {
                input {
                }
                output {
                }
        }
        NAT_T_keepalive_interval = 20;
}


targets {
        policies {
                name = "fritzbox.domain.de";
                connect_on_channelup = no;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                virtualip = 192.168.117.201;
                remoteip = 0.0.0.0;
                remotehostname = "fritzbox.domain.de";
                localid {
                        user_fqdn = "usernamed";
                }
                mode = mode_aggressive;
                phase1ss = "all/all/all";
                keytype = keytype_pre_shared;
                key = "Mc879299eea7g901fk99dfoZd1ac*04|";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipaddr = 192.168.117.201;
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.117.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.117.0 255.255.255.0", 
                             "reject udp any any eq 53", 
                             "reject udp any any eq 500", 
                             "reject udp any any eq 4500", 
                             "permit ip any any";
                wakeupremote = no;
        }
}


policybindings {
}


// EOF

Hab mir auch mal die Routing Tabelle der FB angeschaut. Für meine VPN Clients wurden folgende Routen gesetzt, die fest in der Routingtable bleiben und sich nicht ändern, wenn der Cient sich verbindet oder die Verbindung getrennt wird:

192.168.118.201  0.0.0.0         255.255.255.255 UH        0 0          0 dsl

 

[PeterPawn]

@t7490:
Das sieht aber mehr nach der Konfigurationsdatei für das Programm FRITZ!Fernzugang (Windows-VPN-Client von AVM) aus als nach einer Konfigurationsdatei für die FRITZ!Box. Bei der Konfiguration mittels "FRITZ!Fernzugang konfigurieren" entstehen ja zwei Dateien, eine für die Box und eine für das erwähnte Programm.

 

[t7490]

Das kann natürlich sein. Das Tool kenne ich nicht. Aber da auch die localid und remoteid vertauscht sind, ist das wohl wirklich eine config für die Client Seite...

Aber auf jeden Fall sind da die besagten reject einträge drin...