[Frage] VPN: erlaubte IPs einschränken (vpncfg)

madison42

Neuer User
Mitglied seit
5 Okt 2008
Beiträge
3
Punkte für Reaktionen
0
Punkte
0
Hallo,

meine FritzBox 7390 (kein Freetz) verbindet sich per VPN zu meinem privaten Linux-Server (strongSwan), das klappt soweit.
Sobald die Verbindung steht kann allerdings vom Linux-Server aus jeder Rechner in meinem Heimnetz erreicht werden. Ziel ist, daß nur Verbindungen aus dem Heimnetz in das VPN auf dem Linux-Server zugelassen werden. In der Richtung Linux-Server => Heimnetz soll das nicht möglich sein.
Scheinbar kann man mit "reject" oder "deny" in der accesslist nicht das erreichen was ich mir vorstelle:

Code:
                accesslist = "deny ip 192.168.135.0 255.255.255.0 any",
                             "permit ip any 192.168.135.0 255.255.255.0";

hat leider nichts gebracht, es können noch immer Verbindungen in beide Richtungen aufgebaut werdebn.

Was genau bedeutet denn "permit" im Kontext vpncfg / accesslist? Wenn mann den Beiträgen hier oder hier glaubt, hat das mehr mit Routing als mit Filtern zu tun ...

Hier mal ein Ausschnitt aus meiner vpncfg:

Code:
vpncfg {
        connections {
                enabled = yes;

...

                phase2localid {
                        ipnet {
                                ipaddr = 192.168.64.0;
                                mask = 255.255.254.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.135.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.135.0 255.255.255.0";
        } {
 
Zuletzt bearbeitet:
Was genau bedeutet denn "permit" im Kontext vpncfg / accesslist?
Die anderen Beiträge haben wohl recht ... auch wenn dieselbe Syntax verwendet wird, wie für ACLs an anderer Stelle, ist das wahrscheinlich (ist ja alles Closed-Source) mehr ein Selektor, welcher Verkehr in Richtung IPSec "abbiegen" soll und welcher nicht. Das müßtest Du von den Transform-Tables und den Policies bei Deinem StrongSWAN ja auch kennen (ip xfrm).

Es gibt noch irgendeine Syntax für "connection incoming-related" und "connection outgoing-related", eventuell kann man damit das "falsche Abbiegen" des Traffics bewirken, wenn die Verbindung von der Server-Seite aufgemacht wurde. Ob das aber so sinnvoll ist (der Traffic geht dann schließlich über "dev dsl" i.d.R. ins Internet und zwar unverschlüsselt), würde ich auch bezweifeln. Auch ist damit der Weg für einzelne UDP-Pakete vom Server ins LAN immer noch offen und manchmal reicht ja das schon für das Kompromittieren eines Netzes.

Die Möglichkeit, auf dem Server mit "iptables" neue ausgehende Verbindungen zur FRITZ!Box nicht zuzulassen, wirst Du ja schon in Erwägung gezogen haben. Das ist natürlich nur eine "collaborative solution" und funktioniert nur dann, wenn Dir auf dem Server definitiv niemand in die Suppe spucken kann.
 
Es gibt noch irgendeine Syntax für "connection incoming-related" und "connection outgoing-related", eventuell kann man damit das "falsche Abbiegen" des Traffics bewirken, wenn die Verbindung von der Server-Seite aufgemacht wurde.

Hatte ich auch probiert, ohne Erfolg

Die Möglichkeit, auf dem Server mit "iptables" neue ausgehende Verbindungen zur FRITZ!Box nicht zuzulassen, wirst Du ja schon in Erwägung gezogen haben. Das ist natürlich nur eine "collaborative solution" und funktioniert nur dann, wenn Dir auf dem Server definitiv niemand in die Suppe spucken kann.

So ist es. Hintergund meiner Anfrage ist genau das Szenario daß jmd. meinen Linux-Sever hackt und dann gleich direkten Zugang zu meinem Heim-LAN incl. NAS usw. hat. In dem Fall hilft ein iptables auf dem Linux-Server natürlich genau nichts mehr.

Gibt also wiklich nur die beiden Varianten das Risiko einzugehen oder auf den VPN-Komfort (interner Zugang von allen Clients daheim zum externen Server) zu verzichten? Schade schade ...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.