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

[MaxMuster]

Ja, dann wären logs prima.
Könnte ja durchaus ein "trivialer" Fehler sein, z.B. ein ohne "LZO" im OpenVPN gebautes Image und lzo in der Konfig...
Oder die Box hat (noch) keine korrekte Zeit, und die Zertifikate werden als "ungültig" (weil aus der Zukunft) abgelehnt.

 

[zweifler196]

Hier nun ein kleiner Teil vom Log: Sieht ja so aus, als ob er ein Problem mit dem Statix.key hat, nur warum geht es manchmal?


Mon Oct 29 15:52:08 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Mon Oct 29 15:52:08 2012 Diffie-Hellman initialized with 1024 bit key
Mon Oct 29 15:52:08 2012 WARNING: file '/tmp/flash/openvpn/static.key' is group or others accessible
Mon Oct 29 15:52:08 2012 Control Channel Authentication: using '/tmp/flash/openvpn/static.key' as a OpenVPN static key file
Mon Oct 29 15:52:08 2012 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Oct 29 15:52:08 2012 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
.
.
.
.
.
Mon Oct 29 16:00:12 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:00:18 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:00:28 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:00:38 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:00:48 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:00:50 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:00 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:11 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:21 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:32 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:42 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:52 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:01:54 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:04 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:14 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:24 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:34 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:45 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:02:55 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:03:05 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:03:15 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:03:25 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:03:35 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Mon Oct 29 16:03:45 2012 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)

 

[MaxMuster]

Die "ECONNREFUSED"-Fehler kommen normalerweise, wenn eine Seite versucht mit der anderen zu "reden", obwohl die andere Seite die Verbi Sndung schon getrennt hat. Einen Grund für Abbrüche sehe ich nicht.

Was ist denn "dazwischen", in den acht Minuten?
Bitte bei längeren Ausgabe diese zwischen [noparse]

 und

[/noparse] einbetten, dann sind auch längere Logs erträglich lesbar.

 

[zweifler196]

Neuer Test folgt .....

 

[sengelking]

Hallo, ich habe ein ähnliches Problem…
Szenario: Im Wohnheim müssen wir uns ins OpenVPN der Hochschule einloggen um ins Internet zu kommen. Dafür hat jedes Zimmer eine LAN Buchse. Ich habe nun eine Fritz!Box Fon WLAN mit freetz und openvpn drauf. Die Box verbindet sich mittlerweile einwandfrei mit dem VPN und kann dann auch ins Internet. Allerdings die Clients die mit WLAN daran verbunden sind gehen nicht über das VPN.
Ich habe schon mehreres ausprobiert, komme aber nicht weiter.


Ergebnis von route -n nach OpeneVPN start:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
193.197.62.101  10.42.0.1       255.255.255.255 UGH   0      0        0 lan
134.108.58.0    0.0.0.0         255.255.254.0   U     0      0        0 tun0
10.42.0.0       0.0.0.0         255.255.0.0     U     0      0        0 lan
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 lan
0.0.0.0         134.108.58.1    128.0.0.0       UG    0      0        0 tun0
128.0.0.0       134.108.58.1    128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.42.0.1       0.0.0.0         UG    9      0        0 lan

iptables habe ich auch schon am laufen:

Chain POSTROUTING (policy ACCEPT 14 packets, 717 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13   960 MASQUERADE  all  --  any    tun0    anywhere             anywhere

Weiß jemand weiter?

 

[sengelking]

keine eine Lösung?

 

[MaxMuster]

Wie lautet die iptables Regel? In welchem Netz sind die WLAN-Clients? Nutzen sie die Box überhaupt als Gateway?

 

[zweifler196]

Neuer Test folgt .....

Edit: Um es abzuschließen, es war die virtuelle IP Adresse. Wer gleiche Probleme hat, mal eine andere nehmen. Das hilft!!!

 

[radislav]

Hallo,

ich habe es bei mir openvpn genau so, wie hier auf der ersten Seite beschrieben ist eingerichtet. Ich habe also defaultgateway angepasst, openvpn gestartet und mit "iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE" die Weiterleitung für die Clients eingerichtet. Das funktioniert alles bei mir wunderbar.

Danach ist mir eingefallen, dass mein Telefon (VoIP von KabelDeutschland) von außen nicht erreichbar ist: Genau das gleiche, wenn die Fritzbox ausgeschaltet ist. Muss ich dazu vielleicht noch eine Regel mit iptables einrichten?

Viele Grüße
R@d

 

[MaxMuster]

Ich vermute, das dürfte nicht an den "iptables" liegen, sondern am Routing.
Die IPs der KD-VoIP-Server müssen auch im Routing vom OpenVPN rausgenommen und zum "alten" Defaultgateway geroutet werden...

 

[radislav]

das "alte" Defaultgateway wird aber beim Anpassen gelöscht. Könntest du das vielleicht etwas genauer erläutern? Brauchst du vielleicht mehr Infos dazu?

 

[MaxMuster]

Du musst für die Voip-Server von KD eine statische Route über das Internet eintragen. Besorge die Ip's der Server und trage eine Hostroute dafür ein analog zum Gateway der Box ohne VPN bzw. so, wie die Route zum VPN-Server ist...

 

[radislav]

Wo finde ich denn diese Ip-Adressen? In den SIP-Einstellungen habe ich folgende Gefunden:

registrar = "reg142.kabelphone.de";
outboundproxy = "proxy.kabelphone.de";

Kann man diese dns-Namen benutzen?

Wenn ich jetzt doch die ip hätte, würde dann folgende route passen?

route add [ip-Adresse] gw 169.254.1.1 dev dsl

 

[MaxMuster]

Ja, so.

joerg@joerg-desktop:~$  dig proxy.kabelphone.de | grep -v '^;' | grep -e "IN[^A-Z]*A"
proxy.kabelphone.de.	3283	IN	A	83.169.182.1
joerg@joerg-desktop:~$ for x in 1 2 3 4 5 6 7; do dig prox0$x.kabelphone.de | grep -v '^;' | grep -e "IN[^A-Z]*A"; done
prox01.kabelphone.de.	3548	IN	A	83.169.182.1
prox02.kabelphone.de.	3229	IN	A	83.169.182.9
prox03.kabelphone.de.	1873	IN	A	83.169.182.17
prox04.kabelphone.de.	3508	IN	A	83.169.182.33
joerg@joerg-desktop:~$

Daher würde ich vorschlagen, einfach das ganze C-Netz 83.169.182.0 direkt ins Internet zu schicken:

route add -net  83.169.182.0/24 dev dsl

 

[radislav]

Vielen Dank! Das werde heute Abend mal probieren.

[EDIT]
Wunderbar! Telefon ist damit wieder erreichbar!
[/EDIT]

 

[radislav]

Hallo,

ich habe doch noch ein Problem, wahrscheinlich auch wegen dem angepassten Routing. Meine Fritzbox ist dann von Außen nicht mehr erreichbar, z.B. per FTP. Kann ich dann die Box irgendwie über die original-Ip des Provieders erreichen?

viele Grüße
R@d

 

[MaxMuster]

Naja, eins geht nur: Alles durch das VPN oder alles durch das Internet...
Du könntest jetzt höchstens versuchen, den Verkehr von der Box selbst per iptables vom Routing auszuschließen oder eine IP rule anzulegen...

EDIT: Oder du könntest dir eine Alternative zur Änderung des Default-Routings mit iptables bauen (also das Routing Richtung Internet lassen und nicht ins VPN "umbiegen"), so ähnlich wie in Beitrag #33:

# NAT (da bin ich ziemlich sicher, dass es so geht
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE 

# "Erzwungene Nutzung" des tun0-Interfaces für "LAN-Pakete" (hier für192.168.178.0/24)
# benötigt iptables "mangle" Modul 
# (das ist nur "zusammengeschrieben", nicht getestet, )
iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -j ROUTE --oif tun0

 

[radislav]

das klappt leider nicht:

# ./iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -j ROUTE --oif tun0
iptables v1.4.11.1: unknown option "--oif"
# ./iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -j ROUTE -i tun0
iptables v1.4.11.1: Couldn't load target `ROUTE':No such file or directory
# ./iptables -t mangle -A PREROUTING -s 192.168.178.0/24 -i tun0
[klappt]

Das letzte war wahrscheinlich gemeint und klappt auch, bringt aber so gut wie nichts: von außen ist die Box nicht erreichbar.

 

[MaxMuster]

Sorry, das ROUTE ist kein Standard und geht wohl nicht.
Das hätte auch nicht die Erreichbarkeit der Box von außen zur Folge. Die Idee war ja, dass du das Routing NICHT in das VPN änderst ("eine Alternative zur Änderung des Default-Routings"), sondern das Routing ins Internet stehen lässt. Die Regel hätte dann den "internen Verkehr" durch den Tunnel geschickt.

Dann wird es aber schwieriger. Du müsstest schauen, ob du mit "iproute2" arbeiten könntest. Du brauchst dafür eine Box mit "replace Kernel", sofern auf deiner Box im Kernel nicht schon "IP: advanced router" und "IP: policy routing" aktiviert ist.
Wenn das gegeben ist, könntest du mit "ip rules" das Routing beeinflussen.

 

[radislav]

Ok, weitere Herausforderung. Ich bedanke mich schon mal für deine Mühe!

Ist "iproute2" der befehl "ip" von der Busybox, bzw. FREETZ_BUSYBOX_FEATURE_IP_ROUTE (-> Advanced options -> BusyBox options -> ip -> route option) in freetz-config? Wie kann man sonnst herausfinden, ob "IP: advanced router" und "IP: policy routing" schon von Haus aus aktiviert sind? Ich habe den Kernel 2.6.19.2 (fw 54.04.86).