7
PfSense und OpenVPN - Hartnäckiges Routing Problem im Remote-Netz erfolgreich gelöst, wie immer. Mit funktionierender, getesteter Konfiguration.
καλημέρα, liebe Kolleginnen und Kollegen,
ich hatte ein hartnäckiges Problem mit dem Routing zwischen OpenVPN (mit GUI) und pfSense. Die VPN-Verbindung wurde erfolgreich hergestellt, aber ausser der pfSense-Box konnte kein weiterer Rechner im Remote-Netz erreicht werden. Dieses Problem hatte mich ja so heftig, so lange und so ausdauernd geplagt, weil ich ständig versucht war, an der falschen Stelle nach einer Lösung zu suchen. Aber mit griechischer Gewitztheit und Schläue gelang es mir natürlich auch dieses mal wieder, das Problem zu lösen und alle glücklich zu machen.
Nun die schmutzigen Details.
Zweignetz: 192.168.158.0/24
Hauptnetz (remote): 10.100.100.0/24 (10.0.0.0/8)
OpenVPN-Tunnelnetz: 172.19.48.0/24
Das Tunnelnetz habe ich bewusst in einen eigenen privaten IP-Adressraum versetzt, der sich sowohl von dem 192.168-Zweignetz als auch von dem 10-Netz des Hauptnetzes unterscheidet. Der Hauptgrund: So sehe ich auf den ersten Blick: 172 - damit beginnt der Tunnel und damit endet der Tunnel. Wenn ich 172 sehe, weiss ich, das ist der VPN-Tunnel und sonst nichts. Tunneleingang - 172.19.48.2, Tunnelausgang 172.19.48.1, fertig. Die IP-Adressen des Tunnelnetzes interessieren sonst keinen Endanwender.
Ich komme so auch nicht durcheinander und handele mir Probleme ein, beispielsweise mit der versehentlichen Vermischung von 10.0.0.0/8 und 10.100.100.0/24 - Teilnetzen - VPN-Verbindungen können bekanntlich recht zickig reagieren, wenn sich irgendwelche IP-Adressbereiche nicht deutlich voneinander abgenzen lassen.
Die initiale Konfiguration der pfSense-Box im 10er - Hauptnetz wurde zunächst vorgenommen, wie weiter unten beschrieben.
Die VPN Verbindung wurde erfolgreich hergestellt (der Port 1194 war also offen und durchgängig, entsprechende Löcher in alle zwischenliegenden Firewalls wurden erfolgreich gebohrt). Es traten keine Fehler im OpenVPN-Log auf, insbesondere keine "TLS-Handshake"-Fehler. OpenVPN GUI zeigte die erfolgreiche Kontaktaufnahme mit einem grünen Symbol an und wies per Balloon-Poop-Up darauf hin, die Verbindung sei erfolgreich hergestellt.
Hauptnetz mit Windows 2008 - Server: 10.0.0.0/8, hauptsächlich benutzt wird nur das 10.100.100.0-Teilnetz.
pfSense wird parallel zu einem Gateway (-Router / Firewall) betrieben. Der Gateway für das Remote-Netz besitzt ganz griechisch traditionell die interne IP-Adresse 10.100.100.1, pfSense lauscht nach innen auf der Lan-Schnittstelle mit der IP-Adresse 10.100.100.15. WAN-seitig sind die Interfaces des Gateways und der pfSense jeweils mit einer öffentlich gültigen IP-Adresse ausgestattet - ein ungewöhnlicher Luxus hier in Griechenland.
Vom Zweignetz aus (über das 192.168.158.x Subnetz; 192.168.158.1 als GW) konnte ich mich mit der öffentlichen IP-Adresse der pfSense (also der pfSense-WAN-Schnittstelle) verbinden. Das VPN (vom Windows 8.1-Testrechner per OpenVPN GUI, gestartet mit administrativen Rechten) kam tadellos zustande. Dem TAP-Adapter wurde eine IP-Adresse aus dem Bereich 172.19.48.0/24 zugewiesen. Der Testrechner erhielt während unserer Verbindungsexperimente für das OpenVPN-Tunnelende meistens die 172.19.48.2, seltener die 172.19.48.3, der pfSense Rechner als anderer (Remote-) Endpunkt des Tunnels vergab an sich selbst immer fix die 172.19.48.1.
"Von aussen" war der Remote-Endpunkt des Tunnels 172.19.48.1 (VPN-Tunnelnetz) anpingbar und die (remote-) LAN-Seite der pfSense unter 10.100.100.15 (internes Netz) ebenfalls. Das remoteseitige 10.100.100.0/24er Subnetz war also prinzipiell vom Zweignetz aus erreichbar. Allerdings war kein einziger Rechner aus dem 10.100.100.0/24 Netz über VPN anzupingen, wohl aber jeweils remote vor Ort innerhalb des lokalen Netzes (10.100.100.0/24).
Das Web-Interface der pfSense konnte ich sowohl aus dem 10.100.100.0/24 im lokalen Netz, als auch via VPN aus dem 192.168.158.0/24 Subnets ordnungsgemäß über Webbrowser aufrufen, jeweils indem ich mich in der Adresszeile des Browsers mit der 10.100.100.15 (also mit dem internen Subnetz unseres Import / Export-Unternehmens) verband. Ich bekam die pfSense Oberfläche auch über die Eingabe des 172.19.48.1 (Remote-) Tunnel-Endpunktes 10.129.78.1. Ich konnte also über VPN genauso auf die pfSense-Oberfläche zugreifen, als säße ich bei uns im Büro in Πειραιάς. Nach Eingabe von Benutzername und Passwort allerdings, die pfSense klaglos akzeptiere hat, quittierte pfSense über die Remote-Tunnel-Endpunktadresse alle weiteren Konfigurationsversuche mit einer pfSense spezifischen 501-Fehlermeldung, sowohl lokal wie auch remote.
Der VPN-Verbindungsaufbau klappte also tadellos, aber mit dem Routing gab es wohl Probleme. Also habe ich zunächst von der Möglichkeit Gebrauch gemacht, der pfSense über die "Alternate" OpenVPN-Einstellungen Routen an die Klienten mitzugeben:
Advanced:
route 10.100.100.0 255.255.255.0 10.100.100.15;
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
client-to-client
Der route-Befehl informiert die pfSense-Box, Pakete an die genannten Adressen über den Tunneleingang (172.19.48.1) nach außen (172.19.48.2) zu schieben. Der push "route ..." Befehl informiert die OpenVPN-Gegenstelle, entsprechend adressierte Pakete doch bitteschön zurückzuschieben.
Ich war also der Meinung, dass pfSense die erforderlichen Routen aus dem 10er Hauptnetz an den Klientencomputer im 192.168.158er Netz übermittelt. Trotzdem konnte ich aus dem 192.168er Netz nur das Tunnelende 172.19.48.1 im Import-/Export-Büro sowie die zugehörige 10.100.100.15 per Ping erreichen. Allerdings war kein weiterer Rechner des 10er Netzes per Ping zu erreichen. Ich dachte zunächst, mein Ping wird nicht in das 10er Netz des Büros übermittelt.
Dann stolperte ich über diesen Artikel:
https://community.openvpn.net/openvpn/wiki/RoutedLans
Und auf einmal fiel es mir wie Schuppen aus den Haaren: Was wäre, wenn mein Ping - Befehl sehr wohl ins 10er Subnetz übermittelt würde, nur wüsste der betreffende Zielrechner nicht, auf welcher Route er mir seine Antwort übermitteln könnte und die Antwort würde im digitalen Nirvana landen.
OK, ich habe also meinen guten Freund Eleftherios Sakrattis kontaktiert (ob seiner Leibesfülle darf ich ihn auch liebevoll "Elefantherios" nennen, aber nur ich). Elefantherios hielt sich zu diesem Zeitpunkt zufällig gerade in Αλεξανδρούπολη auf - ideal für Routing-Experimente! Denn eine größere Distanz als zwischen Αλεξανδρούπολη und Πειραιάς lässt sich in Griechenland ja fast gar nicht überbrücken. Unsere Überlegung: Würden wir es schaffen, die Verbindung über die Langdistanz zwischen Αλεξανδρούπολη und Πειραιάς erfolgreich zu überbrücken, dürfte die viel kürzere Verbindung zwischen Αθήνα (da wo mein Scheff wohnt) und Πειραιάς erst recht keine Probleme bereiten.
Elefantherios, seines Zeichens ein ausgesprochen erfolgreicher griechischer MCSE, erklärte sich großzügig bereit, die Rolle der Zweigstelle auszufüllen. Ich schickte ihm also einen USB-Stick mit den erforderlichen .ovpn-Konfigurationsdateien und Zertifikaten per ΕΛΤΑ und nur drei Wochen später hielt Elefantherios schließlich den Brief mit dem USB-Stick in der Hand. Nun konnte es losgehen: Ich in der Zentrale in Πειραιάς und Elefantherios von der simulierten Zweigstelle in Αλεξανδρούπολη. In einer stürmischen, griechischen Nacht, verbunden nur über eine zitternde Telefonleitung, ständig vom Abbruch der Verbindung bedroht. Two nobodies on a road to nowhere.
Und so analysierten wir den Netzwerk-Verkehr auf der pfSense mittels der eingebauten Tools: Routenlisten, Packet-Capture, ARP-Tables etc..., das volle Ballett. Mit Packet Capture konnten wir sehen, dass die Pakete aus Αλεξανδρούπολη tatsächlich in Πειραιάς ankamen:
IP 172.19.48.2 > 10.100.100.100: ICMP echo request, id 1024, seq 28416, length 40
aber die Antwort schlug fehl:
ARP, Request who-has 10.100.100.8 tell 10.100.100.100, length 46
Ziemlich interessant: Wir fanden also heraus, dass eine neue IP-Adresse auftaucht, die im lokalen Netz vorher nicht vergeben wurde (in unserem Falle 10.100.100.8). Diese konnten wir aber merkwürdigerweise von den Rechnern im Netz nicht erreichen (anpingen), auch machte sich diese Adresse gerne auf die eine oder andere Weise unsichtbar. Für uns ein Hinweis: Wir tauchen tatsächlich im Hauptnetz auf, aber irgend etwas stimmt hier noch nicht.
Wie teilt man dem Windows-Server nun mit, wohin er seine Pakete schicken soll? Microsoft stellt folgenden Artikel bereit:
http://msdn.microsoft.com/de-de/library/cc757323%28v=ws.10%29.aspx
Die Syntax des Route-Befehls ist
route add <Ziel> mask <Subnetzmaske> Gateway <metric> Kostenanzahl <1 - 9999> if <Schnittstelle>
Die Option -p verwandelt die temporäre Route in eine permanente. Gespeichet wird diese Route in der Registry und zwar hier:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\PersistentRoutes
Bevor man sich beim Experimentieren eine falsche Route permanent in die Registry brät, empfiehlt es sich, die u.g. Routenanweisungen zunächst ohne den -p Switch zu testen.
Wir denken uns das jetzt aus dem 10er Netz heraus und wollen Pakete aus dem 10er Netz über das 172-er Tunnelnetz in das 192.168er Netz der Zweigstelle befördern. Der für die Beförderung zuständige Rechner ist die pfSense-Box mit der 10.100.100.15 (und nicht etwa der Gateway mit der 10.100.100.1). Dementsprechend müssen wir dem Windows Server im 10er Netz (als Administrator) anweisen, alle Pakete an das Netz 192.168.158.0/24 an die IP-Adresse 10.100.100.15 zu schicken; diese würde sich schon um die entsprechende Weiterleitung kümmern. Wir müssen dem Windows Server also folgende Route mitteilen:
Diese Route alleine brachte uns allerdings noch nicht den gewünschten Erfolg. Elefantherios konnte von aussen den Windows-Server im Hauptnetz noch immer nicht anpingen. Wir mussten also außerdem noch probieren, dem Windows-Server den Weg zum Tunneleingang auf der pfSense weisen:
Und siehe da, von nun klappte es. Und auf einmal war alles möglich: Remote-Zugriff auf die Dateifreigaben etwa, oder die Möglichkeit, sich auf dem Windows Server per Remote-Desktop via VPN einzuloggen.
< Nachträglich geändert # 1: >
Ich habe u.g. Kommentare ausprobiert und die Routen direkt auf dem Default-Gateway 10.100.100.1 eingetragen. Das funktioniert übrigens hervorragend. Demzufolge setzt man die Routen (entgegen o.g. Anleitung) nicht auf dem Windows Server selbst, sondern auf dem Default-Gateway des zu routenden Netzes (hier also des 10.100.100.0/24 bzw. des 10.0.0.0/8 Netzes). Siehe unten für weitere Informationen. Vielen Dank für die Hinweise!
Hier zur Illustration noch ein paar aussagekräftige Screenshots mit beiden erforderlichen Regeln, die auf dem Default-Gateway 10.100.100.1 einzutragen sind. Diese enthalten die Routing-Informationen zur Weiterleitung von Paketen in das entfernte, private Netz (192.168.158.0/24) auf die pfSense Box mit dem OpenVPN-Tunnelausgang (10.100.100.15):
Getestet. Funktioniert.
Allerdings kann die o.g. Vorgehensweise, Routingeinträge direkt auf den betreffenden Rechnern vornehmen, statt auf dem Default-Gatewayrouter, für Szenarien sinnvoll sein, in denen explizit nur bestimmte Computer mit bestimmten, kontrollierbaren Freigaben ins VPN geroutet werden sollen. Also für den Fall, wenn nur bestimmte Rechner explizit über VPN erreichbar sein sollen und alle anderen Rechner des Netzes nicht. Dann ist zu beachten, dass die pfSense Box nicht der Default-Gateway des zu routenden 10-er Netzes sein darf und der Default-Gateway die Route zum VPN-Tunnel nicht kennen darf (die pfSense Box und der Default-Gateway sind also zwei unterschiedliche Systeme).
< /Nachträglich geändert # 1: >
Und so bleibt mir nur, mir selbst mal wieder zu sagen: Herzlichen Glückwunsch, Stronzolios. Bei aller Bescheidenheit: Das hast Du mal wieder fantastisch gemacht.
Elefantherios habe ich natürlich nach althergebrachter griechischer Tradition eingeladen zum Trinken und zum gemeinsamen Singen historischer griechischer Weisen:
"Griechisches Bier,
das schmeckt wie der Schweiss der Pferde. Komm, bring noch vier!"
(ok, der ist nicht von mir, aber trotzdem gut).
Ach ja, noch was: Der Rechner von Elefantherios, die "Zweigstelle", war hier mittels OpenVPN GUI direkt mit dem Tunneleingang verbunden. Das heisst, Elefantherios' Rechner "wusste" automatisch, wohin er die Pakete an "seinen" lokalen 172.19.48.2 - Tunneleingang schicken muss. Käme die Verbindung seitens der Zweigstelle stattdessen über einen Router zustande, müssten die entsprechenden Routen natürlich an allen betroffenen Rechnern der Zweigstelle entsprechend eingetragen werden, da diese ja dann ebenfalls nicht wüssten, wohin die Pakete in den 172er Tunneleingang zu routen wären.
< Nachträglich geändert # 2: >
Elefantherios kann remote über VPN natürlich nur die Rechner im Büro erreichen, bei denen die o.g. Routen gesetzt sind. Mal sehen, wie ich die Verteilung der Routen auf alle relevanten Rechner in unserem Import-Export-Laden (also auf zwei) automatisieren kann, aber das ist ein anderes Thema ...
Hat sich aufgrund u.g. Kommentare erledigt. Vielen Dank für die Tipps!
< /Nachträglich geändert # 2: >
Der Vollständigkeit halber hier noch die
Configuration "Road Warrior" - edit:
General Information
Anmerkung: OpenVPN GUI richtet per Default einen Tap-Adapter ein, keinen Tun-Adapter. Deswegen muss hier der "Device Mode" auf "tap" gesetzt werden. Für andere Szenarien bitte entsprechend anpassen.
Cryptographic Settings
Tipp: Wenn man sich nach klassischer griechischer Tradition eins drauf pfeift, dass die CA auf der selben pfSense-Box läuft wie der OpenVPN-Zugang, kann man die Zertifikate genau so einrichten wie in untem verlinkten Video beschrieben.So funktioniert's hier bestens für unsere Import-/ Export- Butze. Um unsere Datensicherheit brauche ich mir hier ohnehin keine allzu großen Gedanken machen: Wer auch immer an unsere Daten kommt und damit arbeitet, wird ebenso erfolglos bleiben wie wir.
Tunnel Settings
Client Settings
Advanced:
route 10.100.100.0 255.255.255.0 10.100.100.15;
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
client-to-client
Alle anderen Felder bleiben frei.
< Nachträglich geändert # 3: >
route und push route - Anweisungen werden nicht benötigt. Danke für den Hinweis an @aqui, siehe seinen u.g. Kommentar und Links.
Getestet. Funktioniert.
< /Nachträglich geändert # 3: >
Haben wir für erste Tests erst einmal "disabled". Man kann hier im Menü-Punkt "Advanced" für verschiedene Klienten-Remotenetzbereiche sog. iroutes definieren nach dem Muster
iroute 192.168.158.0 255.255.255.0
Diese Anweisung bewirkt, dass Pakete aus dem Klienten-Remotenetz nicht über den VPN-Tunnel ins Hauptnetz geschoben werden (dort haben sie ohnehin nichts verloren), sondern immer im Remotenetz verbleiben.
So könnte eine Konfiguration vollständig aussehen, wenn "enabled":
Weitere Optionen für den, der's braucht.
Neues Interface zufügen; das Interface heisst zunächst OPT1, wir benennen es später um in OpenVPN1194
Den Rest nicht ausfüllen bzw. keinen Haken setzen.
Die Reiter "Port Forward","1:1" und "NPt" enthalten in dieser Konfiguration jeweils keine Einträge.
Radiobutton "Manual Outbound NAT rule generation (AON - Advanced Outbound NAT)" anklicken und Regeln automagisch generieren lassen
Zusätzliche NAT-Regel für den privaten IP-Adressraum der Zweigstelle(n) hinzufügen; für jede Zweigstelle mit eigenem Adressraum eine eigene Regel erstellen:
Das Gleiche auch für das OpenVPN1194 Interface:
Den Rest jeweils nicht ausfüllen bzw. keinen Haken setzen.
Wir lassen alle "Default"-Regeln stehen, wie sie sind.
Aber ansonsten reissen wir willenlos alle Scheunentore auf und erlauben ganz großzügig alles:
Firewall - Die WAN-Konfiguration im Edit-Modus:
So sehen die Firewall-Regeln der WAN-Seite in der Übersicht aus (die grauen Felder sind "default"):
Und so sehen die Firewall-Regeln der LAN-Seite in der Übersicht aus:
Der Reiter "Floating" enthält in dieser Konfiguration keinen Eintrag.
General DNS Forwarder Options:
Enable - kein Haken bei "Enable DNS forwarder"; DNS Forwarding ist nicht aktiviert.
Die Option kann in Szenarien sinnvoll sein, in denen der DNS-Forwarder der pfSense Box Namensanfragen für eine lokale Windows-Domäne an den DNS des Windows-Servers weiterleiten soll, und die pfSense-Box die Rechner im Remote-Netz nicht selbständig als DNS über DHCP versorgen soll. Wir sind mit viel weniger zufrieden und lassen das weg, solange keiner danach fragt.
Unsere Erfahrung: Dateifreigaben und Remote-Desktop klappen auch ohne DNS-Forwarding, Domänen- und Active Directory Credentials werden vorher abgefragt. Unsere Empfehlung: Erst mal prüfen ob man's tatsächlich braucht und erst bei konkretem Bedarf konfigurieren.
Hier ein "modernes" Video für die erste Einrichtung von pfSense, interessant vor allem im Hinblick auf Erstellung und Einrichtung von Zertifikaten. So kriegt man erst einmal eine Grundkonfiguration, aber 100% fertig ist man noch nicht. Man kann aber so erst einmal bedenkenlos starten:
Einige Anregungen aus dieser reich bebilderten Konfigurationsanleitung waren sehr hilfreich:
http://swimminginthought.com/pfsense-routing-traffic-strongvpn-openvpn/
Das hatten wir zwischenzeitlich probiert, kamen aber zu dem Schluss, dass DNS-Port Forwarding keine Lösung für unser Problem ist:
https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_o ...
http://meandmymac.net/2013/12/pfsense-openvpn-site-site-dns-resolving/
Ebenfalls als nicht zielführend und eher zeitfressend erwiesen sich Hinweise, den "promicus mode" der NIC unserer pfSense-Box anzuschalten.
Oben erwähnter zentraler Artikel, der letztendlich half, das Routing-Problem in den Griff zu kriegen:
https://community.openvpn.net/openvpn/wiki/RoutedLans
So fügt man eine Route zu einem Windows - Rechner (Server) zu:
http://msdn.microsoft.com/de-de/library/cc757323%28v=ws.10%29.aspx
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
ich hatte ein hartnäckiges Problem mit dem Routing zwischen OpenVPN (mit GUI) und pfSense. Die VPN-Verbindung wurde erfolgreich hergestellt, aber ausser der pfSense-Box konnte kein weiterer Rechner im Remote-Netz erreicht werden. Dieses Problem hatte mich ja so heftig, so lange und so ausdauernd geplagt, weil ich ständig versucht war, an der falschen Stelle nach einer Lösung zu suchen. Aber mit griechischer Gewitztheit und Schläue gelang es mir natürlich auch dieses mal wieder, das Problem zu lösen und alle glücklich zu machen.
Nun die schmutzigen Details.
Übersicht
Zweignetz: 192.168.158.0/24
Hauptnetz (remote): 10.100.100.0/24 (10.0.0.0/8)
OpenVPN-Tunnelnetz: 172.19.48.0/24
Das Tunnelnetz habe ich bewusst in einen eigenen privaten IP-Adressraum versetzt, der sich sowohl von dem 192.168-Zweignetz als auch von dem 10-Netz des Hauptnetzes unterscheidet. Der Hauptgrund: So sehe ich auf den ersten Blick: 172 - damit beginnt der Tunnel und damit endet der Tunnel. Wenn ich 172 sehe, weiss ich, das ist der VPN-Tunnel und sonst nichts. Tunneleingang - 172.19.48.2, Tunnelausgang 172.19.48.1, fertig. Die IP-Adressen des Tunnelnetzes interessieren sonst keinen Endanwender.
Ich komme so auch nicht durcheinander und handele mir Probleme ein, beispielsweise mit der versehentlichen Vermischung von 10.0.0.0/8 und 10.100.100.0/24 - Teilnetzen - VPN-Verbindungen können bekanntlich recht zickig reagieren, wenn sich irgendwelche IP-Adressbereiche nicht deutlich voneinander abgenzen lassen.
Ausgangssituation
Die initiale Konfiguration der pfSense-Box im 10er - Hauptnetz wurde zunächst vorgenommen, wie weiter unten beschrieben.
Die VPN Verbindung wurde erfolgreich hergestellt (der Port 1194 war also offen und durchgängig, entsprechende Löcher in alle zwischenliegenden Firewalls wurden erfolgreich gebohrt). Es traten keine Fehler im OpenVPN-Log auf, insbesondere keine "TLS-Handshake"-Fehler. OpenVPN GUI zeigte die erfolgreiche Kontaktaufnahme mit einem grünen Symbol an und wies per Balloon-Poop-Up darauf hin, die Verbindung sei erfolgreich hergestellt.
Hauptnetz mit Windows 2008 - Server: 10.0.0.0/8, hauptsächlich benutzt wird nur das 10.100.100.0-Teilnetz.
pfSense wird parallel zu einem Gateway (-Router / Firewall) betrieben. Der Gateway für das Remote-Netz besitzt ganz griechisch traditionell die interne IP-Adresse 10.100.100.1, pfSense lauscht nach innen auf der Lan-Schnittstelle mit der IP-Adresse 10.100.100.15. WAN-seitig sind die Interfaces des Gateways und der pfSense jeweils mit einer öffentlich gültigen IP-Adresse ausgestattet - ein ungewöhnlicher Luxus hier in Griechenland.
Vom Zweignetz aus (über das 192.168.158.x Subnetz; 192.168.158.1 als GW) konnte ich mich mit der öffentlichen IP-Adresse der pfSense (also der pfSense-WAN-Schnittstelle) verbinden. Das VPN (vom Windows 8.1-Testrechner per OpenVPN GUI, gestartet mit administrativen Rechten) kam tadellos zustande. Dem TAP-Adapter wurde eine IP-Adresse aus dem Bereich 172.19.48.0/24 zugewiesen. Der Testrechner erhielt während unserer Verbindungsexperimente für das OpenVPN-Tunnelende meistens die 172.19.48.2, seltener die 172.19.48.3, der pfSense Rechner als anderer (Remote-) Endpunkt des Tunnels vergab an sich selbst immer fix die 172.19.48.1.
"Von aussen" war der Remote-Endpunkt des Tunnels 172.19.48.1 (VPN-Tunnelnetz) anpingbar und die (remote-) LAN-Seite der pfSense unter 10.100.100.15 (internes Netz) ebenfalls. Das remoteseitige 10.100.100.0/24er Subnetz war also prinzipiell vom Zweignetz aus erreichbar. Allerdings war kein einziger Rechner aus dem 10.100.100.0/24 Netz über VPN anzupingen, wohl aber jeweils remote vor Ort innerhalb des lokalen Netzes (10.100.100.0/24).
Das Web-Interface der pfSense konnte ich sowohl aus dem 10.100.100.0/24 im lokalen Netz, als auch via VPN aus dem 192.168.158.0/24 Subnets ordnungsgemäß über Webbrowser aufrufen, jeweils indem ich mich in der Adresszeile des Browsers mit der 10.100.100.15 (also mit dem internen Subnetz unseres Import / Export-Unternehmens) verband. Ich bekam die pfSense Oberfläche auch über die Eingabe des 172.19.48.1 (Remote-) Tunnel-Endpunktes 10.129.78.1. Ich konnte also über VPN genauso auf die pfSense-Oberfläche zugreifen, als säße ich bei uns im Büro in Πειραιάς. Nach Eingabe von Benutzername und Passwort allerdings, die pfSense klaglos akzeptiere hat, quittierte pfSense über die Remote-Tunnel-Endpunktadresse alle weiteren Konfigurationsversuche mit einer pfSense spezifischen 501-Fehlermeldung, sowohl lokal wie auch remote.
Problembeschreibung / Diagnose
Der VPN-Verbindungsaufbau klappte also tadellos, aber mit dem Routing gab es wohl Probleme. Also habe ich zunächst von der Möglichkeit Gebrauch gemacht, der pfSense über die "Alternate" OpenVPN-Einstellungen Routen an die Klienten mitzugeben:
Advanced:
route 10.100.100.0 255.255.255.0 10.100.100.15;
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
client-to-client
Der route-Befehl informiert die pfSense-Box, Pakete an die genannten Adressen über den Tunneleingang (172.19.48.1) nach außen (172.19.48.2) zu schieben. Der push "route ..." Befehl informiert die OpenVPN-Gegenstelle, entsprechend adressierte Pakete doch bitteschön zurückzuschieben.
Ich war also der Meinung, dass pfSense die erforderlichen Routen aus dem 10er Hauptnetz an den Klientencomputer im 192.168.158er Netz übermittelt. Trotzdem konnte ich aus dem 192.168er Netz nur das Tunnelende 172.19.48.1 im Import-/Export-Büro sowie die zugehörige 10.100.100.15 per Ping erreichen. Allerdings war kein weiterer Rechner des 10er Netzes per Ping zu erreichen. Ich dachte zunächst, mein Ping wird nicht in das 10er Netz des Büros übermittelt.
Lesen, Nachdenken und Ausprobieren
Dann stolperte ich über diesen Artikel:
https://community.openvpn.net/openvpn/wiki/RoutedLans
Und auf einmal fiel es mir wie Schuppen aus den Haaren: Was wäre, wenn mein Ping - Befehl sehr wohl ins 10er Subnetz übermittelt würde, nur wüsste der betreffende Zielrechner nicht, auf welcher Route er mir seine Antwort übermitteln könnte und die Antwort würde im digitalen Nirvana landen.
OK, ich habe also meinen guten Freund Eleftherios Sakrattis kontaktiert (ob seiner Leibesfülle darf ich ihn auch liebevoll "Elefantherios" nennen, aber nur ich). Elefantherios hielt sich zu diesem Zeitpunkt zufällig gerade in Αλεξανδρούπολη auf - ideal für Routing-Experimente! Denn eine größere Distanz als zwischen Αλεξανδρούπολη und Πειραιάς lässt sich in Griechenland ja fast gar nicht überbrücken. Unsere Überlegung: Würden wir es schaffen, die Verbindung über die Langdistanz zwischen Αλεξανδρούπολη und Πειραιάς erfolgreich zu überbrücken, dürfte die viel kürzere Verbindung zwischen Αθήνα (da wo mein Scheff wohnt) und Πειραιάς erst recht keine Probleme bereiten.
Elefantherios, seines Zeichens ein ausgesprochen erfolgreicher griechischer MCSE, erklärte sich großzügig bereit, die Rolle der Zweigstelle auszufüllen. Ich schickte ihm also einen USB-Stick mit den erforderlichen .ovpn-Konfigurationsdateien und Zertifikaten per ΕΛΤΑ und nur drei Wochen später hielt Elefantherios schließlich den Brief mit dem USB-Stick in der Hand. Nun konnte es losgehen: Ich in der Zentrale in Πειραιάς und Elefantherios von der simulierten Zweigstelle in Αλεξανδρούπολη. In einer stürmischen, griechischen Nacht, verbunden nur über eine zitternde Telefonleitung, ständig vom Abbruch der Verbindung bedroht. Two nobodies on a road to nowhere.
Und so analysierten wir den Netzwerk-Verkehr auf der pfSense mittels der eingebauten Tools: Routenlisten, Packet-Capture, ARP-Tables etc..., das volle Ballett. Mit Packet Capture konnten wir sehen, dass die Pakete aus Αλεξανδρούπολη tatsächlich in Πειραιάς ankamen:
IP 172.19.48.2 > 10.100.100.100: ICMP echo request, id 1024, seq 28416, length 40
aber die Antwort schlug fehl:
ARP, Request who-has 10.100.100.8 tell 10.100.100.100, length 46
Ziemlich interessant: Wir fanden also heraus, dass eine neue IP-Adresse auftaucht, die im lokalen Netz vorher nicht vergeben wurde (in unserem Falle 10.100.100.8). Diese konnten wir aber merkwürdigerweise von den Rechnern im Netz nicht erreichen (anpingen), auch machte sich diese Adresse gerne auf die eine oder andere Weise unsichtbar. Für uns ein Hinweis: Wir tauchen tatsächlich im Hauptnetz auf, aber irgend etwas stimmt hier noch nicht.
Das griechische Routing-Experiment
Wie teilt man dem Windows-Server nun mit, wohin er seine Pakete schicken soll? Microsoft stellt folgenden Artikel bereit:
http://msdn.microsoft.com/de-de/library/cc757323%28v=ws.10%29.aspx
Die Syntax des Route-Befehls ist
route add <Ziel> mask <Subnetzmaske> Gateway <metric> Kostenanzahl <1 - 9999> if <Schnittstelle>
Die Option -p verwandelt die temporäre Route in eine permanente. Gespeichet wird diese Route in der Registry und zwar hier:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip \Parameters\PersistentRoutes
Bevor man sich beim Experimentieren eine falsche Route permanent in die Registry brät, empfiehlt es sich, die u.g. Routenanweisungen zunächst ohne den -p Switch zu testen.
Wir denken uns das jetzt aus dem 10er Netz heraus und wollen Pakete aus dem 10er Netz über das 172-er Tunnelnetz in das 192.168er Netz der Zweigstelle befördern. Der für die Beförderung zuständige Rechner ist die pfSense-Box mit der 10.100.100.15 (und nicht etwa der Gateway mit der 10.100.100.1). Dementsprechend müssen wir dem Windows Server im 10er Netz (als Administrator) anweisen, alle Pakete an das Netz 192.168.158.0/24 an die IP-Adresse 10.100.100.15 zu schicken; diese würde sich schon um die entsprechende Weiterleitung kümmern. Wir müssen dem Windows Server also folgende Route mitteilen:
route -p add 192.168.158.0 mask 255.255.255.0 10.100.100.15 metric 2 Diese Route alleine brachte uns allerdings noch nicht den gewünschten Erfolg. Elefantherios konnte von aussen den Windows-Server im Hauptnetz noch immer nicht anpingen. Wir mussten also außerdem noch probieren, dem Windows-Server den Weg zum Tunneleingang auf der pfSense weisen:
route -p add 172.19.48.0 mask 255.255.255.0 10.100.100.15 metric 2 Und siehe da, von nun klappte es. Und auf einmal war alles möglich: Remote-Zugriff auf die Dateifreigaben etwa, oder die Möglichkeit, sich auf dem Windows Server per Remote-Desktop via VPN einzuloggen.
< Nachträglich geändert # 1: >
Ich habe u.g. Kommentare ausprobiert und die Routen direkt auf dem Default-Gateway 10.100.100.1 eingetragen. Das funktioniert übrigens hervorragend. Demzufolge setzt man die Routen (entgegen o.g. Anleitung) nicht auf dem Windows Server selbst, sondern auf dem Default-Gateway des zu routenden Netzes (hier also des 10.100.100.0/24 bzw. des 10.0.0.0/8 Netzes). Siehe unten für weitere Informationen. Vielen Dank für die Hinweise!
Hier zur Illustration noch ein paar aussagekräftige Screenshots mit beiden erforderlichen Regeln, die auf dem Default-Gateway 10.100.100.1 einzutragen sind. Diese enthalten die Routing-Informationen zur Weiterleitung von Paketen in das entfernte, private Netz (192.168.158.0/24) auf die pfSense Box mit dem OpenVPN-Tunnelausgang (10.100.100.15):
Getestet. Funktioniert.
Allerdings kann die o.g. Vorgehensweise, Routingeinträge direkt auf den betreffenden Rechnern vornehmen, statt auf dem Default-Gatewayrouter, für Szenarien sinnvoll sein, in denen explizit nur bestimmte Computer mit bestimmten, kontrollierbaren Freigaben ins VPN geroutet werden sollen. Also für den Fall, wenn nur bestimmte Rechner explizit über VPN erreichbar sein sollen und alle anderen Rechner des Netzes nicht. Dann ist zu beachten, dass die pfSense Box nicht der Default-Gateway des zu routenden 10-er Netzes sein darf und der Default-Gateway die Route zum VPN-Tunnel nicht kennen darf (die pfSense Box und der Default-Gateway sind also zwei unterschiedliche Systeme).
< /Nachträglich geändert # 1: >
Und so bleibt mir nur, mir selbst mal wieder zu sagen: Herzlichen Glückwunsch, Stronzolios. Bei aller Bescheidenheit: Das hast Du mal wieder fantastisch gemacht.
Elefantherios habe ich natürlich nach althergebrachter griechischer Tradition eingeladen zum Trinken und zum gemeinsamen Singen historischer griechischer Weisen:
"Griechisches Bier,
das schmeckt wie der Schweiss der Pferde. Komm, bring noch vier!"
(ok, der ist nicht von mir, aber trotzdem gut).
Ach ja, noch was: Der Rechner von Elefantherios, die "Zweigstelle", war hier mittels OpenVPN GUI direkt mit dem Tunneleingang verbunden. Das heisst, Elefantherios' Rechner "wusste" automatisch, wohin er die Pakete an "seinen" lokalen 172.19.48.2 - Tunneleingang schicken muss. Käme die Verbindung seitens der Zweigstelle stattdessen über einen Router zustande, müssten die entsprechenden Routen natürlich an allen betroffenen Rechnern der Zweigstelle entsprechend eingetragen werden, da diese ja dann ebenfalls nicht wüssten, wohin die Pakete in den 172er Tunneleingang zu routen wären.
< Nachträglich geändert # 2: >
Hat sich aufgrund u.g. Kommentare erledigt. Vielen Dank für die Tipps!
< /Nachträglich geändert # 2: >
Der Vollständigkeit halber hier noch die
Konfiguration (pfSense Version 2.15):
Menü VPN > OpenVPN; Reiter "Server"
Configuration "Road Warrior" - edit:
General Information
| Server Mode | Remote Access (SSL/TLS + User Auth) | |
| Backend for Authentication | Local Database | |
| Protocol | UDP | |
| Device Mode | tap | |
| Interface | WAN | |
| Local Port | 1194 | # (Paranoide geben hier für ein Plus an "security by obscurity" eine beliebige, höhere, "ungewöhnliche" Portnummer ein) |
| Description | Road Warrior | #(optional) |
Anmerkung: OpenVPN GUI richtet per Default einen Tap-Adapter ein, keinen Tun-Adapter. Deswegen muss hier der "Device Mode" auf "tap" gesetzt werden. Für andere Szenarien bitte entsprechend anpassen.
Cryptographic Settings
| TLS Authentication | Haken setzen (make a hake) | |
| Peer Certificate Authority | Road Warrior CA | # oder den entsprechenden, selbst vergebenen Namen auswählen) |
| Peer Certificate Authority | Road Warrior Server Cert | # Name des selbst erstellten Server-Zertifikates |
| Peer Certificate Revocation List | RoadWarrior-CA-CRL | # oder entsprechender eigener Name; für die CRL ein Zertifikat ausstellen und gleuich wiederrufen, damit OpenVPN-GUI nicht über eine leere CRL stolpert. |
| Server Certificate | vpnuser | # oder entsprechender, selbst vergebener Zertifikatsname |
| DH Parameters Length | 2048 | |
| Encryption algorithm | BF-CBC (128-bit) | # Nach Gusto. |
| Hardware Crypto | No Hardware Crypto Accelleration | # oder doch, wenn Hardware-Kryptografie auf der Plattform unterstützt wird. |
| Certificate Depth | One (Client + Server) | # Nach Gusto. |
Tipp: Wenn man sich nach klassischer griechischer Tradition eins drauf pfeift, dass die CA auf der selben pfSense-Box läuft wie der OpenVPN-Zugang, kann man die Zertifikate genau so einrichten wie in untem verlinkten Video beschrieben.So funktioniert's hier bestens für unsere Import-/ Export- Butze. Um unsere Datensicherheit brauche ich mir hier ohnehin keine allzu großen Gedanken machen: Wer auch immer an unsere Daten kommt und damit arbeitet, wird ebenso erfolglos bleiben wie wir.
Tunnel Settings
| IPv4 Tunnel Network | 172.19.48.0/24 | |
| IPv4 Local Network/s | 10.100.100.0/24 | |
| Concurrent connections | 10 | # Nach Belieben, was die CPU halt so hergibt |
| Compression | Haken setzen (make a hake) |
Client Settings
| Dynamic IP | Haken setzen (make a hake) | |
| Address Pool | Haken setzen (make a hake) | |
| DNS Default Domain | Haken setzen (make a hake); griechenkuss.gr (oder wie auch immer die Domain heisst) | |
| DNS Servers | Haken setzen (make a hake); (öffentliche) IPv4-Adresse der verwendeten DNS angeben |
Advanced:
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
client-to-client
Alle anderen Felder bleiben frei.
< Nachträglich geändert # 3: >
route und push route - Anweisungen werden nicht benötigt. Danke für den Hinweis an @aqui, siehe seinen u.g. Kommentar und Links.
Getestet. Funktioniert.
< /Nachträglich geändert # 3: >
Menü VPN > OpenVPN; Reiter "Client Specific Overrides"
Haben wir für erste Tests erst einmal "disabled". Man kann hier im Menü-Punkt "Advanced" für verschiedene Klienten-Remotenetzbereiche sog. iroutes definieren nach dem Muster
iroute 192.168.158.0 255.255.255.0
Diese Anweisung bewirkt, dass Pakete aus dem Klienten-Remotenetz nicht über den VPN-Tunnel ins Hauptnetz geschoben werden (dort haben sie ohnehin nichts verloren), sondern immer im Remotenetz verbleiben.
So könnte eine Konfiguration vollständig aussehen, wenn "enabled":
| Common name | vpnuser | |
| Description | vpnuser auf Port 1194 | # optionale Beschreibung nach Gusto |
| Tunnel Network | 172.19.48.0/24 | |
| Advanced | iroute 192.168.158.0 255.255.255.0 |
Weitere Optionen für den, der's braucht.
Menü Interfaces > assign"
Neues Interface zufügen; das Interface heisst zunächst OPT1, wir benennen es später um in OpenVPN1194
| Enable | Haken setzen (make a hake) |
| Description | OpenVPN1194 |
| IPv4 Configuration | Type None |
| IPv6 Configuration | Type None |
Den Rest nicht ausfüllen bzw. keinen Haken setzen.
Die Reiter "Port Forward","1:1" und "NPt" enthalten in dieser Konfiguration jeweils keine Einträge.
Menü Firewall > NAT; Reiter "Outbound"
Radiobutton "Manual Outbound NAT rule generation (AON - Advanced Outbound NAT)" anklicken und Regeln automagisch generieren lassen
Zusätzliche NAT-Regel für den privaten IP-Adressraum der Zweigstelle(n) hinzufügen; für jede Zweigstelle mit eigenem Adressraum eine eigene Regel erstellen:
| Interface | WAN | |
| Protocol | any | |
| Source | Network, 192.168.158.0 / 24 | |
| Destination | any, Rest nicht ausfüllen | |
| Description | IP-Netzwerk Zweigstelle, NAT rule added manually S.K. 2014-11-11 |
Das Gleiche auch für das OpenVPN1194 Interface:
| Interface | OPENVPN1194 | |
| Protocol | any | |
| Source | Network | # hier habe ich keinen IP-Adressraum vergeben |
| Destination | any, Rest nicht ausfüllen | |
| Description | IP-Netzwerk OpenVPN1194, NAT rule added manually S.K. 2014-11-11 |
Den Rest jeweils nicht ausfüllen bzw. keinen Haken setzen.
Menü Firewall > Rules; Reiter "Outbound"
Wir lassen alle "Default"-Regeln stehen, wie sie sind.
Aber ansonsten reissen wir willenlos alle Scheunentore auf und erlauben ganz großzügig alles:
Firewall - Die WAN-Konfiguration im Edit-Modus:
So sehen die Firewall-Regeln der WAN-Seite in der Übersicht aus (die grauen Felder sind "default"):
Und so sehen die Firewall-Regeln der LAN-Seite in der Übersicht aus:
Der Reiter "Floating" enthält in dieser Konfiguration keinen Eintrag.
Menü Services > DNS Forwarder
General DNS Forwarder Options:
Enable - kein Haken bei "Enable DNS forwarder"; DNS Forwarding ist nicht aktiviert.
Die Option kann in Szenarien sinnvoll sein, in denen der DNS-Forwarder der pfSense Box Namensanfragen für eine lokale Windows-Domäne an den DNS des Windows-Servers weiterleiten soll, und die pfSense-Box die Rechner im Remote-Netz nicht selbständig als DNS über DHCP versorgen soll. Wir sind mit viel weniger zufrieden und lassen das weg, solange keiner danach fragt.
Unsere Erfahrung: Dateifreigaben und Remote-Desktop klappen auch ohne DNS-Forwarding, Domänen- und Active Directory Credentials werden vorher abgefragt. Unsere Empfehlung: Erst mal prüfen ob man's tatsächlich braucht und erst bei konkretem Bedarf konfigurieren.
Nützliche Links, aus denen ich eine Menge Anregungen erhalten hatte:
Hier ein "modernes" Video für die erste Einrichtung von pfSense, interessant vor allem im Hinblick auf Erstellung und Einrichtung von Zertifikaten. So kriegt man erst einmal eine Grundkonfiguration, aber 100% fertig ist man noch nicht. Man kann aber so erst einmal bedenkenlos starten:
Einige Anregungen aus dieser reich bebilderten Konfigurationsanleitung waren sehr hilfreich:
http://swimminginthought.com/pfsense-routing-traffic-strongvpn-openvpn/
Das hatten wir zwischenzeitlich probiert, kamen aber zu dem Schluss, dass DNS-Port Forwarding keine Lösung für unser Problem ist:
https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_o ...
http://meandmymac.net/2013/12/pfsense-openvpn-site-site-dns-resolving/
Ebenfalls als nicht zielführend und eher zeitfressend erwiesen sich Hinweise, den "promicus mode" der NIC unserer pfSense-Box anzuschalten.
Oben erwähnter zentraler Artikel, der letztendlich half, das Routing-Problem in den Griff zu kriegen:
https://community.openvpn.net/openvpn/wiki/RoutedLans
So fügt man eine Route zu einem Windows - Rechner (Server) zu:
http://msdn.microsoft.com/de-de/library/cc757323%28v=ws.10%29.aspx
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 254195
Url: https://administrator.de/contentid/254195
Printed on: April 25, 2024 at 07:04 o'clock
7 Comments
Latest comment
Hallo Stronzolios,
aber irgendwie ist das viel Text, um nur zu sagen, daß man das Routing korrekt einstellen soll. Übrigens stellt man keine statsichen Routen auf dem Endgerät (client, Server) ein, sondern auf den Routern, insbeosndere dem default-router sollte man sgane, wie alle Company-netze zu erreichen sind. Dann lösne sich solche Probleme in Wohlgefallen auf.
lks
aber irgendwie ist das viel Text, um nur zu sagen, daß man das Routing korrekt einstellen soll. Übrigens stellt man keine statsichen Routen auf dem Endgerät (client, Server) ein, sondern auf den Routern, insbeosndere dem default-router sollte man sgane, wie alle Company-netze zu erreichen sind. Dann lösne sich solche Probleme in Wohlgefallen auf.
lks
Moin,
jetzt weiß ich warum's in Olympia nich vorwärts geht ... mit Ouzo lässt's sich halt schlecht routen
dafür aber besser Romane schreiben.
Wie lks schon sagt sind die Routen auf einem Router besser aufgehoben. Die hättest du dir aber auch sparen können wenn du den Traffic der VPN Clients als Alternative geNATet hättest.
Gruß jodel32
jetzt weiß ich warum's in Olympia nich vorwärts geht ... mit Ouzo lässt's sich halt schlecht routen
dafür aber besser Romane schreiben.Wie lks schon sagt sind die Routen auf einem Router besser aufgehoben. Die hättest du dir aber auch sparen können wenn du den Traffic der VPN Clients als Alternative geNATet hättest.
Gruß jodel32
Hallo Stronzolios,
ich muss mich meinen Vorrednern anschließen.
Wenn ich Deinen Roman vor meinem ersten Tunnel vorliegen gehabt hätte, wäre mir ein lesen bestimmt leichter gefallen.
Aber mit "griechischer Gewitztheit und Schläue" haben wir ja wenig zu tun, wir erleben nur jeden Tag die Auswirkungen.
Nischt für ungut, da kannst Du ja persönlich nichts dafür.
Du hast Dir auf jeden Fall viel Schreibarbeit auferlegt, vielleicht hilft es ja jemand.
Gruß orcape
ich muss mich meinen Vorrednern anschließen.
Wenn ich Deinen Roman vor meinem ersten Tunnel vorliegen gehabt hätte, wäre mir ein lesen bestimmt leichter gefallen.
Aber mit "griechischer Gewitztheit und Schläue" haben wir ja wenig zu tun, wir erleben nur jeden Tag die Auswirkungen.
Nischt für ungut, da kannst Du ja persönlich nichts dafür.
Du hast Dir auf jeden Fall viel Schreibarbeit auferlegt, vielleicht hilft es ja jemand.
Gruß orcape
@Lochkartenstanzer , @114757 ,
Funktioniert prima. Wer hätte das gedacht? Das gefällt mir ja fast noch besser als meine eigene Lösung, und das will schon was heissen! Danke für den guten Tipp! Damit kriege ich tatsächlich Zugriff auf die Endcomputer, ohne dass ich in jedem Gerät die Route eintragen muss. So soll es sein.
Hier nochmal die beiden Regeln für den Router (eingetragen auf dem Gateway 10.100.100.1) kurz zusammengefasst:
Das Routing klappt prima, nur wo die Pakete landen, weiss keiner so recht
Γεια σου!
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
Übrigens stellt man keine statsichen Routen auf dem Endgerät (client, Server) ein, sondern auf den Routern,
Funktioniert prima. Wer hätte das gedacht? Das gefällt mir ja fast noch besser als meine eigene Lösung, und das will schon was heissen! Danke für den guten Tipp! Damit kriege ich tatsächlich Zugriff auf die Endcomputer, ohne dass ich in jedem Gerät die Route eintragen muss. So soll es sein.
Hier nochmal die beiden Regeln für den Router (eingetragen auf dem Gateway 10.100.100.1) kurz zusammengefasst:
| Rule_192 | Rule_172 | |
|---|---|---|
| Destination IP Address | 192.168.158.0 | 172.19.48.0 |
| IP Subnet Mask | 255.255.255.0 | 255.255.255.0 |
| Gateway IP Address | 10.100.100.15 | 10.100.100.15 |
| Metric | 2 | 2 |
| Active | Yes | Yes |
| Private | No | No |
... mit Ouzo lässt's sich halt schlecht routen
Das Routing klappt prima, nur wo die Pakete landen, weiss keiner so recht
Γεια σου!
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
< /Nachträglicher Edit # 1: >
Und so bleibt mir nur, mir selbst mal wieder zu sagen: Herzlichen Glückwunsch, Stronzolios. Bei aller Bescheidenheit: Das hast Du mal wieder fantastisch gemacht.
Ja, wenn Dich hier sonst keiner lobt, dann musst Du das wohl selbst machen.Und so bleibt mir nur, mir selbst mal wieder zu sagen: Herzlichen Glückwunsch, Stronzolios. Bei aller Bescheidenheit: Das hast Du mal wieder fantastisch gemacht.
Sorry, das gehört wohl so nicht in ein Forum, das tut einfach nur Weh....
Aber wenn Du´s brauchst....
Abgesehen davon enthält dieser Tipp auch gravierende Fehler, die das ganze Elend des Problems begründen. Da wäre einfach nur simple (internationale) Gründlichkeit beim Lesen und vor allen Dingen Verstehen der OVPN Konfig und der Routing Thematik hilfreicher gewesen als "griechische Schläue" die eher an Probieren im freien Fall erinnert...?! Perikles, Aristoteles oder sogar Dionysos in seiner Tonne würden es vermutlich ähnlich so sehen...! Stronzolios erinnert eher an das italienische "Stronzo" auf das wir hier aber besser nicht näher eingehen. Von den Assoziationen die einem beim Nachnahmen kommen mal ganz zu schweigen 
Eher lässt das einen Administrator an der Ernsthaftigkeit des Verfassers und dieses Threads erheblich zweifeln !
Nur mal allein die Routing Einträge:
route 10.100.100.0 255.255.255.0 10.100.100.15;
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
zeigen schon die Sinnfreiheit dieses Tips. (Sie sind doppelt und damit kontraproduktiv für die die es nicht sehen !) Von den falschen, zusätzlichen statischen Routen mit "route add..." mal ganz zu schweigen. Das ist überflüssig und zeugt das die Winblows Firewall Konfig nicht stimmt oder der OVPN Client ohne Admin Rechte gestartet wurde.
All das ist überflüssig, denn OVPN kann das alles automatisch erledigen Auch ohne diesen komplizierten und überflüssigen Umweg von oben, ja wenn man es dann richtig macht und auch richtig umsetzt.
Es ist sicher gut gemeint, aber man kann OVPN Anfänger nur dringend warnen diese obigen Tips zu beachten denn sie kaschieren mit Frickelei nichts anderes als eine falsche, fehlerhafte und nicht durchdachte OVPN Konfig !
Grundlagen mit weiteren Hinweisen findet man besser in der offiziellen Forumstutorial mit seinen weiterführenden Links.
Beachtet man all das ist die obige Frickelei überflüssige Makulatur ! Und ob sie aus GR oder D oder sonstwo aus der EU oder der Welt kommt ist dabei wie so oft vollkommen unerheblich und tut nichts zur Sache !
Eher lässt das einen Administrator an der Ernsthaftigkeit des Verfassers und dieses Threads erheblich zweifeln !
Nur mal allein die Routing Einträge:
route 10.100.100.0 255.255.255.0 10.100.100.15;
route 192.168.158.0 255.255.255.0 192.168.158.1;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
push "route 192.168.158.0 255.255.255.0 192.168.158.1";
zeigen schon die Sinnfreiheit dieses Tips. (Sie sind doppelt und damit kontraproduktiv für die die es nicht sehen !) Von den falschen, zusätzlichen statischen Routen mit "route add..." mal ganz zu schweigen. Das ist überflüssig und zeugt das die Winblows Firewall Konfig nicht stimmt oder der OVPN Client ohne Admin Rechte gestartet wurde.
All das ist überflüssig, denn OVPN kann das alles automatisch erledigen Auch ohne diesen komplizierten und überflüssigen Umweg von oben, ja wenn man es dann richtig macht und auch richtig umsetzt.
Es ist sicher gut gemeint, aber man kann OVPN Anfänger nur dringend warnen diese obigen Tips zu beachten denn sie kaschieren mit Frickelei nichts anderes als eine falsche, fehlerhafte und nicht durchdachte OVPN Konfig !
Grundlagen mit weiteren Hinweisen findet man besser in der offiziellen Forumstutorial mit seinen weiterführenden Links.
Beachtet man all das ist die obige Frickelei überflüssige Makulatur ! Und ob sie aus GR oder D oder sonstwo aus der EU oder der Welt kommt ist dabei wie so oft vollkommen unerheblich und tut nichts zur Sache !
Καλησπέρα! aqui,
vielen Dank für die Hinweise.
Stimmt. Klassischer πλεονασμóς. Ist im Textkörper entsprechend korrigiert, damit niemand drüber stolpert.
> Grundlagen mit weiteren Hinweisen findet man besser in der offiziellen OVPN_Doku und in diesem Forumstutorial mit seinen weiterführenden Links.
Schöner Artikel. Gefällt mir gut. Vielen Dank für die Mühe, die Du Dir mit dem Verfassen gemacht hast.
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
vielen Dank für die Hinweise.
... die Routing Einträge ... sind doppelt
route 10.100.100.0 255.255.255.0 10.100.100.15;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
route 10.100.100.0 255.255.255.0 10.100.100.15;
push "route 10.100.100.0 255.255.255.0 10.100.100.15";
Stimmt. Klassischer πλεονασμóς. Ist im Textkörper entsprechend korrigiert, damit niemand drüber stolpert.
> Grundlagen mit weiteren Hinweisen findet man besser in der offiziellen OVPN_Doku und in diesem Forumstutorial mit seinen weiterführenden Links.
Schöner Artikel. Gefällt mir gut. Vielen Dank für die Mühe, die Du Dir mit dem Verfassen gemacht hast.
Bis zum nächsten Mal und viel Erfolg!
Euer symphatischer, griechischer Sysadmin Stronzolios
Es muss ja auch mal EU-Hilfe aus Griechenland geben.
