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

[t7490]

Hallo,

ich würde gern für ein paar Geräte (Smartphone, Tablet, ..) einen VPN Tunnel konfigurieren, der außschließlich Zugriff aufs Internet erlaubt, um den Traffic in WLAN Hotspots von Hotels etc. zu verschlüsseln. Über den VPN Tunnel soll kein Zugriff aus das interne Netzwerk möglich sein.
Bietet die FritzBox 7490 mit der AVM Firmware eine Möglichkeit das zu realisieren oder müsste ich dazu Freetz mit iptables auf die Box packen?

Gruß Tobias

 

[eisbaerin]

Ja, geht. Einfach in der vpn.cfg bei accesslist das interne Netzwerk verbieten.

 

[t7490]

Vielen Dank für deine schnelle Antwort. Das ist ja schon mal super, dass ich mir dafür den Aufwand mit Freetz sparen kann!

Habe es gerade mal mit folgender Access List versucht:

accesslist =  
                             "reject ip 192.168.118.201 255.255.255.255 192.168.117.0 255.255.255.0",
                             "permit ip any any";

Nach dem importieren des Config Files wurde dann irgendwie jeglicher Traffic aus dem LAN ins Internet gedroppt. Also irgendwo ist da wohl ein Denkfehler drin?!
Wo "sitz" die ACL denn? Ja scheinbar nicht auf dem VPN Interface? Filtert die auf dem DSL Interface? Dann könnte man über die VPN Config ja sogar Firewall-Policies für LAN Traffic bauen?

Leider finde ich aber keine Dokumentation zur Syntax von der vpn.cfg.
Hast du eine Idee wo man eine Übersicht über die möglichen Config Parameter der vpn.cfg bekommen könnte?

 

[t7490]

Hier noch mal meine komplette VPN Config. Vielleicht ist der Fehler ja auch an ganz anderer Stelle zu suchen?
LAN=192.168.117.0/24

vpncfg { 
        connections { 
                enabled = yes; 
                conn_type = conntype_user; 
                name = "my-profile-name"; 
                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.118.201; 
                remoteid { 
                        key_id = "my-user-ipsec-id"; 
                } 
                mode = phase1_mode_aggressive; 
                phase1ss = "all/all/all"; 
                keytype = connkeytype_pre_shared; 
                key = "my-psk"; 
                cert_do_server_auth = no; 
                use_nat_t = yes; 
                use_xauth = yes; 
                xauth { 
                        valid = yes; 
                        username = "my-username"; 
                        passwd = "my-password"; 
                } 
                use_cfgmode = yes; 
                phase2localid { 
                        ipnet { 
                                ipaddr = 0.0.0.0; 
                                mask = 0.0.0.0; 
                        } 
                } 
                phase2remoteid { 
                        ipaddr = 192.168.118.201; 
                } 
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs"; 
                accesslist =  
                             "reject ip 192.168.118.201 255.255.255.255 192.168.117.0 255.255.255.0", 
                             "permit ip any any" ; 
        } 
        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

 

[eisbaerin]

Ne, so ist die accesslist falsch.
Wie war denn die accesslist original?

remote_virtualip = 192.168.118.201
.
ipaddr = 192.168.118.201;

Wo kommt denn die 118 her? Ich denke das Netz hat 117?

 

[t7490]

So, jetzt geht es. Die ACL war falsch herum. Hier die funktionierende Config:

vpncfg { 
        connections { 
                enabled = yes; 
                conn_type = conntype_user; 
                name = "my-profile-name"; 
                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.118.201; 
                remoteid { 
                        key_id = "my-user-ipsec-id"; 
                } 
                mode = phase1_mode_aggressive; 
                phase1ss = "all/all/all"; 
                keytype = connkeytype_pre_shared; 
                key = "my-psk"; 
                cert_do_server_auth = no; 
                use_nat_t = yes; 
                use_xauth = yes; 
                xauth { 
                        valid = yes; 
                        username = "my-username"; 
                        passwd = "my-password"; 
                } 
                use_cfgmode = yes; 
                phase2localid { 
                        ipnet { 
                                ipaddr = 0.0.0.0; 
                                mask = 0.0.0.0; 
                        } 
                } 
                phase2remoteid { 
                        ipaddr = 192.168.118.201; 
                } 
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs"; 
                accesslist =  
                             "reject ip 192.168.117.0 255.255.255.0 192.168.118.201 255.255.255.255", 
                             "permit ip any 192.168.118.201 255.255.255.255" ;
        } 
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",  
                            "udp 0.0.0.0:4500 0.0.0.0:4500"; 
} 
 
// EOF

Das 118er Netz habe ich für die VPN Clients genommen. Es funktioniert aber auch, wenn man IP Adressen aus dem LAN (117) vergibt.

Falls jemand noch irgendwo eine Doku zu den Parametern aus der vpn.cfg findet, wäre ich trotzdem noch daran interessiert...

 

[PeterPawn]

http://lmgtfy.com/?q=IPSec+vpn+fritz!box

Der sechste Link führt bei mir dann zu folgender Seite:

http://www.computersalat.de/linux/vpn/ipsec-vpn-zwischen-fritzbox-und-linux/

HTH

 

[t7490]

Ja, ich weiß wie man Google benutzt. Es ist mir aber trotzdem noch nicht gelungen eine vollständige Liste der Parameter zu finden und die in deinem Link ist auch alles andere als vollständig.

Ein Problem habe ich aktuell noch mit der VPN Config. Die Fritzbox übergibt keinen DNS-Server. Somit funktioniert auf einem iPhone DNS nicht mehr, sobald der Tunnel aufgebaut wird.
Unter Android funktioniert die Namensauflösung trotzdem. Allerdings kann ich mir noch nicht ganz erklären wie. Wahrscheinlich erreicht das Gerät noch die D1 Server am Tunnel vorbei. Wenn ich einen Packet Capture auf der FB mache, sehe ich jede Menge Internet Traffic, der über die FritzBox getunnelt wird aber keine einzige DNS Anfrage...
Eigentlich sollte es ja möglich sein per IPSec einen DNS-Server zu übergeben. Aber hierzu finde ich keinen passen Parameter für die Config und da scheinen auch schon andere dran verzweifelt zu sein... kann die Box das wirklich nicht?

 

[PeterPawn]

Ja, ich weiß wie man Google benutzt.

Dann ist's ja gut ... Du solltest die Umleitung auch nicht überbewerten und daß Du bereits selbst gesucht hast, hattest Du irgendwie unterschlagen; zumindest die Auflistung der Dir nicht genehmen Fundstellen.

die in deinem Link ist auch alles andere als vollständig.

Das war auch nicht die Fragestellung, wenn ich Dich mal kurz zitieren darf:

Falls jemand noch irgendwo eine Doku zu den Parametern aus der vpn.cfg findet, wäre ich trotzdem noch daran interessiert...

Welches Kriterium Deiner Bitte erfüllt denn jetzt der Link zu computersalat.de nicht?

Eigentlich sollte es ja möglich sein per IPSec einen DNS-Server zu übergeben. Aber hierzu finde ich keinen passen Parameter für die Config und da scheinen auch schon andere dran verzweifelt zu sein... kann die Box das wirklich nicht?

Die Box kann das durchaus, sie liefert einem Shrewsoft-Client auch tatsächlich ihre eigene Adresse (das ist die Einschränkung, sie gibt nur "sich selbst" als DNS-Proxy weiter). Es ist aber Sache des Clients, diese Einstellung abzufragen (pull) oder zu akzeptieren (push, wobei ich immer noch nicht weiß, ob die FRITZ!Box im cfgmode tatsächlich ihrerseits ein Angebot macht oder nur auf das Pull des Clients wartet). Offenbar reagiert da der iOS-Client aber anders als der des Android-Systems.

EDIT: Fast vergessen ... den cfgmode (https://tools.ietf.org/html/draft-dukes-ike-mode-cfg-02) schaltet natürlich "use_cfgmode=yes;" in der VPN-Konfiguration frei ... der ist aber eigentlich bei einer Host-LAN-Verbindung (conntype_user) immer an.

EDIT2: In meiner ganz alten Link-Liste hatte ich noch einen von AVM, der aber nach dem Relaunch vergangenes Jahr nicht mehr funktionierte. Das betreffende Dokument ist jetzt hierhin umgezogen, mehr dazu gibt es m.W. von AVM für den Endkunden nicht. Da theoretisch auch ein Provider einen Internetzugang über IPSec anbieten könnte, wäre es denkbar, daß die Provider-Dokumentationen da noch detaillierter sind.

 

[t7490]

Ok, Entschuldigung angenommen...

Dass die Box sich selbst als DNS Server im Config-Mode übergibt, kann ich leider nicht bestätigen. Ich bekomme auch auf dem Notebook mit ShrewSoft Client keinen DNS Server. Im Pull-Mode verbindet er sich aber ein DNS Server wird nicht übergeben. Im Push-Mode kommt gar keine Verbindung zu Stande.
use_cfgmode=yes ist in der vpn.cfg aktiv. (sonst würde ja auch gar keine Client-IP übergeben)

//EDIT:
Ich habe dazu jetzt einfach mal beim AVM Support angefragt und auch gleich eine Dokumentation zu den Parametern angefragt. Mal sehen, was zurück kommt...

 

[PeterPawn]

Ok, Entschuldigung angenommen...

Da das bestimmt das "nicht überbewerten" ist ... kein Problem.

Aber die Frage, die ich aufgeworfen habe bzgl. des Inhalts Deiner Bitte, bleibt irgendwie auch bestehen, oder?

Zum Shrewsoft und dem DNS-Pull:

Bei Verwendung von

n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1 (das klappt allerdings nicht)
n:policy-list-auto:1
s:client-auto-mode:pull
s:client-iface:virtual
s:policy-level:auto

(die relevanten Einstellungen)
wird bei mir unter Windows 8.1 (x64) mit Shrewsoft Version 2.2.2 (Standard-Edition) der DNS-Server der Box übermittelt, jedenfalls steht das im Protokoll des Shrewsoft-Clients:

15/06/27 21:44:44 ii : configure hash verified
15/06/27 21:44:44 ii : received config pull response
15/06/27 21:44:44 ii : - IP4 Address = 192.168.xxx.201
15/06/27 21:44:44 ii : - IP4 DNS Server = 192.168.xxx.1

Ich würde jetzt annehmen, daß das für andere Clients genauso funktioniert ... ein irgendwie damit (aufgrund seines Namens) in logischen Zusammenhang zu bringender Parameter bei der FRITZ!Box ist jedenfalls weder in den Zeichenketten der libar7cfg.so, der libcfgimpexp.so oder des avmike zu finden und daher würde ich die These wagen, daß es keinen solchen Parameter gibt.

 

[t7490]

Ja, man hätte die Frage sicher auch präziser formulieren können. Machen wir damit einfach einen Haken an das Thema...

Die Parameter in meiner ShrewSoft Config sind identisch mit deinen. Die Version 2.2.2. Ebenfalls. Dennoch bekomme ich keinen DNS Server übergeben.
Ich konnte allerdings das von dir gepostete Protokoll nicht finden. In dem Trace-Tool standen diese Einträge bei mir nicht drin. Wo genau hast du die her?

btw:
Die Access Lists verstehe ich immer noch nicht wirklich. Eigentlich sollten die doch nur für den einen VPN Tunnel relevant sein, in dem sie konfiguriert sind, oder nicht?
Wenn ich die Zeile "permit udp any any eq 53" in die VPN Access List einfüge, funktioniert aus meinem LAN keine DNS auflösung mehr. Ping ins Internet geht.
Wenn ich die Zeile "permit ip any any" in die VPN Access List einfüge, funktioniert aus meinem LAN ins Internet gar nichts mehr.
Das macht irgendwie gleich mehrfach keinen Sinn für mich, da:
1. ein permit Statement nichts droppen sollte und
2. eine VPN Access List keinen Impact auf meinen LAN-to-WAN Traffic haben sollte
Hat da jemand eine Erklärung für?

 

[PeterPawn]

In dem Trace-Tool standen diese Einträge bei mir nicht drin. Wo genau hast du die her?

Trace-Tool. Debug-Level einstellen, die drei Logs mit "Open Log" starten und Verbindung aufbauen. Irgendwann stehen die Daten dann in den konfigurierten Verzeichnissen/Dateien ("Options" im Trace-Tool).

Die Access Lists verstehe ich immer noch nicht wirklich. Eigentlich sollten die doch nur für den einen VPN Tunnel relevant sein, in dem sie konfiguriert sind, oder nicht?

Nein, definitiv nicht. Die "accesslist" jeder aktivierten (nicht nur jeder aufgebauten) Verbindung wird sofort als Filter wirksam, nur so ist ja auch der Aufbau einer "on demand"-Verbindung möglich, wenn einer der Filter matched.

Wenn ich die Zeile "permit udp any any eq 53" in die VPN Access List einfüge, funktioniert aus meinem LAN keine DNS auflösung mehr. Ping ins Internet geht.

Was passiert jetzt? Der UDP-Verkehr jedes lokalen Hosts (das erste "any") an jede beliebige Adresse (das zweite "any"), der von oder an Port 53 gerichtet ist und - das ist das Entscheidende - am "dev dsl" vorbeikommt (nur da greifen die Transformationen), wird in den Tunnel gestopft, für den diese "accesslist" aktiviert ist. Solange also aus dem Tunnel keine Antworten auf diese Pakete kommen, ist es nur folgerichtig, wenn DNS nicht mehr geht ... erst recht dann, wenn der Tunnel vielleicht gar nicht aufgebaut ist; dann verschwinden UDP-Pakete einfach im Nirwana.

1. ein permit Statement nichts droppen sollte und

Macht es ja auch nicht, s.o. ... es leitet den Verkehr eben um - das Konzept ist z.B. beim Shrewsoft-Client mit den "Policies" und bei Linux-Kernel mit den "Transformations" (ip xfrm) dasselbe (wahrscheinlich nutzt AVM sogar diesen Mechanismus im Kernel, zumindest zum Teil).

2. eine VPN Access List keinen Impact auf meinen LAN-to-WAN Traffic haben sollte

Das ist nun mal keine "Firewall" oder etwas ähnliches ... es ist ein "Selektor". Was paßt, wird in den Tunnel geschubst, der Rest wandert weiter im Stack auf "dev dsl" und landet dann irgendwann mal am (wirklich) externen Interface.

Damit ist aber sicherlich auch klar, wieso "permit ip any any" (also wirklich aller Verkehr durch den Tunnel, u.U. sogar den, der ja wenigstens zum IPSec-Gateway auf der Gegenseite direkt passieren muß) nicht funktioniert. Ob das theoretisch machbar wäre (also ob die gekapselten Pakete erst "hinter" der Selektion wieder injiziert werden), wollte ich schon lange mal testen ... aber so wichtig ist mir das Thema auch nicht und "reject_not_encrypted=yes;" ist an der Stelle ohnehin besser, weil der erst wirksam wird (so jedenfalls meine Kenntnisse), wenn die Verbindung erfolgreich aufgebaut wurde.

 

[t7490]

Okay, danke. Die Debug Option hatte ich übersehen. Jetzt sehe ich mehr. Die Zeile IP4 Address = 192.168.xxx.201 wird angezeigt aber die DNS Zeile taucht nicht auf, was dann ja bestätigt, dass bei mir kein DNS Server übergeben wird...

Könntest du mal deine vpn.cfg posten oder meine oben gepostete mit deiner vergleichen?

Danke auch für die Erläuterungen zu den ACL. So macht das natürlich Sinn. Ich hatte das als Traffic-Filter (Firewall-Policy) im VPN-Tunnel interpretiert. Der Traffic, der in den Tunnel soll, wird ja eigentlich über den IPSec Quickmode Selector bestimmt. Aber gut, wenn die ACL bestimmt, welcher Traffic in den Tunnel geroutet wird, dann ist das Verhalten nachvollziehbar.

 

[PeterPawn]

Der Traffic, der in den Tunnel soll, wird ja eigentlich über den IPSec Quickmode Selector bestimmt.

Was soll das sein? Das müßte dann irgendein herstellerspezifischer Terminus sein, denn der "offizielle" "IPSec quick mode" wäre die ISAKMP-Aushandlung der SAs in Phase2. Wenn nur damit irgendetwas in die Richtung einer Konfiguration des zu tunnelnden Verkehrs erfolgen würde, wäre ja das Tunneln zusätzlicher Netze nicht mehr möglich.

die DNS Zeile taucht nicht auf

Hast Du vielleicht eigene DNS-Server festgelegt in der FRITZ!Box? Dann wäre es denkbar, daß die Box nur dann den DNS-Server setzt, wenn diese Einstellung nicht vorhanden ist. Meine Gegenstelle bei dieser Verbindung war jedenfalls eine 7390 mit 06.20 (also nicht die aktuellste Version).

In der VPN-Konfiguration der FRITZ!Box kann ich keinen Unterschied auf Anhieb ausmachen - der Unterschied in der accesslist ist Dir ja sicherlich bewußt ... ob der aber damit zu tun hat, müßtest Du selbst testen.

Es macht für mich auch nur begrenzt Sinn, da wie bei Dir mit einem anderen Subnetz zu arbeiten, damit mußt Du die VPN-Verbindung ja dann auch komplett von Hand konfigurieren (oder zumindest nachträglich ändern oder es ist gar keine "per user"-Verbindung bei Dir).

In Anbetracht der "reject"-Regel in der "accesslist" würde Dir ja aber ein gesetzter DNS-Server ohnehin nichts helfen, denn die FRITZ!Box bleibt ja auch als DNS-Server nur unter der Adresse 192.168.117.1 erreichbar (die 192.168.118.1 o.ä. dürfte sie gar nicht zugewiesen haben) und Du verbietest ja sämtlichen Verkehr aus 192.168.117.0/24 in den Tunnel. Ich bezweifle eigentlich sogar, daß da der im Rahmen einer von der 192.168.118.201 ausgehenden Verbindung auf dem Rückweg wieder eintreffende Verkehr korrekt über "dev dsl" geroutet wird ... wobei das doch noch sein könnte, wenn die entsprechende Route vom avmike gesetzt wird, denn seit dem Gastnetz kennt die Box ja auch mehrere lokale Netze und kann damit auch beim PA umgehen.

Wie auch immer ... ich hoffe, Du bist Dir (angesichts des nunmehr vorhandenen Verständnisses für die Wirkung von "accesslist") auch darüber im Klaren, daß damit nur der Verkehr aus dem LAN in den Tunnel blockiert wird, nicht der Versand von Paketen aus dem Tunnel ins LAN (das ist keine Firewall). Das mag zwar eine TCP-Verbindung zuverlässig verhindern ... andere Spielereien, die z.B. nur auf der Basis von UDP-Paketen arbeiten (also sogar SIP-INVITEs), bleiben nach wie vor machbar, es kommt halt nur nichts zurück.

 

[t7490]

Was soll das sein? Das müßte dann irgendein herstellerspezifischer Terminus sein, denn der "offizielle" "IPSec quick mode" wäre die ISAKMP-Aushandlung der SAs in Phase2. Wenn nur damit irgendetwas in die Richtung einer Konfiguration des zu tunnelnden Verkehrs erfolgen würde, wäre ja das Tunneln zusätzlicher Netze nicht mehr möglich.

Der "selector" (inennt jeder Hersteller anders) definiert welche Netze für die SA der Phase 2 verwendet werden, also welcher Traffic verschlüsselt wird. Die meisten Hersteller machen daran dann auch fest, welcher Traffic in den Tunnel geroutet wird. Bei der Fritzbox entspricht dies wohl den Parametern phase2localid und phase2remoteid

Hast Du vielleicht eigene DNS-Server festgelegt in der FRITZ!Box? Dann wäre es denkbar, daß die Box nur dann den DNS-Server setzt, wenn diese Einstellung nicht vorhanden ist. Meine Gegenstelle bei dieser Verbindung war jedenfalls eine 7390 mit 06.20 (also nicht die aktuellste Version).

nein, wird dynamisch von 1&1 zugewiesen.

In der VPN-Konfiguration der FRITZ!Box kann ich keinen Unterschied auf Anhieb ausmachen - der Unterschied in der accesslist ist Dir ja sicherlich bewußt ... ob der aber damit zu tun hat, müßtest Du selbst testen.
Es macht für mich auch nur begrenzt Sinn, da wie bei Dir mit einem anderen Subnetz zu arbeiten, damit mußt Du die VPN-Verbindung ja dann auch komplett von Hand konfigurieren (oder zumindest nachträglich ändern oder es ist gar keine "per user"-Verbindung bei Dir).

Das separate Subnetz bringt keinen wirklichen Mehrwert aber auch wenn ich eine IP aus dem LAN verwende, ändert sich an dem Verhalten nichts. Habe beides getestet.

In Anbetracht der "reject"-Regel in der "accesslist" würde Dir ja aber ein gesetzter DNS-Server ohnehin nichts helfen, denn die FRITZ!Box bleibt ja auch als DNS-Server nur unter der Adresse 192.168.117.1 erreichbar (die 192.168.118.1 o.ä. dürfte sie gar nicht zugewiesen haben) und Du verbietest ja sämtlichen Verkehr aus 192.168.117.0/24 in den Tunnel.

Deshalb habe ich die ACL auch schon wie folgt erweitert. Aber da ja kein DNS Server übergeben wird, bringt das erst mal nichts.

"permit udp 192.168.117.1 255.255.255.255 eq 53 any", 
"reject ip 192.168.117.0 255.255.255.0 192.168.117.201 255.255.255.255", 
"permit ip any 192.168.117.201 255.255.255.255" ;

Wie auch immer ... ich hoffe, Du bist Dir (angesichts des nunmehr vorhandenen Verständnisses für die Wirkung von "accesslist") auch darüber im Klaren, daß damit nur der Verkehr aus dem LAN in den Tunnel blockiert wird, nicht der Versand von Paketen aus dem Tunnel ins LAN (das ist keine Firewall). Das mag zwar eine TCP-Verbindung zuverlässig verhindern ... andere Spielereien, die z.B. nur auf der Basis von UDP-Paketen arbeiten (also sogar SIP-INVITEs), bleiben nach wie vor machbar, es kommt halt nur nichts zurück.

Ja, das ist mir bewusst. Wäre dennoch erst mal ausreichend, wenn es denn funktioniert.

Von AVM kam auch schon die erste Antwort aber scheinbar wurde meine Mail nur grob überflogen und der erstbeste Link aus den FAQ, der irgendetwas mit Namesauflösung zu tun hat, versendet. Mit dem Hinweis, dass dies kein Fehler der Fritzbox sei...
Mal sehen, ob das noch zu irgendwas führt oder die Kommunitkation auf dem Niveau bleibt?!

Ich werde es erst mal so belassen, wie es ist. Das iPhone ist nicht ganz so wichtig und auf anderen Geräten funktioniert es ja grundsätzlich abgesehen davon, dass dann die DNS Anfragen über den Hotspot Router laufen. Immerhin sind erst mal die restlichen Daten verschlüsselt.

Wenn ich mal mehr Zeit habe, kommt dann ein Freetz mit iptables und openvpn auf die Box.

 

[PeterPawn]

Wenn ich mal mehr Zeit habe, kommt dann ein Freetz mit iptables und openvpn auf die Box.

Sicherlich keine ganz schlechte Idee, aber informiere Dich vorher über die (begrenzten) Möglichkeiten von iptables in Zusammenarbeit mit dem avm_pa ... sonst ist die Enttäuschung ggf. vorprogrammiert.

 

[t7490]

So, jetzt melde ich mich doch noch mal mit guten Nachrichten! Eigentlich wollte ich nur noch einen 2.User/Profil anlegen aber da ich dann plötzlich einen DNS Server übergeben bekam, habe ich noch ein wenig geforscht.
Das Verhalten ist nur bedingt nachvollziehbar aber reproduziertbar.

Ob ein DNS Server übergeben wird, hängt offensichtlich doch von der ACL ab.
Ein funktionierendes Setup ließ sich nur mit eigenem Subnetz für jeden VPN Client/Profil erreichen.

folgende ACLs habe ich getestet (oben und unten jeweils ein VPN Profil):

1)

"reject ip 192.168.117.0 255.255.255.0 192.168.117.201 255.255.255.255", 
"permit ip any 192.168.117.201 255.255.255.255" ;

"reject ip 192.168.117.0 255.255.255.0 192.168.117.202 255.255.255.255", 
"permit ip any 192.168.117.202 255.255.255.255" ;

==> kein DNS-Server wird übergeben, bei beiden Profilen

2)

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.117.201 255.255.255.255", 
"reject ip 192.168.117.0 255.255.255.0 192.168.117.201 255.255.255.255", 
"permit ip any 192.168.117.201 255.255.255.255" ;

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.117.202 255.255.255.255", 
"reject ip 192.168.117.0 255.255.255.0 192.168.117.202 255.255.255.255", 
"permit ip any 192.168.117.202 255.255.255.255" ;

==> kein DNS-Server wird übergeben, bei beiden Profilen (vermutlich wären Sie aber erreichbar, nicht getestet)

3)

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.117.0 255.255.255.0", 
"reject ip 192.168.117.0 255.255.255.0 192.168.117.201 255.255.255.255", 
"permit ip any 192.168.117.201 255.255.255.255" ;

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.117.0 255.255.255.0", 
"reject ip 192.168.117.0 255.255.255.0 192.168.117.202 255.255.255.255", 
"permit ip any 192.168.117.202 255.255.255.255" ;

==> DNS Server werden übergeben aber sind wegen des Routings nur über Profil 1 erreichbar

4)

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.118.0 255.255.255.0", 
"reject ip 192.168.117.0 255.255.255.0 192.168.118.201 255.255.255.255", 
"permit ip any 192.168.118.201 255.255.255.255" ;

"permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.119.0 255.255.255.0", 
"reject ip 192.168.117.0 255.255.255.0 192.168.119.201 255.255.255.255", 
"permit ip any 192.168.119.201 255.255.255.255" ;

==> DNS Server werden an beide Clients übergeben und sind auch erreichbar.

Die Erreichbarkeit der Server ist ja bedingt durch das Routing über die ACL noch recht gut nachvollziehbar.
Allerdings macht für mich der Zusammenhang mit dem DNS Server Parameter im Config Mode noch keinen Sinn. (insbesondere in Fall 2)

Wie dem auch sei, es funktioniert nun und hier eine komplette Config, falls jemand mal ein ähnliches Setup braucht:

vpncfg { 
        connections { 
                enabled = yes; 
                conn_type = conntype_user; 
                name = "my_profile"; 
                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.118.201; 
                remoteid { 
                        key_id = "my_profile"; 
                } 
                mode = phase1_mode_aggressive; 
                phase1ss = "all/all/all"; 
                keytype = connkeytype_pre_shared; 
                key = "my_psk"; 
                cert_do_server_auth = no; 
                use_nat_t = yes; 
                use_xauth = yes; 
                xauth { 
                        valid = yes; 
                        username = "my_user"; 
                        passwd = "my_pw"; 
                } 
                use_cfgmode = yes; 
                phase2localid { 
                        ipnet { 
                                ipaddr = 0.0.0.0; 
                                mask = 0.0.0.0; 
                        } 
                } 
                phase2remoteid { 
                        ipaddr = 192.168.118.201; 
                } 
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs"; 
                accesslist =  
                             "permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.118.0 255.255.255.0", 
                             "reject ip 192.168.117.0 255.255.255.0 192.168.118.201 255.255.255.255", 
                             "permit ip any 192.168.118.201 255.255.255.255" ; 
        } 
      connections { 
                enabled = yes; 
                conn_type = conntype_user; 
                name = "my_profile2"; 
                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.119.201; 
                remoteid { 
                        key_id = "my_profile2"; 
                } 
                mode = phase1_mode_aggressive; 
                phase1ss = "all/all/all"; 
                keytype = connkeytype_pre_shared; 
                key = "my_psk"; 
                cert_do_server_auth = no; 
                use_nat_t = yes; 
                use_xauth = yes; 
                xauth { 
                        valid = yes; 
                        username = "my_user"; 
                        passwd = "my_pw"; 
                } 
                use_cfgmode = yes; 
                phase2localid { 
                        ipnet { 
                                ipaddr = 0.0.0.0; 
                                mask = 0.0.0.0; 
                        } 
                } 
                phase2remoteid { 
                        ipaddr = 192.168.119.201; 
                } 
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs"; 
                accesslist =  
                             "permit udp 192.168.117.1 255.255.255.255 eq 53 192.168.119.0 255.255.255.0", 
                             "reject ip 192.168.117.0 255.255.255.0 192.168.119.201 255.255.255.255", 
                             "permit ip any 192.168.119.201 255.255.255.255" ; 
        }  ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",  
                            "udp 0.0.0.0:4500 0.0.0.0:4500"; 
}

Gruß Tobias

 

[andiling]

Nur aus Interesse, aber während lokale Geräte geblockt sind, können andere VPN Benutzer erreicht werden, oder?

 

[t7490]

Hab ich nicht getestet aber ich würde erwarten, dass die VPN Clients sich mit der Config gegenseitig erreichen, denn in der ACL ist es ja nicht verboten.
Kann ich aber bei Gelegenheit mal testen.