[Gelöst] FB als OpenVPN Client - externes Netz nur über Telnet von der FB erreichbar

[fry2k]

Ich hab mich heute zum ersten mal mit Freetz auf einer Fritzbox 7362 beschäftigt. Ich habe die Firmware 6.20 installiert und mir hierfür ein Freetz Image mit nur OpenVPN erstellt.

Der OpenVPN Server läuft auf einem debian System und hier wird mittels push "route 10.59.140.0 255.255.255.0" die Route für das interne Netz an den Client geschickt.

Der Verbindungsaufbau funktioniert auch problemlos, wenn ich mich mit telnet auf die Fritzbox einlogge, dann kann ich IP Adressen aus dem Netz 10.59.140.0 anpingen.
Auch ein "route" auf der Fritzbox liefert das gewünschte ergebnis mit allen Routen:

root@fritz:/var/tmp# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.1        10.8.0.17       255.255.255.255 UGH   0      0        0 tun0
10.8.0.17       *               255.255.255.255 UH    0      0        0 tun0
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
192.168.2.202   *               255.255.255.255 UH    2      0        0 dsl
192.168.2.201   *               255.255.255.255 UH    2      0        0 dsl
x.x.x.x         *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
x.x.x.x         *               255.255.255.255 UH    2      0        0 dsl
x.x.x.x         *               255.255.255.255 UH    2      0        0 dsl
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
192.168.2.0     *               255.255.255.0   U     0      0        0 lan
10.59.140.0     10.8.0.17       255.255.255.0   UG    0      0        0 tun0
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

root@fritz:/var/tmp# ping 10.59.140.137
PING 10.59.140.137 (10.59.140.137): 56 data bytes
64 bytes from 10.59.140.137: seq=0 ttl=64 time=59.915 ms
64 bytes from 10.59.140.137: seq=1 ttl=64 time=60.072 ms
64 bytes from 10.59.140.137: seq=2 ttl=64 time=61.078 ms
64 bytes from 10.59.140.137: seq=3 ttl=64 time=60.705 ms
^C
--- 10.59.140.137 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 59.915/60.442/61.078 ms

Versuche ich dies aber von einem PC, der im Netz der Fritzbox ist, funktioniert dies nicht.
Als erstes habe ich an iptables Masquerade gedacht, jedoch ist iptables für freetz unstable und funktioniert zum Teil nicht? Liegt es tatsächlich daran?
Hat vielleicht jemand einen Tip für mich?
Mit client-config-dir und route bzw. iroute habe ich auch schon probiert mein lokales Netz 192.168.2.0 dem Server bekannt zu machen, hat jedoch auch nichts gebracht.

openvpn.server

port 1337
proto udp
dev tun
ca xxx.crt
cert xxx.crt
key xxx.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.59.140.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

erstellte client config auf der Fritzbox

root@fritz:/var/tmp# less /mod/etc/openvpn.conf
#  OpenVPN 2.1 Config, Sun Jan 18 18:48:19 CET 2015
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
remote xxx 1337
nobind
pull
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn.out
verb 3
cipher BF-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

 

[PeterPawn]

Das Gateway für das 10.59.140.0/24-Netz ist lt. Routing-Table wieder die lokale OVPN-Instanz und Du hast offenbar TUN-Mode und - sieht man halt nicht (brctl show) - nicht das tun0-Interface ins "dev lan" gebridged.

Als schnellen Test würde ich mal versuchen, auf der FRITZ!Box die Route mit "ip r cha 10.59.140.0/24 via 10.8.0.1 dev tun0" auf den OpenVPN-Server zeigen zu lassen. Wenn damit der Traffic ankommen sollte (ein traceroute aus dem LAN ist natürlich auch wesentlich aussagekräftiger als "geht nicht", weil man dann leichter sieht, bis wohin es vielleicht doch geht), kann man sich immer noch überlegen, was der Server als Route pushen soll.

 

[fry2k]

Danke schonmal für die Hilfe!

Ja, komisch das als Gateway für die Route die VPN Client Adresse drin steht (10.8.0.5), scheint aber normal zu sein. Wenn ich die Verbindung mit dem OpenVPN Client unter Windows aufbaue, steht unter Windows die selbe Route drin.

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.51     25
         10.8.0.1  255.255.255.255         10.8.0.5         10.8.0.6     30
      10.59.140.0    255.255.255.0         10.8.0.5         10.8.0.6     30

"ip r cha 10.59.140.0/24 via 10.8.0.1 dev tun0" funktioniert leider nicht, als Fehler kommt dann "ip: RTNETLINK answers: Network is unreachable"

brctl hat die option show leider nicht, dafür müsste ich ein extra paket installieren?

root@fritz:/var/tmp# brctl --help
BusyBox v1.22.1 (2015-01-18 16:54:28 CET) multi-call binary.

Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
        addbr BRIDGE            Create BRIDGE
        delbr BRIDGE            Delete BRIDGE
        addif BRIDGE IFACE      Add IFACE to BRIDGE
        delif BRIDGE IFACE      Delete IFACE from BRIDGE

root@fritz:/var/tmp# brctl show
brctl: invalid argument 'show' to 'brctl'

Noch ein traceroute von der Fritzbox

root@fritz:/var/tmp# traceroute 10.59.140.150
traceroute to 10.59.140.150 (10.59.140.150), 30 hops max, 38 byte packets
 1  10.8.0.1 (10.8.0.1)  60.017 ms  60.256 ms  59.890 ms
 2  10.59.140.150 (10.59.140.150)  60.061 ms  59.445 ms  59.706 ms

Und eins von dem Windows LAN Client

C:\Users\fry2k>tracert 10.59.140.150

Routenverfolgung zu 10.59.140.150 über maximal 30 Abschnitte

  1     3 ms     5 ms     1 ms  192.168.2.1
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4  ^C

 

[fry2k]

OK, ich hab das Problem gelöst.
Es lag wohl tatsächlich wie von mir vermutet an dem fehlenden NAT auf der Fritzbox. Da iptables aktuell wohl nicht mehr problemlos funktioniert, habe ich auf dem Server das lokale Netz verfügbar gemacht. Der Vollständigkeithalber:

Auszug aus der server.conf

route 192.168.2.0 255.255.255.0
client-config-dir /etc/openvpn/ccd

server: /etc/openvpn/ccd/client_fritz

client-to-client
iroute 192.168.2.0 255.255.255.0

 

[PeterPawn]

Wenn ich die Verbindung mit dem OpenVPN Client unter Windows aufbaue, steht unter Windows die selbe Route drin.

Das bezweifle ich nicht, auch der direkte Zugriff von der FRITZ!Box aus funktioniert ja, wie Du schreibst.

Wenn Du auf der Box selbst ein ping-Kommando startest, wird automatisch das Interface benutzt, das sich aus der Zieladresse anhand der lokalen Routing-Tabelle ergibt und dann an dieses Interface gesendet. Das ist zwar auch ein Zugriff auf die Einstellungen aus der Routing-Tabelle, aber wenn das Interface dann erst einmal geöffnet ist, müssen die dorthin gesendeten Pakete ja nicht noch einmal durch das Routing.

Auf "dev lan" eingehende Pakete nehmen aber eben genau diesen Weg und werden dann - meine Theorie/Interpretation - an das dort für dieses Ziel hinterlegte Interface ausgegeben, das wäre in Deinem Falle 'tun0'. Wenn dann dort wieder nachgesehen wird, wohin Pakete an das Zielnetz zu senden sind, ist das wieder tun0. Dieser "loop" würde imho nur unterbrochen, wenn das Paket "hinter" dem Routing an den OpenVPN-Daemon ankommt und dort für das richtige Ziel (das ist der OpenVPN-Server, theoretisch könnten das ja auch mehrere Ziele sein, wenn mehr als eine OpenVPN-Verbindung besteht) verschlüsselt und verpackt wird. Die Idee beim Bridgen ist es, daß das Paket dann auf Layer2 (und nicht im Routing) für den OpenVPN-Daemon sichtbar wird und auf die Reise gehen kann. Das sind die theoretischen Überlegungen, die es zu bestätigen oder zu widerlegen gilt, wenn Du der Erklärung eine gewisse Wahrscheinlichkeit zubilligst.

Warum sich der Network-Stack dem Ändern der Route verweigert, verstehe ich allerdings nicht, denn die Fehlernachricht sagt ja eigentlich, er kennt keinen Weg zu 10.8.0.1, während der als UGH (Up, Gateway, Host) - also als indirekte Route zu einem Host (über 10.8.0.17) - als erster Eintrag in der Tabelle steht. Da bin ich etwas ratlos, würde notfalls alternativ nicht auf "change", sondern auf "delete" gefolgt von "add" zum Test setzen.

Das Problem mit dem fehlenden show-Command beim brctl-Applet höre ich heute schon zum zweiten Mal, da könnte jemand beim Aufräumen in den Applets der Busybox in Freetz etwas zu gründlich gewesen sein.

Wenn Du auf das "show" verzichtest und einfach mal ein "add" für tun0 zur lan-Bridge als Test machst, sollte das notfalls auch eine Fehlernachricht ergeben (Device or resource busy), wenn tun0 schon hinzugefügt wurde.

Das Hinzufügen müßte dann so aussehen: brctl addif lan tun0

Wenn das Interface nach dem Beenden des OpenVPN-Daemons deaktiviert wird, sollte es automatisch wieder aus der Brigde fliegen - theoretisch jedenfalls. Meines Wissen kann ein "down"-Interface nicht Member sein.

Ansonsten kannst Du auch die AVM-Busybox (liegt in Deinem Freetz-Trunk-Verzeichnis unter build/original/filesystem/bin/busybox) auf einen USB-Stick (oder gleich per FTP in den NAND-Flash bei /var/media/ftp, die 7362SL müßte ja auch 22 MB davon haben) kopieren und von dort aufrufen (...path.../busybox brctl show).

Ansonsten solltest Du für das nächste Freetz-Image dann auch prophylaktisch mal ein passendes brctl-Applet konfigurieren. Bei AVM ist es enthalten

BusyBox v1.20.2 (2014-09-26 13:25:19 CEST) multi-call binary.

Usage: brctl COMMAND [BRIDGE [INTERFACE]]

Manage ethernet bridges

Commands:
        show                    Show a list of bridges
        addbr BRIDGE            Create BRIDGE
        delbr BRIDGE            Delete BRIDGE
        addif BRIDGE IFACE      Add IFACE to BRIDGE
        delif BRIDGE IFACE      Delete IFACE from BRIDGE
        setageing BRIDGE TIME           Set ageing time
        setfd BRIDGE TIME               Set bridge forward delay
        sethello BRIDGE TIME            Set hello time
        setmaxage BRIDGE TIME           Set max message age
        setpathcost BRIDGE COST         Set path cost
        setportprio BRIDGE PRIO         Set port priority
        setbridgeprio BRIDGE PRIO       Set bridge priority
        stp BRIDGE [1/yes/on|0/no/off]  STP on/off

(ist zwar eine 7490/06.23-BB, aber das sollte egal sein) und wenn die aus irgendeinem Grund mal auf die Idee kommen, es zu verwenden, dann geht die Sucherei erst richtig los. Ich werde mal bei Gelegenheit im Freetz-Trunk schauen, ob da tatsächlich 'show' nicht dabei ist, wenn man die Standard-Konfiguration nimmt.

EDIT:

habe ich auf dem Server das lokale Netz verfügbar gemacht.

Mit client-config-dir und route bzw. iroute habe ich auch schon probiert mein lokales Netz 192.168.2.0 dem Server bekannt zu machen, hat jedoch auch nichts gebracht.

:gruebel:

 

[MaxMuster]

Das mit dem "route/iroute" war vermutlich der fehlende Part.
Falls es interessiert: Die Config deutet auf eine "Multi-Client"-(fähige) Konfig auf dem OpenVPN-Server hin.
Dann gibt es ein Zusatz-"Feature": Es reicht nicht, dass der VPN-Prozess die Pakete "bekommt" (dafür reicht die "normale" Route im IP-Stack auf ein Interface des VPNs, also der "route"-Eintrag in der Config), das OpenVPN muss jetzt noch wissen, zu welchem der (potenziell mehreren) Clients das Netz geroutet werden muss. Das macht der "iroute" Eintrag im CCD. Ohne den
- Weiß der VPN-Prozess nicht, wohin er Pakete zu schicken hat
- Verwirft er "eingehende" Pakete von diesem Netz (und es gibt Fehlermeldungen dieser Art im Log: ""MULTI: bad source address from client <XY> , packet dropped")

EDIT
Zu

"ip r cha 10.59.140.0/24 via 10.8.0.1 dev tun0" funktioniert leider nicht, als Fehler kommt dann "ip: RTNETLINK answers: Network is unreachable"

Du kannst keine Routen "kaskadieren". Es gibt kein Interface, das (direkt) zu 10.8.0.1 führt, sondern das Ziel müsste in einem zweiten Schritt auch noch herausgesucht werden.
Es muss also ein "direkt erreichbarer Next-Hop" angegeben werden. Ist aber auf einem "normalen" Linux auch so:

joerg@joerg-virtual-machine:~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
1.1.1.1         10.10.10.2      255.255.255.255 UGH   0      0        0 lo
joerg@joerg-virtual-machine:~$ sudo ip route add 2.2.2.2/32 via 1.1.1.1
RTNETLINK answers: Network is unreachable
joerg@joerg-virtual-machine:~$ sudo ip route add 2.2.2.2/32 via 1.1.1.1 dev lo
RTNETLINK answers: Network is unreachable
joerg@joerg-virtual-machine:~$ 
joerg@joerg-virtual-machine:~$ sudo ip route add 2.2.2.2/32 via 10.10.10.2
joerg@joerg-virtual-machine:~$ route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
1.1.1.1         10.10.10.2      255.255.255.255 UGH   0      0        0 lo
2.2.2.2         10.10.10.2      255.255.255.255 UGH   0      0        0 lo
joerg@joerg-virtual-machine:~$