Hallo,
wenn ich im Server das Routing verändere, wird die OpenVPN-Konfiguration
nicht aktualisiert.
D.h. die Push Route Einträge und damit die Routes durch den Tunnel
werden am Client nicht nachgezogen.
Ich habe den Server und den Dienst schon neu gestartet.
netstat -r am Server zeigt den neuen Routing Table.
route print im Windows OpenVPN Client zeigt den alten Routing Table.
Was muß ich tun, um OpenVPN Server-Konfiguration zu aktualisieren?
Gruß
Anselm
OpenVPN (Push)-Routes aktualisieren
Moderator: Securepoint
die Routing-Tabelle der Firewall hat nichts mit der Routing-Tabelle des Clients zu tun. Verstehe ich Sie richtig, dass Sie dem OpenVPN-Client eine neue Route in ein Netz hinter der Securepoint mitgeben wollen?
Dafür erstellen Sie eine neue Regel (Firewall -> Portfilter):
openvpn-net -> zusätzliches-net -> any -> ACCEPT
Danach starten Sie den openVPN-Dienst neu und die Route wird automagisch an den Client übergeben.
Dafür erstellen Sie eine neue Regel (Firewall -> Portfilter):
openvpn-net -> zusätzliches-net -> any -> ACCEPT
Danach starten Sie den openVPN-Dienst neu und die Route wird automagisch an den Client übergeben.
Zuletzt geändert von Erik am Di 24.11.2009, 20:02, insgesamt 1-mal geändert.
Danke für die absolut notwendige Info!
Aber dazu noch ein paar Anmerkungen:
1. Warum steht diese nicht unwesentliche Info (noch) nicht im Handbuch?
Auch schon nicht im 2007nx Handbuch und dem OpenVPN Howto.
2. Dieses Koppeln der Client Push Routing Konfiguration allein an eine Firewallregel
stelle ich aus mehreren Gründen zur Diskussion:
Grund 1:
Ich habe unterschiedliche Typen von Roadwarriern, denen ich unterschiedliche
Zugänge zu eingeschränkten Teilnetzen meiner fast 2 Dutzend Netze hinter
der Firewall gewähren möchte. (Diese Teilnetze gehören teils zu Kundennetzen
miteinander konkurrierender Industrieunternehmen, die ich hübsch getrennt
halten muß) Der Client Push Routing Table umfasst aber immer alle Teilnetze
für die ich irgendeine Firewallregel mit Openvpn-Elementen definiert habe.
D.h.: Jeder OpenVPN Client
weiß immerhin schon, welche Teilnetze (und zwar alle!) sich hinter dem VPN
Server befinden. Das ist ja schon mal eine nicht unwesentliche Information
für potentielle Hacker.
Grund 2:
Ohne im Handbuch gewarnt zu werden, muß man auf einmal extrem vorsichtig
mit seinen Firewall Regeln sein, wenn man sich sein OpenVPN nicht komplett
stilllegen will und man nur schwer hinter den Grund kommt, weil der Effekt
wie eine Zeitbombe erst perfiderweise lange nach der auslösenden "bösen" Tat
eintritt und der betroffene ältere Admin sich schon gar nicht mehr an den
möglichen Auslöser erinnert.
Hier das leider nicht fiktive Scenario:
Ein Mensch, nennen wir in Admin, hat seit ewigen Zeiten (ich glaube seine
erste Version war Securepoint 3) eine Portfilterregel, die ihm als Admin
Zugang zu seinen SP Appliances gewährt, folgendermaßen:
Gruppe Admin Clients --> Admin Zugriff --> internes und(!) externes Interface der SPs
Nachdem die neue Appliance und OpenVPN halbwegs funktioniert, denkt
(schwerer Fehler) der Admin, es könne nicht schaden, die ip-Adresse seines
für eigene Zwecke eingerichteten OpenVPN Roadwarriers, einfach der
Gruppe Admin Clients hinzuzufügen. Regelupdate. Alles funktioniert immer
noch wunderbar. Nach einer Woche denkt(!) dieser Admin, jetzt könnte es
doch nicht schaden, die Appliance vor dem Wochenende zu booten.
Ab diesem Boot werden zwar weiterhin alle OpenVPN Tunnel erfolgreich
aufgebaut, aber kein Bit kommt mehr durch den Tunnel jeden Roadwarriers.
Warum?
Der Boot sorgt dafür, daß automatisch Push Route Regeln aus den Portfilter
Regeln generiert werden. Und zwar für alle Clients.
Und obige Admin Porfilter Regel sorgt nun dafür, daß jeder OpenVPN Client
folgende Route (unter in diesem Fall 2 Dutzend anderen) installiert bekommt:
route add
gateway=
D.h. soweit ich es verstehe:
Jedes Paket, das durch den Tunnel soll, wird verschlüsselt, aber nicht mehr über das
Default Gateway an das externe Interface der Appliance geschickt, sondern durch
den Tunnel an das tun0 Interface der Appliance und damit erneut verschlüsselt
durch den Tunnel an das tun0 Interface und so weiter und sofort bis in alle
Ewigkeit .....
Ende der Geschichte.
Das Problem muß anders gelöst werden! Zumindest muß verhindert werden, daß
Push Routing Regeln aus Portfilter Regeln generiert werden, die das externe
Interface betreffen.
Gruß
Anselm
Aber dazu noch ein paar Anmerkungen:
1. Warum steht diese nicht unwesentliche Info (noch) nicht im Handbuch?
Auch schon nicht im 2007nx Handbuch und dem OpenVPN Howto.
2. Dieses Koppeln der Client Push Routing Konfiguration allein an eine Firewallregel
stelle ich aus mehreren Gründen zur Diskussion:
Grund 1:
Ich habe unterschiedliche Typen von Roadwarriern, denen ich unterschiedliche
Zugänge zu eingeschränkten Teilnetzen meiner fast 2 Dutzend Netze hinter
der Firewall gewähren möchte. (Diese Teilnetze gehören teils zu Kundennetzen
miteinander konkurrierender Industrieunternehmen, die ich hübsch getrennt
halten muß) Der Client Push Routing Table umfasst aber immer alle Teilnetze
für die ich irgendeine Firewallregel mit Openvpn-Elementen definiert habe.
D.h.: Jeder OpenVPN Client
weiß immerhin schon, welche Teilnetze (und zwar alle!) sich hinter dem VPN
Server befinden. Das ist ja schon mal eine nicht unwesentliche Information
für potentielle Hacker.
Grund 2:
Ohne im Handbuch gewarnt zu werden, muß man auf einmal extrem vorsichtig
mit seinen Firewall Regeln sein, wenn man sich sein OpenVPN nicht komplett
stilllegen will und man nur schwer hinter den Grund kommt, weil der Effekt
wie eine Zeitbombe erst perfiderweise lange nach der auslösenden "bösen" Tat
eintritt und der betroffene ältere Admin sich schon gar nicht mehr an den
möglichen Auslöser erinnert.
Hier das leider nicht fiktive Scenario:
Ein Mensch, nennen wir in Admin, hat seit ewigen Zeiten (ich glaube seine
erste Version war Securepoint 3) eine Portfilterregel, die ihm als Admin
Zugang zu seinen SP Appliances gewährt, folgendermaßen:
Gruppe Admin Clients --> Admin Zugriff --> internes und(!) externes Interface der SPs
Nachdem die neue Appliance und OpenVPN halbwegs funktioniert, denkt
(schwerer Fehler) der Admin, es könne nicht schaden, die ip-Adresse seines
für eigene Zwecke eingerichteten OpenVPN Roadwarriers, einfach der
Gruppe Admin Clients hinzuzufügen. Regelupdate. Alles funktioniert immer
noch wunderbar. Nach einer Woche denkt(!) dieser Admin, jetzt könnte es
doch nicht schaden, die Appliance vor dem Wochenende zu booten.
Ab diesem Boot werden zwar weiterhin alle OpenVPN Tunnel erfolgreich
aufgebaut, aber kein Bit kommt mehr durch den Tunnel jeden Roadwarriers.
Warum?
Der Boot sorgt dafür, daß automatisch Push Route Regeln aus den Portfilter
Regeln generiert werden. Und zwar für alle Clients.
Und obige Admin Porfilter Regel sorgt nun dafür, daß jeder OpenVPN Client
folgende Route (unter in diesem Fall 2 Dutzend anderen) installiert bekommt:
route add
gateway=
D.h. soweit ich es verstehe:
Jedes Paket, das durch den Tunnel soll, wird verschlüsselt, aber nicht mehr über das
Default Gateway an das externe Interface der Appliance geschickt, sondern durch
den Tunnel an das tun0 Interface der Appliance und damit erneut verschlüsselt
durch den Tunnel an das tun0 Interface und so weiter und sofort bis in alle
Ewigkeit .....
Ende der Geschichte.
Das Problem muß anders gelöst werden! Zumindest muß verhindert werden, daß
Push Routing Regeln aus Portfilter Regeln generiert werden, die das externe
Interface betreffen.
Gruß
Anselm
-
Mixed-Pickl
- Beiträge: 1
- Registriert: Mo 21.12.2009, 19:23
Hallo,
ich habe bei den Push-Rutes das Problem, daß ich eine "Route.exe add ADD 0.0.0.0 Subnet 0.0.0.0 192.168.250.9
und
Route add 192.168.250.1 mask 255.255.255.0 192.168.250.9
wobei das 250er Netz der Tunnel ist und mein Zielnetz 192.168.1.0 ist.
wie kann ich das fixen, gem. unterer Anleitung geht das so nicht.
Danke
ich habe bei den Push-Rutes das Problem, daß ich eine "Route.exe add ADD 0.0.0.0 Subnet 0.0.0.0 192.168.250.9
und
Route add 192.168.250.1 mask 255.255.255.0 192.168.250.9
wobei das 250er Netz der Tunnel ist und mein Zielnetz 192.168.1.0 ist.
wie kann ich das fixen, gem. unterer Anleitung geht das so nicht.
Danke
Hallo,
Sie müssen für die Regel openvpn-netz -> Internet für das Objekt Internet ein
anderes Netzwerkobjekt erstellen. Das sollte aus zwei Netzen bestehen:
1. 0.0.0.0/1
2. 128.0.0.0/1
Am Besten zu einer Gruppe zusammenfassen und dann als Ziel in der Regel
ersetzen.
Sie müssen für die Regel openvpn-netz -> Internet für das Objekt Internet ein
anderes Netzwerkobjekt erstellen. Das sollte aus zwei Netzen bestehen:
1. 0.0.0.0/1
2. 128.0.0.0/1
Am Besten zu einer Gruppe zusammenfassen und dann als Ziel in der Regel
ersetzen.
best regards
oliver hausmann
--
Securepoint GmbH
oliver hausmann
--
Securepoint GmbH