[Frage] OpenVPN hinter be.IP Plus und Routing

[Angel2k]

Hallo Leute, ich hätte da mal eine kleine Frage... ich bin ein gewohnheitstier und habe für fast jede VPN Verbindung die ich benutze immer OpenVPN dabei. Das erspart mir das lästige installieren von zig Programmen. Da ich auch Freunden, Bekannten sowie Kunden helfe die eine DigiBox, eine FritzBox, ein Lancom (oder sonstige) Router haben, setze ich meist auf einem System welches sich hinter dem Router befindet, einen OpenVPN Server auf und fertig ist.

Ich weiß, die DigiBox sowie der be.IP Plus haben einen VPN Dienst, aber dafür müsste ich wieder eine weitere Software installieren, möchte ich nicht, darum geht es mit OpenVPN weiter.

Bei uns in der Firma wo ich hauptberuflich tätig bin, habe ich hinter unserer DigiBox auf einem Linux System ein OpenVPN Server installiert und wenn ich zuhause bin, kann ich darauf zugreifen und kann alle Clients und Systeme via RDP, SMB etc. erreichen. Nun steht bei einem Bekannten von mir in seinem Homeoffice ebenfalls ein kleiner Linux Server mit OpenVPN und ein be.IP Plus hängt dort an der Wand. Die Verbindung zum OpenVPN klappt problemlos, Tunnel wird aufgebaut, Routing im Server selbst klappt, denn diesen kann man über seine lokale IP erreichen, SMB sowie Putty klappt auch alles.

Nun wollten er aber auch auf die Drucker oder einen seiner zwei PCs von Unterwegs zugreifen. Entweder via RDP, TeamViewer (via IP) oder andere Fernwarutungs Programme. Allerdings klappt das nicht... die Router zum Client selbst klappt, aber die Rück-Route vom Client zum VPN-Gateway zu dem verbundenen Clien (Notebook) klappt nicht. Die Netze sehe wie folgt aus,
- 192.168.21.0/24 (1 ist Server, 254 ist be.IP Plus)
- 10.8.0.0/24 (OpenVPN Tunnel)

Da mein Setting in der Firma in der DigiBox klappt, hab ich mir dieses zur Kontrolle noch einmal angeschaut...
-> Netzwerk -> Routen -> Konfig von IP4-Routen -> Netzwerkroute via Gareway (10.8.0.0/24, 192.168.21.1, BRIDGE_BR0, Metrik 0)

Durch diese Regel kann ich auch von meinem Notebook (10.8.0.6) den Client 192.168.21.11 via ping erreichen, aber eine Verbindung aufbauen geht nicht. Bei der Firewall bin ich dann zum testen in die Richtlinien -> Optionen und deaktivierte die IPv4-Firewall. Dann funktionierte die Kommunikation... OK, also eine Filterregel hinterlegen doch da scheitert es und ich hab einen Denkfehler. Wenn ich eine neue Regel anlege, sollte diese doch wie folgt sein...
- Quelle = das lokale LAN
- Ziel = der Gateway oder das VPN Netz?
- Service = any
- aktion = zugriff

oder mache ich da irgendwo einen Denkfehler? In der DigiBox hab ich diese Regel nicht benötigt weil die IPv4-Firewall deaktiviert ist. Vermutlich, weil ich dort das gleiche Problem hatte, aber aufgrund des Vorfalls mit dem Arzt (angepinntes Topic) werde ich diese demnächst auch wieder einschalten. Wobei ich die externen Zugriffe bei uns schon geprüft habe. Noch ist alles "safe".

Ich würde mich aber schon mal über einen Tipp bezüglich des Routings bedanken. Ich weiß, viel Text... aber bevor zig fragen kommen die mir noch nicht helfen, versuche ich gerne etwas Klarheit zu verschaffen.

Mfg. Angel

Nachtrag: Sehe gerade, dass Thema mit dem Arzt und der Sicherheitslücke war gar nicht angepinnt. Aber ich denke wir wissen was ich meine.

 

[Limer]

Wenn ich deinen text richtig verstehe geht es wenn du die Firewall auf .21.11 komplett deaktivierst?
-> Du musst (am besten die vorhandenen) Regeln für RDP richtig anpassen/schreiben/setzen.

Google Search

- Quelle ist definitiv NICHT das lokale Subnetz (192.168.21.0/24) sondern das VPN Netz (10...../24)
- Ziel? Es muss eine eingehende Regel sein. Das Ziel ist der PC zu dem du die RDP Verbindung aufbauen willst.
- Service?
- "Aktion = Zugriff" Erlauben?

 

[Angel2k]

Moin... war von mir vielleicht etwas doof formuliert. Aber nein, es geht nicht um die Firewall Regeln der Clients, dass Problem ist die Firewall Regel im be.IP Plus (192.168.21.254), denn sobald diese deaktiviert ist (Firewall -> Richtlinie -> Optionen, Status der IPv4-Firewall = deaktiviert) funktioniert das routing.

Die Verbindungen an den Clients funktioniert, dass habe ich innerhalb des 192.168.21.0/24 getestet... Die Firewall im be.IP Plus scheint die Rückroute irgendwo zu blockieren. Ich könnte nun auch jedem Windows Client händisch die Rückrouter mitteilen (damit klappt es sogar), aber das möchte ich gerne vermeiden und der Gateway / Router (be.IP Plus) soll die Route verwalten.

 

[Limer]

Hat mich auch ein wenig gewundert das du Subnetze mit Bitmask angibst aber an der Windows Firewall scheiterst ;-)
Da ich den be.IP Plus überhaupt nicht kenne kann ich dir da nicht weiter helfend aber deine Überlegung sieht dafür imho gut aus.

- Quelle = das lokale LAN
- Ziel = der Gateway oder das VPN Netz?
- Service = any
- aktion = zugriff

Kannst ja einfach testweise zwei regeln anlegen.

 

[Angel2k]

Ja, /24 lässt sich schneller aufschreiben als die komplette Subnetzmaske. Ich es aber mal so, wir kochen doch alle nur mit Wasser. Jeder hat da irgendwo seine Stärken und Schwächen

Aber kommen wir zum Kern der Frage / Problem... da mich interessiert hatte, was die Firewall an sich so tut und filtert, habe ich noch einmal die Suchmaschine angeschmissen und ganz simple "be.ip ipv4-firewall" gesucht und bin dabei auf diesen Treffer gestoßen. Das interessante ist, dass das Szenario welches ich habe dort vorhanden ist. Die vollständige IPv4-Filterung wäre also laut dieser Dokumentation das Problem.

Ich habe diese einmal deaktiviert, meine Einstellungen übernommen und siehe da... via TeamViewer kann ich sogar die Clients ansprechen. Auch der drucker ist über das Webinterface erreichbar. RDP teste ich nachher bei mir und wenn das klappt, kann ich ihm mitteilen dass er nun loslegen kann

Wenn jetzt ein be.IP Plus Spezie hier vorbei schaut, würde mich mal interessieren ob man nicht eine Filterregel hinterlegen kann die dieses Phänomen irgendwie zulässt. Oder gibt es da generelle Probleme?

 

[weißnix_]

Noch ein Treffer: Ich hatte ein deja vu beim Threadtitel.

 

[Angel2k]

Alles klar, mein Fehler bei der Suche... und als ich die Suchmaschine belästigt hatte, war mein such Term wohl nicht die beste Variante, aber gut... das Thema gab es ja dann schon mal und die Lösung aus Post 16 mit dem maskieren der IP Adressen wäre mit definitiv auch gegangen. Hätte ich auch von selbst drauf kommen können, wollte aber gucken ob es auch anders klappt.

Aber die Logik der Firewall (ich lasse nur durch was ich schon mal gesehen habe), also das mit den unvollständigen Sessions ergibt Sinn. Es ist nur schade, dass man dafür keine explizite Regel hinterlegen kann. Dann ist es auch kein Wunder, dass zwar meine Routing Regel korrekt war war, es aber bei den Firewall-Filter-Regeln harkt. Aber gut, ist halt nicht alles Gold was glänzt. Dann also IP am VPN Server maskieren oder "Vollständige IPv4-Filterung" deaktivieren

Das gute ist, dass Wissen kann ich am Wochenende gleich weiter nutzen. Ein weiterer Bekannter von mir hat sich gerade selbstständig gemacht und da kommt ebenfalls ein be.IP Plus inkl. IP630 Telefonen zum Einsatz. Mal schauen wie gut das alles klappt

Ich bedanke mich aber schon mal bei euch beiden für die Anteilnahme und wünsche noch einen angenehmen Abend.

Mfg. Angel

 

[CapFloor4711]

Hi,

Wenn jetzt ein be.IP Plus Spezie hier vorbei schaut, würde mich mal interessieren ob man nicht eine Filterregel hinterlegen kann die dieses Phänomen irgendwie zulässt.

Mit einer Route läßt sich dieses Problem nicht lösen: Die Pakete werden in deiner Konstellation auf unterschiedlichen Wegen hin und zurück geroutet. Üblicherweise spricht das für ein "suboptimales" Netzwerkdesign. Deshalb gibt es auch die "Vollständige IPv4-Filterung" Option in der be.ip: Pakete, die auf ihrem Hinweg nicht an der be.ip vorbeigekommen sind, dies aber auf ihrem Rückweg tun, werden verworfen. Eigentlich keine schlechte Idee!

Um diese Situation zu beseitigen, muss man ein SourceNAT am LAN-Interface des VPN-Servers für Pakete aus dem Tunnel konfigurieren. Dann kommen auch die Antwortpakete nicht mehr am Router vorbei, sondern landen direkt wieder beim VPN-Server.

VG