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

[gesko]

@MaxMsuter

Vielen Dank für den Hinweis. Das ist ja ärgerlich. Könntest Du vielleicht näher erläutern woran das liegt? Gestern habe ich noch aus dem aktuellen Trunk neue Binaries und Module mit der 5.50 gebaut .... Aber das Experiment kann ich dann wohl abbrechen oder? Selbst mit freetz fw geht es nicht? Kommt man an einem Downgrade nicht vorbei?

Welches ist denn die letzte fw mit der es noch funktioniert? Könntest Du mir hier evtl. einen Downloadlink zur Verfügung stellen? Auf dem AVM ftp servern im Downgrade Verzeichnis erhält man nur die 5.05.

Greets Gesko

 

[MaxMuster]

Es gibt mehrere Threads dazu, dass iptables mit neueren FWs nicht mehr geht. AVM nutzt selbst einen Teil von iptables für den "Packet-Accelerator", damit ist das "reguläre" iptables teilweise ausgeschlossen.

 

[radislav]

Hallo,

gibt es eine Möglichkeit, diese iptables-Regel durch eine andere zu ersetzten, z.B. mit ip?

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

wie schon vorhin erwähnt, funktioniert iptables mit nat leider überhaupt nicht mit der aktuellen FW 05.xx

 

[MaxMuster]

Nat ohne iptables? Nicht das ich wüsste...

 

[radislav]

Hallo,

ich habe noch eine kleine Unschönheit entdeckt: Nachdem openvpn läuft, sind die Portfreigaben auf die einzellnen Cliens nicht mehr gültig. z.B. diese: "tcp 0.0.0.0:5900 192.168.178.20:5900 0 # vnc", Der Rechner mit xx.20 ist also (von Außen) per vnc nicht zu erreichen. Wenn man aber openvpn killt, dann gehts. Interessant ist auch, dass die Freigaben auf sich selbs sehr wohl funktinieren, z.B. diese "tcp 0.0.0.0:21 0.0.0.0:21 0 # ftpd",

MasMuster, hast du eine Idee woran das liegen kann und wie man es korrigieren kann?

Viele Grüße

 

[RalfFriedl]

Das liegt nicht daran, dass die Box die Verbindungen nicht weiter leitet, sondern daran, dass die Default Route am PC von Box auf OpenVPN geändert wird. Konkret kommt der Verbindungs-Aufbau von der Box beim PC an, aber die ANtwort geht nicht an die Box, sondern an den OpenVPN Server, und der kann damit nichts anfangen.

 

[radislav]

sowas habe ich vermutet... kann man die Portfreigabe dennoch irgendwie einstellen?

 

[MaxMuster]

Woran das liegt? Das ist erstmal "einfach":
Die Portweiterleitungen werden vom dsld gemacht und greifen für Pakete vom DSL-Interface ins LAN (bzw. WLAN) und zurück.
Die FTP-Freigabe landet "auf der Box", alles von der Box wird per Regelwerk über die DSL-Verbindung geschickt. Damit "bleibt alles beim alten".
Beim VNC (aus dem LAN) gehen jetzt aber alle Pakete zum VPN Tunnel Interface, damit kann der dsld nichts mehr tun.

Das kann also nicht mehr funktionieren, denn die "Antworten" von dem VNC-Gerät werden, wie von dir "gewünscht" (zumindest konfiguriert) in den VPN-Tunnel geschickt und deshalb nicht vom dsld "zurückgenattet".

Um etwas ähnliches zu erreichen, könntest du das über die VPN-Strecke machen, dazu müsste aber zunächst die VPN-Schnittstelle selbst eine "öffentliche" IP haben (und darf nicht "genattet" sein, wie bei dir wohl der Fall).
Hätte dein Tunnel-Interface eine "öffentliche IP", dann könntest du die VNC-Verbindung über diese "VPN-IP" machen und auf der Box am VPN-Interface eintreffende Pakete für bestimmte Ports mit iptables an bestimmte interne Geräte weiterleiten:

Das könnte dann für den oben genannten Fall sowas sein (nur "aus dem Kopf")

iptables -t nat -A PREROUTING -i tun0 -p tcp --dport 5900 -j DNAT --to 192.168.178.20:5900

ALternativ könntest du versuchen auch für die bekannten "Portforwarding-Geräte und -Protokolle" jeweils eine weitere "Ausnahme" generieren, so dass z.B. VNC-Pakete von dem Server nicht durch den VPN-Tunnel geroutet werden. Dazu müsstest du (ähnlich wie in Beitrag #83 beschrieben) die Pakete markieren und dann anders routen:

iptables -A PREROUTING -i lan -t mangle -p tcp  -s 192.168.178.20 --sport 5900  -j MARK --set-mark 1

# alles mit "mark 1" wie zuvor weiter zur "normalen" Routingtabelle
ip rule add fwmark 1 prio 30010 table main

 

[radislav]

beide Methoden funktionieren leider noch nicht:
1. DNAT

# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere anywhere UNKNOWN match `tcp' to:192.168.178.20:5900

2. MARK

# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- NAS.fritz.box anywhere UNKNOWN match `tcp' [8 bytes of unknown target data]

 

[MaxMuster]

War vielleicht noch nicht deutlich genug:
Die "Version 1" geht bei dir (mit "privaten IPs" im VPN) definitiv nicht. Das wäre für Szenarien möglich, wo du im VPN eine öffentliche IP bekommst (wie sonst die IP des DSL). Aber da du den Infos zufolge keine solche IP im VPN bekommst, geht das bei dir nicht! Zusätzlich müsstest du dann beim Aufruf des VNCs die IP des VPN-Providers nutzen, die du noch irgendwie in Erfahrung bringen müsstest...

Die zweite Version scheint ja zumindest irgendwie zu funktionieren (es gibt "matches", allerdings nur sehr wenige). Hast du auch den "ip rule" Befehl dazu mit genutzt?
Hast du die Möglichkeit, von dem VNC-Gerät aus einen TCP-Trace (vom Port 5900 aus) zu machen?!?

 

[radislav]

ok, vergessen wir also die erste...

"ip rule" Befehl habe ich natürlich dazu benutzt.
tcptraceroute kann ich freilich auf dem .20-Client ausführen:

# tcptraceroute --track-port --dnat -P 5900 www.wissen.de
Warning: --track-id implied by specifying the local source port
Selected device eth0, address 192.168.178.20, port 5900 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.731 ms 0.485 ms 0.490 ms
2 10.119.0.1 31.786 ms 26.720 ms 28.066 ms
3 vss-6b-6k.fr.eu (178.33.227.252) 32.589 ms * 53.476 ms
4 rbx-g1-a9.fr.eu (91.121.128.43) 61.083 ms 30.208 ms 26.958 ms
5 * * *
6 decix.dts-online.net (80.81.192.149) 35.664 ms 35.572 ms 37.135 ms
7 edge1-ae0-68.dts-online.net (212.62.68.251) 42.691 ms 41.737 ms 117.644 ms
8 * * *
9 84.201.97.76 [open] 41.551 ms 42.632 ms 46.565 ms

Ich hoffe mal, dass ich nun das richtige ausgeführt habe...

 

[MaxMuster]

O.k., die iptables Regel scheint nicht zu greifen, es geht durchs VPN, wie man sieht.

Mein iptables-Befehl müsste wohl auf "OUTPUT" gehen, statt beim "PREROUTING" einzugreifen. Geht das :

iptables -A OUTPUT -i lan -t mangle -p tcp  -s 192.168.178.20  ! -d 192.168.178.0/24 --sport 5900  -j MARK --set-mark 1

?

 

[unn4m3d]

Hallo,
ich möchte mich hier mal einklinken. Ich würde gerne meine Fritzbox 7270v3 mit aktueller Firmware-Version: 74.05.50 und freetz als OpenVPN Client nutzen damit alle verbundenen Geräte über den Tunnel ins Internet kommen können.

Ist das jetzt erstmal prinzipiell unmöglich wegen den weiter oben erwähnten IPTables?
Ich habe von meinem VPN Anbieter folgende Config bekommen:

client
dev tun
proto udp
remote xxx.xxx.xxx.xxx 443
resolv-retry infinite
nobind
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3
explicit-exit-notify 5
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/user.crt
key /tmp/flash/openvpn/user.key
log /var/tmp/debug_openvpn.out

Ich habe die Zertifikate auf die Box geladen, komme aber jetzt nicht weiter, bzw. bin auch verunsichert wegen dieser iptables Aussage weiter oben.

 

[radislav]

leider auch nicht

# ./iptables -A OUTPUT -i lan -t mangle -p tcp -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900 -j MARK --set-mark
1
iptables v1.4.11.1: Can't use -i with OUTPUT
Try `iptables -h' or 'iptables --help' for more information.
# ./iptables -A OUTPUT -t mangle -p tcp -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900 -j MARK --set-mark 1
# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK tcp -- irisha.fritz.box !192.168.178.0/24 UNKNOWN match `tcp' [8 bytes of unknown target data]
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
# ip rule add fwmark 1 prio 30010 table main
#

danach traceroute:

# tcptraceroute --track-port --dnat -P 5900 www.wissen.de
Warning: --track-id implied by specifying the local source port
Selected device eth0, address 192.168.178.20, port 5900 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.691 ms 0.701 ms 1.340 ms
2 10.119.0.1 102.147 ms 28.042 ms 27.632 ms
3 vss-6b-6k.fr.eu (178.33.227.252) 30.083 ms 29.777 ms *
4 rbx-g1-a9.fr.eu (91.121.128.43) 30.476 ms 32.570 ms 28.027 ms
5 fra-1-6k.de.eu (178.33.100.243) 44.411 ms * 34.486 ms
6 decix.dts-online.net (80.81.192.149) 36.732 ms 37.595 ms 35.068 ms
7 edge1-ae0-68.dts-online.net (212.62.68.251) 43.818 ms 126.304 ms 41.368 ms
8 * * *
9 84.201.97.76 [open] 42.346 ms 46.737 ms 55.015 ms

 

[MaxMuster]

@radislav:
Das sieht aber bei mir ganz anders (besser) aus:

root@fritz:/var/tmp/netfilter# iptables -A OUTPUT -t mangle -p tcp -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900 -j MARK --set-mark 1
root@fritz:/var/tmp/netfilter# iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
MARK       tcp  --  192.168.178.20      !192.168.178.0/24     [B]tcp spt:5900 MARK set 0x1[/B]

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
root@fritz:/var/tmp/netfilter#

mit aktueller Firmware-Version: 74.05.50 und freetz als OpenVPN Client nutzen damit alle verbundenen Geräte über den Tunnel ins Internet kommen können.

das ist tatsächlich mit der FW nicht möglich, weil es das mit dieser FW nicht vollständig laufende iptables benötigte.

 

[unn4m3d]

Danke für deine schnelle Antwort MaxMuster.

Welche ist denn die letzte die das supportet hat?

 

[radislav]

@MaxMuster: ok, vielleicht habe ich beim herumspielen irgendwas durcheinander gebracht: ich mache heute Abend mal ein Hardreset und dann probiere ich es noch Mal...
[NACHTRAG]
nein: nach einem Neustart ist es immer noch so. Fehlen bei mir vielleicht irgendwelche module?

xt_MARK                 1910  1 
rtc_avm                 6557  1 
rtc_sysfs               2704  0 
rtc_proc                3847  0 
rtc_dev                 5493  1 
rtc_core                7083  4 rtc_avm,rtc_sysfs,rtc_proc,rtc_dev
rtc_lib                 2712  3 rtc_avm,rtc_sysfs,rtc_core
ipt_MASQUERADE          2579  1 
iptable_nat             6662  1 
ip_nat                 15885  2 ipt_MASQUERADE,iptable_nat
ip_conntrack           46260  3 ipt_MASQUERADE,iptable_nat,ip_nat
xt_tcpudp               2743  1 
iptable_mangle          2136  1 
iptable_filter          2158  0 
ip_tables              11822  3 iptable_nat,iptable_mangle,iptable_filter
x_tables               13427  5 xt_MARK,ipt_MASQUERADE,iptable_nat,xt_tcpudp,ip_tables
.....

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

 

[MaxMuster]

Hab es kurz versucht "nachzustellen", die "PREROUTING" Kette sollte passen (kann aber auch an meinem nicht kompletten "Nachbau" deines Szenarios liegen):

root@fritz:/var/tmp# iptables -A OUTPUT  -t mangle -p tcp  -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900  -j MARK --set-mark 1
root@fritz:/var/tmp# iptables  -A PREROUTING  -t mangle -p tcp  -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900  -j MARK --set-mark 1
#
# jetzt auf einem Rechner: sudo tcptraceroute -s 192.168.178.20  -p 5900 1.1.1.1
# 
root@fritz:/var/tmp# iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 56 packets, 3068 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    4   240 MARK       tcp  --  *      *       192.168.178.20      !192.168.178.0/24     tcp spt:5900 MARK set 0x1

Chain INPUT (policy ACCEPT 49 packets, 2612 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 1 packets, 60 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 38 packets, 6421 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MARK       tcp  --  *      *       192.168.178.20      !192.168.178.0/24     tcp spt:5900 MARK set 0x1

Chain POSTROUTING (policy ACCEPT 39 packets, 6481 bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@fritz:/var/tmp#

 

[radislav]

leider steht bei mir immer noch was kommischen drin:

mein upScript:
# iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
# ip rule add from 192.168.178.0/24 to 192.168.178.0/24 prio 30000 table main
# ip rule add from 192.168.178.1 prio 30001 table main
# ip rule add from 192.168.178.0/24 prio 31000 table 2
# ip route replace default dev tun0 table 2
...
...
# ip rule add fwmark 1 prio 30010 table main
....
# ./iptables -A OUTPUT  -t mangle -p tcp  -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900  -j MARK --set-mark 1
# ./iptables  -A PREROUTING  -t mangle -p tcp  -s 192.168.178.20 ! -d 192.168.178.0/24 --sport 5900  -j MARK --set-mark 1
# ./iptables -L -v -n -t mangle
Chain PREROUTING (policy ACCEPT 284K packets, 255M bytes)
 pkts bytes target     prot opt in     out     source               destination         
   35  1400 MARK       tcp  --  *      *       192.168.178.20     !192.168.178.0/24   [B] UNKNOWN match `tcp' [8 bytes of unknown target data] [/B]

Chain INPUT (policy ACCEPT 108K packets, 120M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 176K packets, 135M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 71520 packets, 28M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MARK       tcp  --  *      *       192.168.178.20     !192.168.178.0/24    [B]UNKNOWN match `tcp' [8 bytes of unknown target data] [/B]

Chain POSTROUTING (policy ACCEPT 247K packets, 164M bytes)
 pkts bytes target     prot opt in     out     source               destination 

# auf 192.168.178.20:
# tcptraceroute -s 192.168.178.20  -P 5900 www.wissen.de
Selected device eth0, address 192.168.178.20, port 5900 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.628 ms  1.272 ms  0.516 ms
 2  * * *
 3  * * *
alle anderen auch mit "* * *"

 

[MaxMuster]

o.k., beim "PREROUTING" matched es auch bei dir. Und der trace sieht jetzt auch besser aus (geht nicht durch das VPN, die "Sternchen" dürfte die Firewall des dsld machen, schließlich gibt es keine eingehneden Pakete dazu).
Ein tcptraceroute mit Port 5999 (oder was auch immer, ungleich 5900) sollte als zweiten Hop wieder die VPN-IP (10.119.X.Y) zeigen, dann "stimmt es" (Port 5900 geht durch dsl, alles andere durch das VPN).