[Gelöst] Brücke Openvpn Tap1 LAN – Wie ?



  • Hallo Forum !

    Ich hab mal wieder ein Problem, das ich hoffe, mit PFsense lösen zu können.

    Hier mein Aufbau:
    LAN-Netz <–-> PFsense <---> Openvpn-Tunnel mittels TAP-Device

    Was ich bereits eingerichtet habe:
    Brücke mit LAN und TAP1.
    Openvpn Tunnel mit dev TAP.
    Ping zum Server und zu einem anderen Client der ebenfalls im Tunnel ist funktioniert vom PFsense aus.

    Mein Problem:
    Wie bekomme ich es jetzt hin, dass auch meine lokalen PCs durch den Tunnel den Server
    und den Client anpingen und sogar Verbindungen aufbauen können ?

    NACHTRAG:
    Ich kannjetzt auch den Server anpingen und den anderen OpenVPN Client.
    Allerdings funktioniert das Bridging noch nicht 100%ig.

    Das nächste fatale Problem ist, dass ich den PFsense nie mehr rebooten darf.
    Er startet nach dem Reboot immer im Configmodus, weil er der Meinung ist, daß etwas mit den Schnittstellen nicht stimmt.
    Auch fehlt nach dem reboot die TAP1.

    Wie kann ich den dazu bringen die Einstellungen auch beim Booten zu behalten ?



  • Habs nun doch gelöst bekommen.
    Fakt ist, PFsense ist sich mit den Devices selbst im Weg.

    Es merkt sich die eingestellten Devices nicht.
    Mache ich eine Brücke mit TAP1 und EM1 läuft alles einwandfrei.

    Reboote ich, kommt er mit einer Fehlkonfiguration der Devices.
    Völliger Quatsch!

    So gut und toll PFsense auch ist, bei manchen einfachen Dingen versagt sie leider.

    Ich hab mein Problem, dass er die nicht vorhandenen Devices bemängelt, einfach so gelöst, daß ich sie ihm beim booten erzeugen lasse.
    Zusätzliches Problem mit VPN:
    Selbst mit dem TAP-Fix scheint er nur einmal die Einstellung zum dev tap zu nutzen.
    beim nächsten Reboot steht wieder dev ovpnc1 drin (in der /var/etc/openvpn/client1.conf), obwohl es im Webpanel auf TAP steht.
    also hab ich mir im /etc den normalen openvpn-ordner erstellt und die Config dort eingefügt:

    
    mkdir /etc/openvpn
    touch /etc/openvpn/config.conf
    

    Dann den Inhalt von
    /var/etc/openvpn/client1.conf
    in
    /etc/openvpn/config.conf
    eingefügt mit den Änderungen, die der client braucht.

    Die Lösung für den Reboot sieht dann so aus:

    /etc/rc:

    suche nach

    
    # Recreate capabilities DB
    /usr/bin/cap_mkdb /etc/login.conf
    

    füge danach ein

    ifconfig tap create
    ifconfig tap create
    ifconfig tap create
    openvpn /etc/openvpn/client.conf
    sleep 10
    ifconfig bridge0 addm tap1
    

    Zur Erklärung:
    ich erstelle die tap0 und tap1 aus dem Grund, daß openvpn von sich aus tap1 nutzt.
    Wieso, ist mir schleierhaft, da er normal ja mit 0 anfängt.
    um auf der sicheren Seite zu bleiben, hab ich tap0-2 erstellt.

    Die bridge0 beinhaltet bei mir em1,tap0,tap1
    solange der tunnel nicht steht, ist tap1 wieder weg.
    Also könnte es sein, wenn keine Internetverbindung oder kein Tunnel besteht bzw. nicht mehr besteht,
    beim booten wieder der misconfiguration Fehler kommt, weil eine Brücke aus mind. 2 Devices bestehen muss.
    Fehlt nun tap1 gibts sicherlich Fehler.
    Daher auch tap0 und em1, denn dann sollte es kein Fehler geben.

    Anschliessend wird der Tunnel aufgebaut.

    Danach füge ich tap1 der Brücke bridge0 hinzu, da dieses Device seltsamerweise nicht in
    der Brücke vorhanden ist, obwohl es im Webpanel als Teil der Brücke angezeigt wird.

    Wichtig:
    Den vorhandenen openvpn-Client im Webpanel muss man deaktivieren.
    Um das Ganze überhaupt zum laufen zu bekommen, muss man die devices erst einrichten.

    Einrichten der Geräte:
    Mit dem Command-prompt 3x ifconfig tap create ausführen.
    Dann die Devices neu erstellen und zuordnen.
    Ich hab tap0 mit tap0 bezeichnet u.s.w.
    Die einzelnen Devices auswählen und jeweils aktivieren und überall none bei Type einstellen. (Bezieht sich jetzt nur auf tap0 und tap1, weitere Geräte wurden nicht erstellt.)
    Dann die Brücke erstellen mit LAN, Tap0 und TAP1 .

    Die originale LAN-Schnittstelle bearbeiten und da wo static steht ein none auswählen und speichern.
    NICHT APPLY DRÜCKEN! Erst wenn alles eingestellt ist.
    Dann die Brücke bearbeiten, aktivieren und beim Typ wieder auf static stellen und weiter unten die IP der ursprünglichen LAN-Schnittstelle eingeben. Das Pulldownfeld auf 24 stellen.

    Nun kommt der wichtigste Punkt, den ich schon bei 2 PFsenses vergessen hab.
    Die Firewallregeln !
    Unbedingt bei Brücke und tap1 alles erlauben, sonst sperrt man sich aus (bridge0) und man kann den Tunnel (tap1) nicht nutzen.
    Tap0 kann man ignorieren.

    Die Firewallregeln darf man jetzt "applyen".

    Die Konfig des Tunnels (/etc/openvpn/client1.conf) bearbeiten und dev tap1 anstelle von dev tun eintragen und statt proto udp, proto tcp eintragen.
    Wenn jemand fragment xxx eingetragen hat, das muss da raus.

    Wenn nun die Firewallregeln bearbeitet und die Netzwerkgeräte aktiviert und eingestellt wurden, kann man ein netzwerkgerät (z.B. die Brücke) auswählen und darf dann auf APPLY drücken.

    Serverseitig vom openvpn-Server:
    Viele Tuts und Howtos behandeln den Weg, wie man Zertifikate erstellt und einbindet.
    Soweit so hilfreich, aber kaum jemand behandelt das, was danach kommt, nämlich der wirklich wichtige Teil: die Routen !

    In meinem Startscript vom Server habe ich zunächst die Hauptroute eingetragen:
    route add -net 10.10.0.0 netmask 255.255.255.0 gw 10.10.0.1

    Ob die nun wichtig ist oder nicht, weis ich nicht, sie funktioniert bei mir.

    Weiterhin habe ich andere Routen hinzugefügt:
    route add -net 192.168.100.0 netmask 255.255.255.0 gw 10.10.0.9
    route add -net 192.168.10.0 netmask 255.255.255.0 gw 10.10.0.109

    ….

    Da ich ja mehrere komplette Netze, an denen jeweils eine PFsense als Router hängt, in den Tunnel einbinden will.

    Dann kommen die CCDs, die Clientkonfigurationen, die ich vom Server aus einstellen kann.

    dort steht für den jeweiligen Client folgendes drin:

    
    # Weist dem Client eine fixe IP zu, jeder Client bekommt eine andre IP
    ifconfig-push 10.10.0.9 255.255.255.0
    
    # Sagt dem client welche Netze er durch den Tunnel erreichen kann.
    
    ### Das Netz des Tunnels und die IP des Servers
    push "route 10.10.0.0 255.255.255.0"
    push "route 10.10.0.1 255.255.255.255"
    
    ### Die Netze der anderen Clients. Nicht das von diesem Client eintragen!
    push "route 192.168.10.0 255.255.255.0"
    push "route 192.168.11.0 255.255.255.0"
    push "route 192.168.20.0 255.255.255.0"
    push "route 192.168.21.0 255.255.255.0"
    
    # Der Client teilt dem Server sein eigenes Netz mit. Hier kommt das Netz dieses OpenVPN-Clients rein.
    route 192.168.100.0 255.255.255.0
    
    ### falls man aus div. Gründen das Internet durch den Tunnel jagen möchte...
    
    # Der Client wird angewiesen, den gesamten Traffic
    # durch den Tunnel zu schicken.
    #push "dhcp-option DNS 208.67.220.220"
    #push "redirect-gateway def1"
    

    Jeder kann sich nun hiermit seinen eigenen Reim draus machen, was er wo einstellen will oder nicht.

    Ob das nun der richtige Weg ist oder nicht, ist mir grad egal, denn er führt mich zu meinem Ziel, einen brauchbaren UDP-Tunnel aufzubauen.

    NACHTRAG:
    Ich wollte hier keine negative Kritig bezgl. PFsense äußern, lediglich einen ggf. auch mehrere Fehler aufzeigen und dass man auch diese, wenn auch nicht perfekt, lösen kann.
    PFsense ist imho eine nahezu perfekte Routersoftware, die ich durchaus weiterempgehlen kann.



  • Es wäre sehr schön wenn Du aus diesen Informationen einen offiziellen Bugreport machen könntest.


Locked