Gesamten Fritz!Box LAN-Traffic über OpenVPN Tunnel ins Internet routen

radislav · 26 Apr 2013

Code:

# tcptraceroute -s 192.168.178.20  -P 5999 www.wissen.de
Selected device eth0, address 192.168.178.20, port 5999 for outgoing packets
Tracing the path to www.wissen.de (84.201.97.76) on TCP port 80 (www), 30 hops max
 1  192.168.178.1  0.762 ms  0.457 ms  0.515 ms
 2  10.119.72.1  36.667 ms  59.534 ms  27.981 ms
 3  rbx-9-m1.fr.eu (91.121.10.253)  27.971 ms  70.479 ms  27.270 ms
 4  * rbx-2-6k.fr.eu (213.251.191.130) 66.907 ms  108.472 ms
 5  rbx-g1-a9.fr.eu (213.186.32.233)  27.982 ms  28.194 ms  61.383 ms
 6  fra-1-6k.de.eu (94.23.122.209)  51.332 ms * *
 7  decix.dts-online.net (80.81.192.149)  91.358 ms  36.287 ms  63.625 ms
 8  edge1-ae0-68.dts-online.net (212.62.68.251)  61.947 ms  97.280 ms  66.764 ms
 9  * * *
10  84.201.97.76 [open]  46.458 ms  110.307 ms  82.782 ms

MaxMuster · 26 Apr 2013

Und jetzt die spannende Frage nach dem VNC Test...

unn4m3d · 27 Apr 2013

radislav schrieb:
@unn4m3d: du brauchst eine 04.xx firmware evtl. mit freetz-1.2

Du hast doch auch eine FB 7270 im Einsatz, muss man da wirklich so weit runter? Das wäre ja schon arg ärgerlich..

Achso kann mir bitte jemand erklären wieso es mit den IPtables nicht läuft auf der 7270?

Desto mehr ich lese desto verwirrter werde ich.

MaxMuster · 27 Apr 2013

Ja, muss man.
Interessiert es dich wirklich technisch, warum es nicht läuft? Dazu findest du einiges hier im Forum und in Freetz-Tickets dazu. Stichwort dazu ist "conntrack", das für NAT benötigt wird (auch hier ist google dein Freund).
Oder glaubst du es nur einfach nicht nicht? Dann kannst du es mit einigen Eingriffen im Freetz durchaus schaffen, ein Image mit conntrack-Modul zu bauen. Allerdings wärest du wohl der erste, wenn die Firmware damit bei dir funktionierte ;-)

unn4m3d · 27 Apr 2013

Mich interessiert es weil ich in den letzten Tagen viel Freizeit dafür geopfert habe mit Lesen in dem Glauben, dass es eine Lösung gibt, die praktisch anwendbar und vor allem machbar ist. Das angeeignete Wissen wäre dann ja für die Tonne und die Zeit hätte ich dann lieber anderweitig verbracht. Das Problem ist halt, dass ich ansonsten nicht so viel Plan von diesen ganzen Routinggeschichten habe und mir da das ein oder andere zusammenreimen muss. Ich schau mir dieses "conntrack" gleich mal an. Ich glaube ich hänge den Glauben das es mit der guten FB problemlos funktioniert jetzt erstmal an den Nagel. Ich denke mal ich benutze dann "tomato", "dd-wrt" oder "open-wrt". Muss ich halt noch ein zusätzlichen Device besorgen.

Vielen Dank für deine Antwort, dein Support, deine Expertise und deine Geduld hier im Forum sind echt der Hammer!

radislav · 29 Apr 2013

MaxMuster schrieb:
Und jetzt die spannende Frage nach dem VNC Test...

leider nein, sonnst würde ich schon Erolg melden

@unn4m3d:

Ich werde mal versuchen, es mit ein Paar Sätzen zu erklären...
Bei FW 05.xx kollidiert das Modul nf_conntrack mit einem AVM-Modul generic_conntrack. Es ist also nicht mehr möglich nf_conntrack zu laden, von dem extrem viel abhängt, z.B. nf_nat für iptables.

Ich habe schon ein paar Versuche gemacht, den AVM-Modul wegzuschmeisen, das funktioniert aber leider nicht gut...

MaxMuster · 29 Apr 2013

@radislav: Machst du bitte mal ein "ip rules show"?
Frage wäre, ob du im Kernel noch diese Dinge aktiviert hast, damit das überhaupt geht:

Code:

Networking --->
	Networking options  --->
		[*]   IP: policy routing 
		[*]     IP: use netfilter MARK value as routing key

radislav · 30 Apr 2013

genau daran liegt es! bei mir ist "IP: use netfilter MARK value as routing key" in der Kernel-config nicht aktiviert.

Code:

# ip rule show
0: from all lookup local
30000: from 192.168.178.0/24 to 192.168.178.0/24 lookup main
30001: from 192.168.178.1 lookup main
30010: from all fwmark 0x1 lookup main
31000: from 192.168.178.0/24 lookup 2
32766: from all lookup main
32767: from all lookup default

ich werde freetz mal neukompilieren und draufspielen...

PsychoMantis · 1 Mai 2013

Es existiert ein Firmen-WLAN. Darüber würde ich gerne ins Internet. Die Firma möchte aber nur äußerst ungern, dass ich mit ihrer öffentlicher IP surfe.
Ich habe seit vielen Jahren einen vserver wo Asterisk drauf läuft und nun dachte ich folgendes: Auf dem vserver richte ich openvpn-Server ein, dann stelle ich eine alte La-Fonera in der Firma hin, die nur den WLAN-Client spielt. An die hänge ich per WLAN dann eine Fritzbox. Und dann richte ich das so ein, dass an die ganzen Clients (sollen nur 1 - 3 Stück sein) die IP-Adresse aus dem 10.x.x.x - Bereich direkt vom VPN-Server vergeben wird.
Bevor ich jetzt anfange unzählige Threads durchzulesen stellt sich zunächst nur eine Frage: ist dies überhaupt so möglich wie ich es beschrieben habe?

MaxMuster · 1 Mai 2013

Kenne die Fonera nicht genau, aber wenn du damit die FB "ins Netz" bekommst, sollte das klappen.
Gut ist, dass du damit den VPN-Server selbst in der Hand hast. So kann der VPN-Server "ordentlich das Netz zur FB routen" und du musst auf der FB nur routen (und nicht das LAN "Natten", um es vor dem VPN-Server zu verstecken).

PsychoMantis · 1 Mai 2013

Das hört sich ja echt vielversprechend an. Die Frage ist dann: wie richte ich das ein? OpenVPN-Server läuft auf dem vserver bereits - allerdings wird da nix geroutet momentan (habe ich bisher nicht gebraucht). Sollte ich den VPN-Client in die LaFonera (das ist so ein WLAN-Router mit OpenWrt drauf, der als WLAN-Client eingesetzt werden kann) rein tun (dann könnte ich wohl die Fritzbox unmodifiziert lassen) oder in die Fritzbox?

MaxMuster · 2 Mai 2013

Hängt natürlich von der sonstigen Config des Servers ab, das ist aber im Prinzip ganz einfach.
Ist die FB/Fonera der einzige Client, geht es sogar mit static key, sonst solltest/müsstest du eine Konfig mit Zertifikaten bauen.

Zu dem FB/Fonera Client muss dann in der Config auf dem Server das Netz, dass hinter der FB ist, zum VPN-Client geroutet werden.
Wenn die Fonera schon OpenVPN "kann", kann die natürlich auch als Client fungieren und das Netz der FB dann zu dieser "weiterleiten".

Ist bei der FB das "Standardnetz" 192.168.178.0, steht beim OpenVPN-Server zusätzlich:

route 192.168.178.0 255.255.255.0

Für eine "static key" Config reicht dass, bei Zertifikaten muss zudem dem Server noch gesagt werden, zu welchem Client das geschickt werden muss.
Dazu brauchst du ein "client-config-dir" mit einem Eintrag für deinen Client, der zumindest einen Eintrag "iroute 192.168.178.0 255.255.255.0" hat.
Dazu gibt es einige Beiträge, auch hier im Forum.

Dann musst du berücksichtigen, dass der vServer das Netz der FB auch ins Internet routet und dabei nattet.

JohnDoe42 · 23 Jul 2013

Hallo zusammen,

eine kurze Frage: Hat jemand Erfahrungen mit der 74.05.22-FW für die 7270v3 bezüglich des redirect-gateway (gesamten Traffic durchs VPN routen) ? Ich durfte schon feststellen, daß das Modul nf_conntrack nicht zu laden ist ...
Falls das nicht funktioniert: Würde es mit einer 7170 mit aktuellem Trunk (auf Basis 28.04.87-FW) funktioneren ?
Beste Grüße,

JD.

MaxMuster · 23 Jul 2013

Die Problematik mit "redirect-gateway" auf den Boxen sollte mit den 2.3-er Versionen von OpenVPN nicht mehr bestehen.
Eine 7170 müsste also sowohl damit als auch mit iptables funktionieren.

JohnDoe42 · 23 Jul 2013

Hallo Jörg,

vielen dank für die Info. Könntest Du noch was zur 7270v3 bzw. deren Kernel und der 05er-FW sagen ? Benötige ich das nf_conntrack für das redirect-gateway zwingend ? Falls ja, kann ich mir den Versuch auf Basis der 05.22-FW sparen - das endet in Reboots.
Beste Grüße,

JD.

MaxMuster · 23 Jul 2013

Kommt drauf an, wie du die Frage meinst.

"redirect-gateway" bedeutet nur, dass das VPN als "Defaultgateway" genutzt werden soll. Mit älteren OpenVPN-Versionen kam es da auf FB zu Problemen, weil die mit der Art, wie AVM das Defaultgateway setzt (auf ein Interface statt eine IP), nicht klar kamen ("unable to redirect default gateway -- Cannot read current default gateway from system"). Das Problem sollte mit den neueren OpenVPN Versionen nicht mehr auftauchen.
Also streng genommen benötigst du für den Befehl "redirect-gateway" kein conntrack. Die FB wird so "alles" zum OpenVPN Server routen, egal ob von der Box oder aus dem LAN der Box.

Für eine Mit-Nutzung des VPN von Geräten "hinter" der FB, ohne dass dazu der Server entsprechend konfiguriert ist (also ohne eine Route für dein LAN auf dem Server), müssen die Geräte hinter der VPN-IP versteckt werden. Diese NAT ist das, wofür du immer conntrack benötigst. Wenn du das brauchst, muss es eine ältere Firmware sein.

JohnDoe42 · 23 Jul 2013

MaxMuster schrieb:
Für eine Mit-Nutzung des VPN von Geräten "hinter" der FB ...

Nein, mir genügt es, wenn die verbundenen VPN-Clients den Server/die Box als Gateway benutzen.
Nochmals besten Dank für die Infos, ich werde das mit einer 7270v3 mal testen und berichten.
Grüße,

JD.

EDIT: Hab' 's probiert: Leider erfolglos.
Zunächst mal die Route ohne redirect-gateway ( also ohne OpenVPN

):

Code:

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0     *.*.*.1   *.*.*.50	  1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
     *.*.*.0    255.255.255.0    *.*.*.50   *.*.*.50	  20
    *.*.*.50  255.255.255.255        127.0.0.1       127.0.0.1	  20
   *.*.255.255  255.255.255.255    *.*.*.50   *.*.*.50	  20
        224.0.0.0        240.0.0.0    *.*.*.50   *.*.*.50	  20
  255.255.255.255  255.255.255.255    *.*.*.50   *.*.*.50	  1
  255.255.255.255  255.255.255.255    *.*.*.50               2	  1
Standardgateway:      *.*.*.1

Route mit:

Code:

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0    192.168.178.1  192.168.178.100	  1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
     *.*.*.0    255.255.255.0    *.*.*.50   *.*.*.50	  20
    *.*.*.50  255.255.255.255        127.0.0.1       127.0.0.1	  20
   *.*.255.255  255.255.255.255    *.*.*.50   *.*.*.50	  20
    192.168.178.0    255.255.255.0  192.168.178.100  192.168.178.100	  30
    192.168.178.0    255.255.255.0    192.168.178.1  192.168.178.100	  1
  192.168.178.100  255.255.255.255        127.0.0.1       127.0.0.1	  30
  192.168.178.255  255.255.255.255  192.168.178.100  192.168.178.100	  30
        224.0.0.0        240.0.0.0    *.*.*.50   *.*.*.50	  20
        224.0.0.0        240.0.0.0  192.168.178.100  192.168.178.100	  30
  255.255.255.255  255.255.255.255    *.*.*.50   *.*.*.50	  1
  255.255.255.255  255.255.255.255  192.168.178.100  192.168.178.100	  1
Standardgateway:     192.168.178.1

Soweit okay, wenn ich dann allerdings im Browser (ohne Proxy) eine Seite öffnen möchte bricht die OpenVPN-Verbindung ab. Der Client-Log hierzu:

Code:

...
Tue Jul 23 15:15:20 2013 Successful ARP Flush on interface [2] {174F1F12-8BEB-4452-868F-EDCD63A68F86}
Tue Jul 23 15:15:25 2013 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=0 u/d=up
Tue Jul 23 15:15:25 2013 C:\WINDOWS\system32\route.exe ADD 127.0.0.1 MASK 255.255.255.255 *.*.*.1
Tue Jul 23 15:15:25 2013 ROUTE: route addition failed using CreateIpForwardEntry: Falscher Parameter.   [status=87 if_index=3]
Tue Jul 23 15:15:25 2013 Route addition via IPAPI failed [adaptive]
Tue Jul 23 15:15:25 2013 Route addition fallback to route.exe
Tue Jul 23 15:15:25 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Jul 23 15:15:25 2013 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 *.*.*.1
Tue Jul 23 15:15:25 2013 Route deletion via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:25 2013 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.178.1
Tue Jul 23 15:15:25 2013 Route addition via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:25 2013 MANAGEMENT: >STATE:1374585325,ADD_ROUTES,,,
Tue Jul 23 15:15:25 2013 C:\WINDOWS\system32\route.exe ADD 192.168.178.0 MASK 255.255.255.0 192.168.178.1
Tue Jul 23 15:15:25 2013 Route addition via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:25 2013 C:\WINDOWS\system32\route.exe ADD 192.168.178.0 MASK 255.255.255.0 192.168.178.1
Tue Jul 23 15:15:25 2013 Route addition via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:25 2013 Initialization Sequence Completed
Tue Jul 23 15:15:25 2013 MANAGEMENT: >STATE:1374585325,CONNECTED,SUCCESS,192.168.178.100,127.0.0.1
Tue Jul 23 15:15:46 2013 Connection reset, restarting [0]
Tue Jul 23 15:15:46 2013 SIGUSR1[soft,connection-reset] received, process restarting
Tue Jul 23 15:15:46 2013 MANAGEMENT: >STATE:1374585346,RECONNECTING,connection-reset,,
Tue Jul 23 15:15:46 2013 Restart pause, 5 second(s)
Tue Jul 23 15:15:51 2013 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Jul 23 15:15:51 2013 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue Jul 23 15:15:51 2013 MANAGEMENT: >STATE:1374585351,RESOLVE,,,
Tue Jul 23 15:15:51 2013 Attempting to establish TCP connection with [AF_INET]127.0.0.1:3128
Tue Jul 23 15:15:51 2013 MANAGEMENT: >STATE:1374585351,TCP_CONNECT,,,
Tue Jul 23 15:15:51 2013 TCP connection established with [AF_INET]127.0.0.1:3128
Tue Jul 23 15:15:51 2013 Send to HTTP proxy: 'CONNECT *:* HTTP/1.0'
Tue Jul 23 15:15:56 2013 C:\WINDOWS\system32\route.exe DELETE 192.168.178.0 MASK 255.255.255.0 192.168.178.1
Tue Jul 23 15:15:56 2013 Route deletion via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:56 2013 C:\WINDOWS\system32\route.exe DELETE 192.168.178.0 MASK 255.255.255.0 192.168.178.1
Tue Jul 23 15:15:56 2013 ROUTE: route deletion failed using DeleteIpForwardEntry: Falscher Parameter.  
Tue Jul 23 15:15:56 2013 Route deletion via IPAPI failed [adaptive]
Tue Jul 23 15:15:56 2013 Route deletion fallback to route.exe
Tue Jul 23 15:15:56 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Jul 23 15:15:56 2013 C:\WINDOWS\system32\route.exe DELETE 127.0.0.1 MASK 255.255.255.255 *.*.*.1
Tue Jul 23 15:15:56 2013 ROUTE: route deletion failed using DeleteIpForwardEntry: Falscher Parameter.  
Tue Jul 23 15:15:56 2013 Route deletion via IPAPI failed [adaptive]
Tue Jul 23 15:15:56 2013 Route deletion fallback to route.exe
Tue Jul 23 15:15:56 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Jul 23 15:15:56 2013 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 192.168.178.1
Tue Jul 23 15:15:56 2013 Route deletion via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:56 2013 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 *.*.*.1
Tue Jul 23 15:15:56 2013 Route addition via IPAPI succeeded [adaptive]
Tue Jul 23 15:15:56 2013 Closing TUN/TAP interface
Tue Jul 23 15:15:56 2013 SIGTERM[hard,init_instance] received, process exiting
Tue Jul 23 15:15:56 2013 MANAGEMENT: >STATE:1374585356,EXITING,init_instance,,

Hast Du eine Idee, was da falsch läuft ?
Grüße,

JD.

MaxMuster · 23 Jul 2013

Warum versucht er denn eine Route für 127.0.0.1 (also "sich selbst" zu setzen)? Das sieht fast so aus, als "verbindest du dich mit dir selbst")

.

Wie lautet denn dein "remote" Eintrag bzw. wie wird dieser Name aufgelöst ("ping <remote in der Client-Config>")?

EDIT: Vermute, du nutzt einen Proxy auf dem Client selbst? Dann muss das "in die Hose gehen": Der Client will eine Route zum Server (bzw. zum Proxy) über "das alte Routing" behalten und alles andere "umbiegen". Wenn aber der Proxy "du selbst" bist, rettest du die alte Route nicht sondern entziehst in diesem Fall hier nicht nur dem OpenVPN-Client sondern zugleich auch dem Proxy den Weg zum Server.
Solltest du das so nutzen wollen, musst du zuvor "von Hand" eine Hostroute zum VPN-Server über das "alte" Gateway eintragen.

JohnDoe42 · 23 Jul 2013

MaxMuster schrieb:
EDIT: Vermute, du nutzt einen Proxy auf dem Client selbst?

Sorry, mea culpa ... Du vermutest natürlich richtig.

Solltest du das so nutzen wollen, musst du zuvor "von Hand" eine Hostroute zum VPN-Server über das "alte" Gateway eintragen.

Also in etwa sowas ?

Code:

route ADD 192.168.178.1 MASK 255.255.255.0 *.*.*.1

Und noch eine Frage: Was bedeutet "zuvor" ? Bevor ich die OpenVPN-Verbindung initiiere ? Zu diesem Zeitpunkt kennt doch mein Client(-Rechner) die IP des OpenVPN-Servers noch garnicht ... ?
Beste Grüße,

JD.

MaxMuster · 23 Jul 2013

Nee, die "Internet-IP", also die DSL-IP der Box.
Ggf müsste man das vor dem OpenVPN-Start mit einem Skript machen.

Im Windows "route add <DSL-IP> <Gateway>".
Zur Not eben mit einem Skript (ohne sed und grep müsste man da schon etwas "basteln"...)

Gesamten Fritz!Box LAN-Traffic über OpenVPN Tunnel ins Internet routen

Aktives Mitglied

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Aktives Mitglied

IPPF-Promi

Statistik des Forums