FritzBox OpenVPN Client ignoriert "redirect-gateway"

Ich habe dias bei mir mit zwei Clientconfigs gelöst. In der einen steht "redirect-gateway" drin in der anderen nicht. Damit kann ich mir quasi meine Verbindungsgeschwindigkeit aussuchen ;-)
Wenn Du das aber permanent vom Sever (FBF) vergeben willst, muß Du diese Option pushen. Das ist Dir aber wahrscheinlich sowieso klar. Der Client muß diese Option dann auch pullen ("pull").
Wenn ich Deine Fehlermeldung richtig erkenne, scheinst Du das aber ja schon zu machen, oder?

Hat deine Box den ein Default Gateway? Wenn ich mich recht entsinne, funktionierte der Befehl fast wie ein Skript:
-Suche das Default-Gateway (über das momentan der Openvpn-Server erreicht wird)
- Trage eine Hostroute für den Openvpn-Server über das "alte" Default-Gateway ein
- Lösche Defaultroute
- Trage eine neu Defaultroute über die Openvpn-Verbindung ein

Wenn er das irgendwie nicht hinkriegt (weil er das Defaultgateway nicht erkennt oder so) könnte das zu der Fehlermeldung führen...

Jörg

[Edit frank_m24: Vollzitat vom Beitrag direkt darüber gelöscht, siehe Forumregeln.]
Hallo Jörg,
habe verschiedene Threats in diesem Forum gelesen, wo Du kompetente und freundliche Antworten erteilt hast. Ich stehe jetzt vor dem gleichen Problem, wie in diesem Threat schon beschrieben und habe auch Deine Antwort gelesen. Allerdings kann ich das nicht umsetzen.

Die Server / Client Open VPN Verbindungen stehen wunderbar und ich kann auch auf die jeweiligen Subnetze, die hinter den beiden Subnetzen liegen, zugreifen. Allerdings nicht allen Traffic der Client Box über den Tunnel schicken. Das war eigentlich mein Hauptgrund der Aufgabe.

Im Log der Client Box taucht der Fehler auf:

unable to redirect default gateway -- Cannot read current default gateway from system

Wäre es möglich, dass Du mir aufzeigst, wie ich hier einen workaround finde. Bin leider nicht fit in Linux und Routing etc. und komme hier selbst nicht weiter.

Vielen Dank für Deine mögliche Unterstützung, Gruss aus WI, Wiesah

Das Problem dürfte vermutlich ein bekannter "Fehler" von AVM sein. Eine mögliche Änderung/Korrektur findest du im Ticket 783. Die sollte bei dir möglich sein, sofern du kein AVM-VPN benötigst...

Ansonsten musst du genau dass, was oben steht, "per Hand" Ausführen:
Das könntest du über ein up-Skript machen, beim herunterfahren des VPN muss das dann auch per Hand wieder "zurückgebaut" werden in einem down skript.

Wenn es aber bei dir möglich wäre, das DG "korrekt" zu setzen, wäre das der deutlich einfachere/bessere Weg.


Jörg

Hallo Jörg,

vielen Dank für Deine Hinweise. Folgende Fragen und Ergebnisse tauchen auf für Deine angegebene Lösung:

1. ich habe ein tunnelup.sh file geschrieben mit deinen Anweisungen.
2. Starte ich dieses file bevor ich den openvpn client aufrufe, oder danach?
3. bekomme Fehlermeldung invalid option -- W

# /var/usb/tunnelup.sh
ping: invalid option -- W
BusyBox v1.8.2 (2010-06-22 13:16:24 CEST) multi-call binary

Usage: ping [OPTION]... host

Send ICMP ECHO_REQUEST packets to network hosts

Options:
-4, -6 Force IPv4 or IPv6 hostname resolution
-c CNT Send only CNT pings
-s SIZE Send SIZE data bytes in packets (default=56)
-I iface/IP Use interface or IP address as source
-q Quiet, only displays output at start
and when finished
route: resolving dev
route: resolving net
route: resolving net

Anmerkung: müßte das nicht auch in der route add net Zeile heißen:
128.0.0.0/1 dev tun0 statt wie bei Dir angegeben: 128.00.0./1 ?

route hat folgendes Ergebnis:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
188.96.23.7 * 255.255.255.255 UH 3 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
92.76.28.221 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl

keine Änderung im DG!

Traceroute hat auch kein Ergebnis = zuerst 10.8.0.1 (meine Serverbox)
sondern geht zu einer öffentlichen IP

# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
1 dslb-092-076-000-001.pools.arcor-ip.net (92.76.0.1) 13.425 ms 12.877 ms 1
3.288 ms
2 88.79.30.189 (88.79.30.189) 25.927 ms 16.877 ms 20.558 ms
3 92.79.212.113 (92.79.212.113) 19.185 ms 16.939 ms 13.482 ms
4 92.79.213.122 (92.79.213.122) 22.324 ms 22.379 ms 25.535 ms
5 te3-1.c101.f.de.plusline.net (80.81.192.132) 21.415 ms 21.199 ms 24.284 m
s
6 heise1.f.de.plusline.net (82.98.98.98) 20.835 ms 21.640 ms 21.297 ms
7 heise1.f.de.plusline.net (82.98.98.98) 23.778 ms !A * 21.632 ms !A

Zu der Lösung im Ticket 783 folgende Fragen:

1. ich habe Freetz nicht installiert, sondern starte openvpn von einer sh Datei.
a. Kann ich diesen Patch (default_route_fix_v1.patch) auch mit der normalen Firmware (7270 74.04.86) von AVM ohne Freetz durchführen?
2. habe die Patch Datei runtergeladen.
a. wie führe ich die Patch Datei aus?
b. Durch einfaches Aufrufen?
c. In welches Verzeichnis muss ich die kopieren?
d. Werden die benötigten Pfade automatisch angelegt?

Nach meinem Verständnis würde durch diesen Patch das Default Gateway vor Openvpn richtig angezeigt werden, so dass dann durch den redirect Gateway Befehl von openvpn der Tunnel als GW gesetzt werden müßte.

Vielen Dank für deine Hilfe und bitte um Nachsicht für meine Unkenntnisse in Linux, so dass ich selbst zu den elementaren Fragen des Patchens Frage stelle!

Gruss, wiesah

Hatte nicht bedacht, dass du kein freetz nutzt, da kann die Busybox die Befehle so scheinbar nicht (und/oder es war mein Fehler, denn die Zeilen waren nicht korrekt).

Probiere diese Befehle doch mal "einzeln" einzugeben bei dir. Geht das?

Jörg

Edit: Zum Patch: Dieser legt eine Datei für "onlinechanged" an. Lade mal die Datei hier herunter (unten gibt es "download Original Format" oder so). Wenn du die als "/var/tmp/onlinechanged" abspeicherst (ggf noch ausführbar machen), wird dann nach einer "neuen IP" das DG korrekt gesetzt? Dann könntest du das per debug.cfg auch noch einbinden, und dann kämest du ohne UP-Skript usw. aus...

Hallo Jörg,

vor den Routen Änderungen hatte ich folgenden Routing Table:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
188.108.204.223 * 255.255.255.255 UH 3 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
88.71.18.124 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl

Hier die Ergebnisse der Routing tables nach den Eingaben:

# route add mein.dyndns.name dev dsl
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.14.243.69 * 255.255.255.255 UH 0 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
188.108.204.223 * 255.255.255.255 UH 3 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
88.71.18.124 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl
# route add -net 0.0.0.0/1 dev tun0
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.14.243.69 * 255.255.255.255 UH 0 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
188.108.204.223 * 255.255.255.255 UH 3 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
88.71.18.124 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 128.0.0.0 U 0 0 0 tun0
default * 0.0.0.0 U 2 0 0 dsl
#

Danach

# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 *

= kein Ergebnis.

Soviel zu den Eingaben per Hand "einzeln"

Danach noch folgende Route dazugefügt und Routing Table ausgeführt:

# route add default gw 10.8.0.1
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.14.243.69 * 255.255.255.255 UH 0 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
188.108.204.223 * 255.255.255.255 UH 3 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
88.71.18.124 * 255.255.255.255 UH 2 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 128.0.0.0 U 0 0 0 tun0
default localhost 0.0.0.0 UG 0 0 0 tun0
default * 0.0.0.0 U 2 0 0 dsl

Jetzt nachgeprüft:

# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
1 localhost (10.8.0.1) 63.417 ms 52.746 ms 49.826 ms
2 rdsl-manz-de01.nw.mediaways.net (213.20.56.1) 80.151 ms 108.063 ms 74.933
ms
3 xmws-manz-de01-chan-18.nw.mediaways.net (195.71.47.242) 74.120 ms 73.493 m
s 99.641 ms
4 rmws-manz-de02-xe-0-0-0-0.nw.mediaways.net (213.20.253.82) 74.055 ms 72.52
2 ms 79.362 ms
5 xmws-frnk-de16-chan-0.nw.mediaways.net (62.52.50.162) 100.262 ms 77.408 ms
74.545 ms
6 * te3-1.c101.f.de.plusline.net (80.81.192.132) 85.915 ms 79.568 ms
7 heise1.f.de.plusline.net (82.98.98.98) 79.708 ms 80.520 ms 84.896 ms
8 heise1.f.de.plusline.net (82.98.98.98) 88.982 ms !A * 191.376 ms !A

So geht es! Allerdings keine so elegante Lösung. Herzlichen Dank für Deine Hilfe!

Zum Patch

Ich habe die Datei runtergeladen, aber noch nicht ausprobiert, da ich mit dem jetzigen Ergebnis von heute schon zufrieden bin.

Die Variente werde ich auch noch ausprobieren und meine Fragen / Ergebnisse Dir hier auch noch einmal posten. Nochmals danke für Deine Unterstützung und schnelle Anworten auf meine Posts.

Gruss, Wiesah

Das oben war erstmal nur zum Testen gedacht, ob die Befehle so funktionieren; es fehlte noch "route add -net 128.0.0.0/1 dev tun0", insgesamt funktionieren sollte also:

im "up-skript" und analog im "down-Skript"
Steht auf der OpenVPN-Seite, wie diese Skripte aufgerufen werden, denke an "script-security 2" dabei...

Ich bin gespannt auf die "onlinechanged" Versuche.

Jörg

Hi Jörg,

ich habe den Code Text mit der letzen Zeile ersetzt und

route add default gw 10.8.0.1 mit

route add -net 128.0.0.0/1 dev tun0 ersetzt mit folgenden Ergebnissen:

# /var/usb/startupclient01.sh
Starting telnetd
Waiting for internet connection
PING www.google.de (74.125.77.147): 56 data bytes
64 bytes from 74.125.77.147: seq=0 ttl=57 time=28.420 ms

--- www.google.de ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 28.420/28.420/28.420 ms
Creating TUN device
mknod: /var/tmp/tun: File exists
Starting OpenVPN
route: SIOCADDRT: File exists
route: SIOCADDRT: No such device
route: SIOCADDRT: No such device

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.14.253.4 * 255.255.255.255 UH 0 0 0 dsl
82.82.150.92 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
92.76.51.175 * 255.255.255.255 UH 3 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default * 0.0.0.0 U 2 0 0 dsl
# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
1 dslc-082-082-144-001.pools.arcor-ip.net (82.82.144.1) 15.974 ms 27.799 ms
13.557 ms
2 88.79.30.193 (88.79.30.193) 15.694 ms 17.325 ms 18.588 ms
3 92.79.212.117 (92.79.212.117) 31.237 ms 30.377 ms 14.703 ms
4 92.79.213.130 (92.79.213.130) 21.839 ms 27.281 ms 48.372 ms
5 te3-1.c101.f.de.plusline.net (80.81.192.132) 22.464 ms 46.438 ms 38.162 m
s
6 heise2.f.de.plusline.net (82.98.98.106) 23.223 ms 44.596 ms 23.289 ms
7 heise2.f.de.plusline.net (82.98.98.106) 46.954 ms !A * 23.638 ms !A
#

redirect gateway funktioniert somit mit der Zeile

route add -net 128.0.0.0/1 dev tun0 nicht !!!

wieder zurück gesetzt mit

route add default gw 10.8.0.1 und die Ergebnisse:

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
89.14.253.4 localhost 255.255.255.255 UGH 0 0 0 dsl
89.14.253.4 * 255.255.255.255 UH 0 0 0 dsl
82.82.150.92 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.1 * 255.255.255.255 UH 2 0 0 dsl
192.168.180.2 * 255.255.255.255 UH 2 0 0 dsl
10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0
92.76.51.175 * 255.255.255.255 UH 3 0 0 dsl
192.168.178.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.179.0 * 255.255.255.0 U 0 0 0 guest
10.8.0.0 localhost 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 lan
169.254.0.0 * 255.255.0.0 U 0 0 0 lan
default localhost 128.0.0.0 UG 0 0 0 tun0
128.0.0.0 localhost 128.0.0.0 UG 0 0 0 tun0
default localhost 0.0.0.0 UG 0 0 0 dsl
default * 0.0.0.0 U 2 0 0 dsl
# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
1 localhost (10.8.0.1) 67.023 ms 70.585 ms 52.816 ms
2 rdsl-manz-de01.nw.mediaways.net (213.20.56.1) 80.863 ms 94.906 ms 74.587
ms
3 xmws-manz-de02-chan-18.nw.mediaways.net (195.71.47.246) 89.548 ms 92.035 m
s 97.260 ms
4 rmws-manz-de02-xe-1-0-0-0.nw.mediaways.net (213.20.253.98) 91.243 ms 95.73
6 ms 99.754 ms
5 xmws-frnk-de16-chan-0.nw.mediaways.net (62.52.50.162) 72.091 ms 90.483 ms
105.054 ms
6 te3-1.c101.f.de.plusline.net (80.81.192.132) 148.840 ms 130.225 ms 160.55
5 ms
7 heise2.f.de.plusline.net (82.98.98.106) 149.757 ms 138.053 ms 97.593 ms
8 heise2.f.de.plusline.net (82.98.98.106) 79.877 ms !A * 211.410 ms !A

So funktioniert es !

onlinechanged schaffe ich heute nicht mehr. Ich versuche es in den nächsten Tagen zu probieren und poste dann die Ergebnisse.

Gruss, Wiesah

Irgendwie habe ich das Gefühl, wir reden oder arbeiten scheinbar immer Haarscharf aneinander vorbei ...


Im Beitrag #4 hat der "erste Teil" vom Ändern des ("route add -net 0.0.0.0/1 dev tun0") problemlos funktioniert, der Befehl wurde angenommen, die Route auch eingetragen:

Jetzt geht der gleiche Befehl nicht mehr??? Das ist ja merkwürdig.

Und vor allem, da die beiden Routen im "letzten" Auszug deiner Routingtabelle sogar doch drin sind?!?:

Nur nochmal zur Sicherheit, ob du das auch "richtig" machst: Das ganze Routing-Ändern darf natürlich erst ausgeführt werden, wenn die VPN-Verbindung sicher steht, deshalb sollte es vom OpenVPN aufgerufen werden als "up"-Skript, wie ich oben geschrieben hatte. Hast du das so gemacht??

Übrigens: Um deine Beiträge lesbarer zu gestalten setze doch bitte die Ausgaben vom normalen Fließtext ab und nutze die Tags [noparse] [/noparse] bzw. im Editor das # drumherum.


Jörg

Hallo Jörg,

Du hattest Recht! Ich hatte zumnächst Deine Bezehlszeilen mit in mein generelles Start Script für Openvpn hinten angehängt. Anscheinend stand der Tunnel noch nicht richtig und somit wurden die Routing Zeilen wohl "verschluckt". Gestern dann diese Routing Zeilen erst einmal aus dem generellen Start Script gelöscht und die 3 Zeilen händisch eingeben, nachdem openvpn gestartet hatte. Eh voilá - Meine Client Box wurde wieder über meine Server Box richtig geroutet, d.h. erste Station = 10.8.0.1 bei Traceroute und auch die nachfolgenden Stationen waren eindeutig durch meinen Server geroutet, da von den Namen nachvollziehbar.

Danach hatte ich versucht ein up script zu integrieren, d.h. die 3 Zeilen in ein seperates Script File zu schreiben. Dieses dann Tunnel.up genannt.

Leider scheiterte ich dann in der openvpn *.conf Datei, da ich zwar den Befehl script-security 2 setzte und auch den Namen des tunnel.up scripts hier hinterlegte.

Ich bekam jedoch eine Fehlermeldung, dass script-security 2 nicht ausgeführt werden konnte.

Da ich openvpn 2.1. rc1 benutze ergab eine Recherche, dass ich für diese Version hätte eingeben müssen: script-security 2 system.

Auch das funktionierte nicht. Jetzt weiß ich hier nicht weiter???

Ein weiteres Problem taucht jetzt auf:

Duch die Zwangstrennung des IP Providers gehen leider die Routen auf der Client Seite verloren, da DSL ja immer kurz unterbochen wird.

Dann scheitert die Verbindung mit folgender Fehlermeldung aus dem log file des Servers:

WWed Dec 1 03:32:09 2010 us=410701 read UDPv4 [EHOSTUNREACH]: No route to host (code=148)

Hast Du dafür einen Tip?

Dann bliebe noch die Variante "onlinechanged".

Dazu folgende Fragen:

Ich habe die Datei im richtigen Format heruntergeladen und nenne die Datei onlinechanged (korrekt?)

Diese kopiere ich jetzt in das Verzeichnis: /var/tmp/ hinein Danach werde ich sie auch mit dem Linux Befehl ausführbar machen.

Wird die Datei onlinechanged jetzt automatisch ausgeführt?

In der Datei wird die Route auf 169.254.2.1 gesetzt, die aber in meinen Routing tables nicht auftaucht. Ist das soz. ein generischer Ersatz für 0.0.0.0, damit dann durch den redirect Befehl von openvpn ein Eintrag <> "0" steht und somit 10.8.0.1 eingetragen werden kann oder wie funktioniert das?

Freue mich auf Deine weiteren Hinweise.

Wiesah

Also, die Skripte müssen zunächst "normale Shell-Skripte" sein, also mit "#!/bin/sh" an Anfang und vermutlich noch ausfrührbar (chmod +x ...).

Bleiben denn die beiden Routen über "tun0" erhalten? Geht überhaupt von der Box aus eine Namensauflösung "direkt"? Vermutlich musst du noch etwas mehr "ticksen":
- Hostrouten für die DNS-Server des Providers beim Client (damit der immer die IP des Servers auflösen kann, und dafür nicht den Tunnel benötigt).
- Periodische Abfrage, ob der Dyndns-Name eine neue IP bekommen hat, verbunden danach mit sowas wie dies (nur so aus dem Kopf, nicht geprüft):

Es gäbe dafür (wenn die DNS-Auflösung immer klappt) auch das Skript "ipchange", was bei einer Änderung der Server-IP aufgerufen wird, in dem man das unterbringen könnte (dem wird die neue IP übergeben, so dass man die Route eintragen kann, die "alte" müsste man sich über eine Umgebungsvariable oder sonstwie merken).



Jörg

Hallo Jörg,

danke wieder für die Hinweise. Die Angelegenheit wird mir insgesamt zu komplex, da doch zu viele Voraussetzungen fehlen und ich auch einige Dinge, die für Dich selbstverständlich sein mögen, nicht nachvollziehen kann.

Ich habe jetzt die Lösung mit manuellem Tunnelup auf Client Seite, die nur nicht mehr funktioniert, wenn durch den ISP die tägliche Zwangstrennung vorgenommen wird. Das reicht eigentlich für meine momentanen Zwecke, auch wenn es etwas "gebastelt" ist.

Gern würde ich auch noch einmal die Variante mit dem Patch ausprobieren, wie in Deinem Post unter #7 kurz erwähnt.

Wäre es möglich, dass Du mir hierfür noch ein einfaches aber doch detailliertes "How-to" aufgeben könntest, da ich schon beim Kopieren der Datei (welcher Name? in welches Verzeichnis?) gescheitert bin.

Es gibt im Ticket 783 auch eine Patch Datei zum "runterladen":

default_route_fix_v1.patch

Auch hier weiß ich nicht, wie die in der FB auf command-Zeile eingegeben werden kann, bzw. in welche Verzeichnisse das kopiert bzw. aufgerufen werden muss.


Für Deine weiteren Hinweise weiterhin herzlichen Dank!

Wiesah