Problem mit VPNC unter Debian

    Hallo!


    Ich nutze einen Rootserver RS 2000 G9 mit Debian Bullseye, auf dem ich einen VPN zu meiner heimischen Fritzbox einrichten möchte. Dazu habe ich VPNC installiert.

    Unter /etc/vpnc habe ich eine Konfiguration test.conf angelegt mit folgendem Inhalt:

    Das Script /etc/vpnc/fb-script.sh setzt Routing-Einstellungen, damit nur mein privater IP-Range durch den Tunnel geroutet wird.

    Die Konfiguration habe ich nach folgener Anleitung durchgeführt:

    https://waal70blog.wordpress.com/2019/01/14/connect-vpn-to-fritzbox-with-vpnc-from-debian-linux/


    Wenn ich den Tunnel mit "vpnc-connect test" aufbaue, schaut eigentlich alles richtig aus:

    Ausgabe von ifconfig:

    Ausgabe von route:

    Code
    Kernel IP routing table
Destination      Gateway         Genmask         Flags Metric Ref    Use Iface
default          89.58.28.1      0.0.0.0         UG    0      0        0 eth0
[Server-Netz]    0.0.0.0         255.255.252.0   U     0      0        0 eth0
[Privates-Netz]  0.0.0.0         255.255.255.0   U     0      0        0 tap0

    Mein Problem: es gehen keine IP-Packets durch den Tunnel, keine IP-Connection, kein ping zur Fritzbox, mounten von NAS-Shares, SSH, FTP - nichts.

    Auf einem VServer bei einem anderen Provider mit der gleichen Konfiguration funktioniert der Tunnel, nur auf dem Netcup Rootserver nicht.

    Beide Server sind mit ISPconfig und UFW Firewall installiert. Ein komplettes Deaktivieren der Firewall ändert nichts am Problem.


    Mit der gleichen Config gelingt der Tunnel auf einem VServer bei einem anderen Provider. Wenn ich den Tunnel dort abbaue (vpnc-disconnect) und auf Netcup neu connecte, funktioniert dort leider nichts.

    Ich hab keine Idee, woran es liegen könnte und ich finde auch in den LOGS keine echte Spur.

    Jeder Client hat aber schon eigene Zugangsdaten (Username/Password) und somit auch eine eindeutige interne IP-Adresse? Dein letzter Absatz klingt nämlich eigenartig.


    Was genau machst Du im Shellscript? Vielleicht liegt dort der Fehler begraben. Oder ist das völlig inhaltsgleich wie im verlinkten Blogpost?

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

    Danke für deine Antwort. Ich verwende einen Fritzbox-Account zum Tunnelaufbau auf mehreren Endgeräten, jedoch nie gleichzeitig. Nur während ich ein Endgerät nutze, baue ich bei Bedarf dort den Tunnel auf und nach der Nutzung erfolgt ein Disconnect. Das funktioniert derzeit mit 4 unterschiedlichen Clients, darunter 2 Notebooks, mit denen ich mich von unterwegs in mein heimisches Netz verbinde. Der Netcup-Server soll zukünftig den Tunnel per Cronjob in den Nachtstunden aufbauen, um ein Backup zu übertragen. Aber leider gelingt mir speziell mit diesem Server kein IP-Connect. Das Shellscript ist inhaltsgleich zum verlinkten Post.

    Zitat von KB19

    Jeder Client hat aber schon eigene Zugangsdaten (Username/Password) und somit auch eine eindeutige interne IP-Adresse?

    Ich habe für den Netcup-Server jetzt eigene Zugangsdaten eingerichtet. Der Server erhält jetzt eine andere/eigene IP. Nach wie vor erhalte ich jedoch keine IP-Verbindung durch den Tunnel.

    Als Erstes fällt auf, dass das TAP Device die Subnetzmaske 255.255.255.255 hat, obwohl es im Script mit 255.255.255.0 gesetzt werden soll (jedenfalls in dem auf der Webseite). Auch die Broadcast Adresse 0.0.0.0 finde ich merkwürdig an der Stelle.


    Dann: Gibt es iptables Regeln, die die Kommunikation verhindern oder nicht erlauben?


    Generell finde ich es merkwürdig, hier ein TAP Device zu benutzen. Der Grund, dass es mit ip und iptables besser zurechtkommt, halte ich für nicht stichhaltig. Damit hatte ich nie ein Problem.


    Letzter Punkt: Du müsstest mal mit tcpdump herausfinden, mit welcher Quelladresse dein Server die Pakete in den Tunnel schickt. Am Ende verwendet er die Adresse von eth0 oder so, das wird dann natürlich nicht funktionieren.

    Hallo Frank!


    Danke für deine Antwort.

    Zitat von frank_m

    Generell finde ich es merkwürdig, hier ein TAP Device zu benutzen. Der Grund, dass es mit ip und iptables besser zurechtkommt, halte ich für nicht stichhaltig. Damit hatte ich nie ein Problem.

    Ich habe jetzt in der VPNC-Conf Zeile "Interface mode tap" den Eintrag tap durch tun ersetzt und das hat mein Problem gelöst !!!


    Super - vielen Dank für den Hinweis! Ich verstehe trotzdem nicht, wieso es auf einem anderen VServer bei einem anderen Provider mit dem tap device lief und auf dem Netcup Server ein tap device nicht funktioniert und stattdessen ein tun device erforderlich ist. Hauptsache ist aber, dass damit eine IP-Verbindung durch den Tunnel möglich ist. Ich freu mich gerade riesig, dass es jetzt geht!