[Gelöst] [be.ip plus] Routing für OpenVPN

[Tom7320]

Hallo!

Im LAN habe ich einen gerouteten OpenVPN Server, den ich gerne aus dem Internet erreichen würde. Die Eckdaten:

• IP Adresse des OpenVPN Servers: 192.168.0.43, Port 1194, UDP
  
• Durch das geroutete OpenVPN genutzete Netzwerk: 10.205.74.0/24

Nichts einfacher als das dachte ich und habe konfiguriert:

• NAT-Konfiguration, Port Forwarding vom WAN auf das Ziel 192.168.0.43:
  
  
• Firewall, IPv4-Filterregeln WAN geöffnet:
  

Soweit so einfach. VPN Verbindung kann auch aufgebaut werden. Allerdings erreiche ich noch keine Rechner im 192.168.0.0/24 Netz. Logisch. Route vergessen. Also Route angelegt:


Klappt nur leider noch immer nicht. VPN Verbindung wird hergestellt, aber ich erreiche noch immer keine Rechner im besagten Netz. Was habe ich nur vergessen???

THX!

Thorsten

 

[weißnix_]

Muss nicht der OVPN-Server das Routing zwischen den beiden Netzwerken machen?
Will heißen, letzterer Routingeintrag gehört nach meinem dafürhalten in dessen Konfig und er muss die Route auch an die Clients veröffentlichen.

 

[Tom7320]

Naja der Aufbau ist ja quasi so:

                         +-------------------------+
              (public IP)|                         |
 {INTERNET}=============={     Router              |
                         |                         |
                         |         LAN switch      |
                         +------------+------------+
                                      | (192.168.0.1)
                                      |
                                      |              +-----------------------+
                                      |              |                       |
                                      |              |        OpenVPN        |  eth0: 192.168.0.43/24
                                      +--------------{eth0    server         |  tun0: 10.205.74.0/24
                                      |              |                       |
                                      |              |           {tun0}      |
                                      |              +-----------------------+
                                      |
                             +--------+-----------+
                             |                    |
                             |  Other LAN clients |
                             |                    |
                             |   192.168.0.0/24   |
                             |   (internal net)   |
                             +--------------------+

Das Einzige, was ich getan habe, ist den Router zu tauschen. Es war eine Fritzbox und ist jetzt die be.ip. Von daher schließe ich ein Problem mit dem OpenVPN Server und dessen Routing aus. Mit der Fritzbox musste ich genau zwei Dinge konfigurieren, damit es funktioniert:

1. Portfreigabe/Weiterleitung vom Internet Port 1194/UDP auf den OpenVPN Server im LAN 192.168.0.43:1194
2. Manuelle Route für das Netz 10.205.74.0/24 via Gateway 192.168.0.43 (OpenVPN Server) setzen

Bei der be.ip kam jetzt noch die oben genannte Firewall Regel dazu, um den Zugriff vom Internet auf den OpenVPN Server zuzulassen. Was meiner Meinung nach jetzt noch fehlt, ist eine Regel, die Verkehr aus dem 10.205.74.0/24 Netz in das 192.168.0.0/24 Netz und zurück erlaubt:



Wenn ich die Firewall ganz abschalte funktioniert es bestens, so dass ich mir quasi sicher bin, dass es sich um ein Problem mit der Firewall handelt. Nur ich komme leider nicht darauf, was ich falsch gemacht habe?!?!

 

[weißnix_]

Ähm die zweite Regel ist für mich nicht logisch: Du erlaubst nur den lokalen Zugrif auf 1194. Da sollte dann Any oder eine entsprechende Dienstegruppe erlaubt werden.

 

[Tom7320]

Hm. So geht es auch nicht:

Ich müsste mal live das Firewall Log sehen und schauen was geblockt wird. Geht das irgendwie?

 

[weißnix_]

Das Log:
Loglevel auf debug stellen.
Da in wenigen Minuten mehr als 1000 Einträge zusammenkommen können ist der interne Speicherbereich viiiel zu klein. Deshalb einen externen syslogserver aufsetzen.

Lief die Fritte vorher im gleichen Adressbereich? Ich denke immer noch, das die Serverkonfi irgendwie krumm ist. Ich hab auch einen OVPN-Server im Netz hinter der be.ip und hab dafür an der be.ip nur die OVPN-Forwarding-Regel. Das Natting in's lokale Netz macht der OVPN-Server.

 

[Tom7320]

Problem gelöst! Es muss die vollständige IPv4 Filterung deaktiviert sein, dann klappt es:



Es gibt zwar einen FAQ Eintrag bei Bintec dazu, aber in Zusammenhang mit OpenVPN ist mir die Option noch nicht so ganz klar. Was passiert schlimmes wenn ich sie deaktiviere? Warum kann ich Hosts im LAN bei aktivierter vollständiger Filterung zwar anpingen aber keinen Dienst wie z.B. HTTP erreichen? Ich würde gerne verstehen....

@weißnix_: Ist die Option bei Dir an oder aus?

 

[weißnix_]

An!
Ich bin mir jetzt zwaar nicht sicher, aber im Augenblick bin ich bei meinen Firewallversuchen auf dem Stand, das LAN-Local die interne Schnittstelle der be.ip ist.
So sind auch meine FW-Regeln gesetzt. Mein internes Netzwerk ist auf "nicht vertrauenswürdig gesetzt, was für allee Zugriffe eine FW-Regel erforderlich macht.
Im lokalen Neetz musst Du dabei die be.ip einfach nur als Switch betrachten. FW-Regeln benötigst Du erst, wenn ein Zugriff auf die be.ip erfolgt oder über diese hinausgeht (WAN).
IMHO taucht das OVPN-Subnetz garnicht im lokalen Netz auf, weil der OVPN-Server eigentlich als gateway fungiert und damit mit seiner Adresse im internen Netz agiert. Wenn die Pakete vom OVPN-Netzt über die be.ip geroutet werden läuft IMHO was verkehrt.

Edit: Ich glaube ich ahne wo es hakt. Bei mir kommt es nicht auf den Fall an, das aus dem lokalen Netz eine Verbindung zu den OVPN-Clients aufgebaut werden muss. Die remote Clients nutzen nur einzelne Dienste im lokalen Netz.
Wenn es bei Dir auch in der gegenrichtung geht würden abgehende Daten scheinbar über die be.ip geroutert werden. Rücklaufende Pakete erreichen die lokalen Rechner dagegen direkt--> unvollst. Session.

Bei mir ist die Lage etwas anders: Der OVPN-Server ist auch für alle lokalen Clients das Gateway in alle Netzwerke. Dadurch laufen alle Sessions vollständig über diesen Rechner. Die be.ip ist bei mir nicht das Default-Gateway im Netz.
Meine Basis-Struktur entsprich etwa dem hier (ist seitdem etwas gewachsen): https://telekomhilft.telekom.de/t5/...lisierungsbox-Prem-und-WLAN/m-p/1468147#M2135

 

[Tom7320]

Hm. Ja. Klingt logisch. Allerdings war es auch bei der Fritte notwendig die Route für das Netz 10.205.74.0/24 via Gateway 192.168.0.43 (OpenVPN Server) in die Routingtabelle einzutragen! Insofern kann es nicht ganz stimmen was Du sagst. Aber ich gestehe, dass ich es auch nicht ganz verstehe. Wenn ich mich als Roadwarrior mit meinem VPN verbinde und eine Webseite aufrufe, was ist dann die source address? Ich dachte in meinem Fall eine IP aus dem 10.205.74.0 Netz (VPN Tunnel). Das NATing macht daraus eine öffentliche IP. Diese IP steht dann als destination address auf dem Antwortpaket des Server. Das NATing ersetzt dann die öffentliche IP wieder durch die 10.205.74.0. Der Router (egal ob Fritte oder be.ip) muss dieses Paket dann über den OpenVPN Server routen. Daher braucht man den oben genannten Eintrag in der Routingtabelle. Und deshalb scheint es auch nicht mit aktivierter Vollständiger IPv4 Filterung zu funktionieren, auch wenn ich noch nicht ganz verstehe, was genau diese Option macht....

Gibt's hier Routingexperten????

 

[weißnix_]

Ich bin doch schon zurückgerudert
Ja, die Route ist erforderlich - Ich hatte im ersten Ansatz vergessen, das bei mir der OVPN-Server auch das Default-Gateway für das ganze Netz ist. Da brauch ich das nicht.
Aber es erklärt für mich auch, warum der Schalter bei Dir nicht aktiviert sein darf. Weil nur ein Teil der Pakete geroutet werden muss. Alle Pakete vom VPN in Dein Netz kennen den Weg ohne Routingeintrag.
Die Option ist doch ganz gut in der Hilfe erklärt: Alle Pakete einer Session müssen von der Firewall gesehen werden. Hin und Zurück. Kennt ein Teil der Pakete den Weg ohne Routing, werden die nicht gesehen und die Session ist aus Sicht der be.ip unvollständig.

 

[Tom7320]

Jo, hast recht. Habe gestern eine Weile mir mit Wireshark die Pakete angeschaut. tcpdump auf der be.ip würde mir jetzt noch fehlen um das Ganze aus Sicht des Routers zu betrachten....

 

[weißnix_]

Die be.ip kann Traces erstellen.

 

[Tom7320]

Och nöööööö! Sag mir sowas doch nicht am Wochenende! Jetzt schau ich mir wieder stundenlang tcpdumps an und meine Frau denkt endgültig der ist total besch****
Ich muss mich jetzt eh erstmal ganz banal mit den Voice Applikationen beschäftigen....

 

[weißnix_]

Das denken die Frauen sowieso. Egal was wir machen. Telefonie hat einfach zu funktionieren. Wenn es mal nicht geht gibts dafür null Verständnis.

 

[Tom7320]

Oooohhhhh wie Recht Du doch hast!!!
In diesem Sinne ein schönes Wochenende!

 

[Tom7320]

Zum Abschluss des Themas fasse ich hier mal kurz die gewonnenen Erkenntnisse zusammen, damit es für andere, die einen OpenVPN Server hinter einer be.ip betreiben wollen, einfacher ist:

Erster Schritt:
Zwei der im ersten Post genannten Schritte sind auf jeden Fall nötig:

1. Portforwarding vom WAN auf den OpenVPN Server einrichten. Netzwerk -> NAT -> NAT Konfiguration wie im ersten Post beschrieben.
2. Zugriff durch die Firewall erlauben. Firewall -> Richtlinien -> IPv4-Filterregeln ebenfalls wie im ersten Post beschrieben. Vorher unter Firewall -> Adressen und Firewall -> Dienste den OpenVPN Server und den OpenVPN Dienst entsprechend den lokalen Gegebenheiten anlegen.

Als zweiten Schritt kann man sich dann zwischen zwei Varianten entscheiden. Beide Varianten sind meines Erachten bzgl. der Performance gleichwertig. Die eine Variante erfordert weitere Konfigurationen an der be.ip, die andere erfordert NATing beim OpenVPN Server.

Zweiter Schritt Variante A:
Die be.ip muss den Netzwerkverkehr des OpenVPN Netzes (10.205.74.0/24 im Beispiel) korrekt routen und darf ihn nicht filtern. Dafür sind zwei Einstellungen nötig:

1. Rote manuell anlegen. Unter Netzwerk -> Routen eine Route anlegen, damit die be.ip weiß wo Pakete in das OpenVPN Netz hin geroutet werden sollen. Ziel-IP ist also das 10.205.74.0 Netz, Gateway der OpenVPN Server (192.168.0.43 im Beispiel).
2. Unter Firewall -> Richtlinien -> Optionen die "Vollständige IPv4-Filterung" abschalten, damit Pakete an das 10.205.74.0er Netz nicht verworfen werden.

Zweiter Schritt Variante B:
Alternativ arbeitet man mit NATing auf Seiten des OpenVPN Servers. Aus Sicht der be.ip kommen dann nur Pakete für das 192.168.0.0er Netzwerk vorbei, so dass bei dieser Variante keine weitere Konfiguration auf Seiten der be.ip mehr nötig ist. Dafür muss man auf dem OpenVPN Server das NATing konfigurieren. Hier als Beispiel iptables für für Linux:

iptables -A FORWARD -o eth0 -i tun0 -s 10.205.74.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Das sollte es gewesen sein. Vielleicht hilft es ja jemand....

Schönen Feiertag!

Thorsten

 

[wagman77]

Herzlichen Dank an den Thread-Ersteller Thorsten.
Dank dieser Anleitung habe ich es geschafft, einen Linux OpenVPN Server hinter einer Bintec Be.IP plus ans Laufen zu bringen.
Ich habe mich für "zweiter Schritt Variante A entschieden.

 

[Tom7320]

Vollzitat von darüber entfernt by stoney

Gerne! Freut mich, dass es geholfen hat. Ich fand es damals nicht gerade trivial. Aber seitdem läuft es bei mir genauso wie beschrieben unverändert und stabil.

PS: Man könnte sich ja mal an WireGuard wagen...

Schönen Sonntag!

 

[pdsc]

Auch wenn es jetzt schon eine Weile her ist, läuft der OpenVPN noch immer bei dir Thorsten?

Ich versuche ganz banal einfach nur einen OpenVPN Server hinter der be.IP Plus zu konfigurieren. Das Portforwarding und die Firewall-Regeln habe ich jetzt gefühlte 1000+ x geprüft und kann keinen Fehler feststellen. Grundsätzlich erhalte ich vom OpenVPN-Client immer einen TCP Handshake Fehler.

Irgendeinen Tipp, was ich vergessen haben könnte?