Tunnel zwischen Fritzbox und OpenVPN-Server nutzen zum surfen

[Gerdchen03]

OK, das mit dem weiteren VPN-Client gefällt mir am besten und wäre leicht umzusetzen. Derzeit kann ich vom OpenVPN-Server aus keinen Ping ins interne Netz absetzen. In der Datei in client-config-dir der Fritzbox habe ich nur iroute 192.168.178.0 255.255.255.0 eingetragen. Auf dem Server route 192.168.178.0 255.255.255.0 und push "route 192.168.178.0 255.255.255.0". Damit ging dann das Surfen mit meinem PC über die Fritzbox als Client.
Müssen in die Datei in client-config-dir auch noch route 192.168.178.0 255.255.255.0 und push "route 192.168.178.0 255.255.255.0" eingetragen werden?

 

[MaxMuster]

Also, das push-en der Route darf nur zu den "anderen" Clients erfolgen, nicht zu dem, bei dem das Netz angeschlossen ist.
Daher müsste der in Befehl in die Dateien im client-config-dir für "alle anderen Clients" (aber nur, sofern du nicht per "redirect-gateway" sowieso schon alles umgeleitet hast).

Ich wette zu 99%, dass du (sofern du die Nat-Regel raus hast) den PC schon pingen könntest, das aber von dessen Firewall geblockt wird.

 

[Gerdchen03]

Ich hab heute wieder Zeit mich ein wenig mit der Materie auseinanderzusetzen. Ich denke, ich habe alles umgesetzt, wozu du mir geraten hast. Ping (zu einer IP aus dem Netz 192.168.178.0) geht weder auf der Fritzbox noch auf irgendeinen Client vom OpenVPN-Server aus. Von meinem Rechner aus kann ich den OpenVPN-Server über 10.8.0.1 anpingen, meine Fritzbox über 10.8.0.14 allerdings nicht. Da spricht einiges dafür, dass das Problem an der Firewall liegt. Wie kann ich das Problem lösen?

Hier noch mal meine Einstellungen systematisch aufgelistet:

Meine iptables in der /etc/rc.local:

iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -o venet0 -s 192.168.178.0/24 -j SNAT --to xxx.xxx.xxx.xxx

vpnclient.conf auf der Fritzbox:

client # wir sind Client
dev tun #
dev-node /var/tmp/tun # Hier wird das Devide angegeben. wichtig!
proto udp # wir nutzen UDP, kein TCP
remote xxx.xxx.xxx.xxx 1194# die IP/ DNS Name der Gegenseite und Port
resolv-retry infinite # Namensauflösung immer
nobind # wir brauchen den Port nicht zu binden.
persist-key
persist-tun
ca ./xx.crt # Die Zertifikate (Pfadangabe muss richtig sein)
cert ./FritzBox.crt
key ./FritzBox.key
dh ./xxxxx.pem
comp-lzo # Komprimierung, sofern auf der Gegenseite auch aktiv.
verb 1 # Fuer Debugging ruhig bis 8 hochsetzen.
mute 20 # Nach x Wiederholungen im Log ruhe.

server.conf auf dem OpenVPN-Server

local xxx.xxx.xxx.xxx
port 1194
proto udp
dev tun
ca ./easy-rsa2/keys/xxx.crt
cert ./easy-rsa2/keys/server.crt
key ./easy-rsa2/keys/server.key
dh ./easy-rsa2/keys/xxxx.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
push "route 192.168.178.0 255.255.255.0"
route 192.168.178.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
comp-lzo
max-clients 12
user vpn
group vpn
persist-key
persist-tun
status openvpn-status.log
log-append  openvpn.log
verb 4

Datei FritzBox auf dem OpenVPN-Server im Ordner ccd:

iroute 192.168.178.0 255.255.255.0 # clientnetz + netmask

Ich hab einen Rechner im Netzwerk (192.168.178.0), den ich von außen mit z.B. IP-OpenVPN-Server:15000 erreichen muss. Das geht nicht mehr? Oder kann ich eine Protfreigabe einrichten, die alle Anfragen auf dem Port an den einen Rechner weiterleitet? Früher mit der normalen Fritzbox konnte ich ihn über dyndns-Adresse:15000 erreichen.

 

[MaxMuster]

Also, das push-en der Route darf nur zu den "anderen" Clients erfolgen, nicht zu dem, bei dem das Netz angeschlossen ist.

Nimm bitte den "push" Befehl aus der Server-Config.

server.conf auf dem OpenVPN-Server

...
push "route 192.168.178.0 255.255.255.0"
...

 

[Gerdchen03]

Ok, ich bin nicht sicher, ob ich es korrekt verstanden hab. Sorry!

Also, das push-en der Route darf nur zu den "anderen" Clients erfolgen, nicht zu dem, bei dem das Netz angeschlossen ist.

Muss dann in die server.conf ein Eintrag derart?
push "route 192.168.178.1 255.255.255.0"
push "route 192.168.178.2 255.255.255.0"

Update: push "route 192.168.178.1 255.255.255.0" hab ich probiert, klappt nicht, also offensichtlich Blödsinn


Oder bedeutet das, dass der Eintrag in die Dateien im client-config-dir des OpenVPN-Servers muss und somit an die Fritzbox übermittelt wird? Oder muss ich gar für jeden Client eine Dateien im client-config-dir anlegen, so dass jeder über das Netz Kenntnis hat?

 

[MaxMuster]

Der Server darf die Routen für Netze beim Client nicht "komplett" pushen.
Ansonsten wird der Client eine Route für sein LAN in Richtung VPN bekommen, was nicht sein darf.

Das heißt nochmal auf kurz: kein push "route ..." in die Hauptkonfig!

Wenn, dann in die einzelnen Configs der "anderen" Clients im client-config-dir.

Das wäre für das Netz 192.168.178.x ein Eintrag
push "route 192.168.178.0 255.255.255.0"

 

[Gerdchen03]

OK, ich hab alle push "route ...."-Einträge aus der server.conf auf dem OpenVPN-Server entfernt, und in die Datei für die Fritzbox im client-config-dir push "route 192.168.178.0 255.255.255.0" eingetragen. Das sollte so also richtig sein. Ein traceroute 192.168.178.1 oder ping 192.168.178.1 läuft sich aber dennoch tot.
Nun wäre die Firewall der Punkt, an dem ich ansetzen muss. Hättest du da bitte noch einen Tip für mich? Ich denke mal, es macht Sinn erst mal an der Fritzbox anzusetzen.

 

[MaxMuster]

Nein, das "push route" für darf für 192.168.178.0 255.255.255.0 gerade nicht in die Config der FB! Die "hat" ja das Netz selbst und darf es nicht in das VPN hinein routen.
Nur in "alle anderen" Configs kann/darf das stehen.

 

[Gerdchen03]

Das war dann wohl ein Missverständnis. Ich hatte das so verstanden,weil du oben vom server gesprochen hattest, in den der Eintrag nicht darf.
Der Eintrag push "route ..." darf also weder in die server.conf des OpenVPN-Servers, noch in die Datei für die Fritzbox im client-config-dir. Will ich dem Rechner mit dem Zertifikat "Computer1.crt" das Netz bekannt machen, muss ich auch für ihn eine Datei im client-config-dir anlegen, in der lediglich push "route ..." eingetragen wird.
Ich hoffe, jetzt hab ich es richtig umgesetzt.

 

[MaxMuster]

Ja, sollte passen.

Im Ergebnis darf es nicht sein, dass einem VPN-Client, bei dem lokal noch ein Netz ist (in der Regel ein Router, nicht ein OpenVPN-Client auf einem Endgerät), dieses Netz ins VPN routet.
Daher darf in der lokalen Config dieses Clients kein "route <LAN>" sein und er darf diesen Eintrag auch nicht per "push" bekommen.

Bei einem Server mit einer Multi-Client-Konfig heißt das, dass keine solche "push" Einträge in der "Haupt-Konfig" sind (denn alles da wird an alle Clients geschickt, auch an den einen, der das nicht bekommen darf, weil das LAN eben lokal ist und nicht "hinter" dem VPN).

Wenn denn "andere" Clients dieses LAN erreichen sollen, muss in der Konfig beim Client einen "route" Eintrag haben, oder dieses muss per "push" kommen, dann z.B. durch client-config-dir.
Hinweis: Wenn du jedoch per "redirect-gateway" dafür sorgst, das "alles" ins VPN geht, sind diese Einträge komplett überflüssig! Wichtig jedoch dann ein "client-to-client" in der Config.

 

[Gerdchen03]

Ich hab jetzt mein Smartphone per OpenVPN verbunden und in der Datei "smartphone" im client-config-dir den push "route 192.168.178.0 255.255.255.0" eingetragen. Ich verwende das Netz meines Mobilfunkanbieters, kein internes WLAN. Ich kann das Webinterface eines an der Fritzbox angeschlossenen Receivers nicht erreichen, also scheint es noch nicht zu klappen. Firewall evtl?

In der server.conf des OpenVPN-Servers ist ein push "redirect-gateway def1 bypass-dhcp" eingetragen. Somit brauche ich mich im Prinzip nicht um route und push "route ..." zu kümmern, korrekt?

Wichtig jedoch dann ein "client-to-client" in der Config.

In jeder Config, oder nur server.config auf dem OpenVPN-Server?

ifconfig auf der Fritzbox bringt mir:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.30  P-t-P:10.8.0.29  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:21259 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7400 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:27650895 (26.3 MiB)  TX bytes:651144 (635.8 KiB)

Wenn ich auf dem OpenVPN-Server ein ping 10.8.0.30 absetze passiert noch immer nichts. Von der Fritzbox aus kann ich alle Rechner im VPN-Netz anpingen, z.B. 10.8.0.1 oder 10.8.0.10, aber keinen aus dem 192.168.178.0-Netz.

 

[MaxMuster]

Also, client-to-client ist ein Server-Befehl:

--client-to-client
    Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. 
    The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating 
    traffic to the TUN/TAP interface.

    When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will 
    only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.

Im Tunnel-Modus werden (ohne "topology subnet") noch immer /30 "Pseudo-Netze" vergeben. Die "IP des Servers" existiert nicht und wird nur fürs Routing genutzt. Der Server kann (in deiner Konfig) nur unter der .1 erreicht werden.
Der Server selbst müsste die .30 in deinem Beispiel aber erreichen, wenn der Client verbunden ist. Man sieht ja auch, dass Rx und Tx Counter da sind, es sollte also was durch den Tunnel gehen ...

 

[Gerdchen03]

Ja, das was durch geht sieht man. Ich kann auch mit meinem Rechner, der an der Fritzbox hängt surfen. vom Server aus sind weder Fritzbox über 10.8.0.30, noch ein anderer Rechner über eine 192.168.178.0-IP zu erreichen.

root@v45838:/etc/openvpn# traceroute 10.8.0.10
traceroute to 10.8.0.10 (10.8.0.10), 30 hops max, 60 byte packets
 1  10.8.0.10 (10.8.0.10)  120.050 ms  120.047 ms  120.037 ms
root@v45838:/etc/openvpn# traceroute 10.8.0.30
traceroute to 10.8.0.30 (10.8.0.30), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
root@v45838:/etc/openvpn# traceroute 192.168.178.1
traceroute to 192.168.178.1 (192.168.178.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *

Außerdem kann ich von meinem Rechner aus auf mein Smartphone zugreifen, welches mit dem OpenVPN-Server mobil verbunden ist, nicht über WLAN:

rechner-wlan:~ user$ traceroute 10.8.0.10
traceroute to 10.8.0.10 (10.8.0.10), 64 hops max, 52 byte packets
 1  fritz.box (192.168.178.1)  0.869 ms  0.485 ms  0.435 ms
 2  10.8.0.10 (10.8.0.10)  130.129 ms  87.601 ms  85.054 ms

 

[MaxMuster]

Also, wie sehen denn diesbezüglich (192.168.178.0) die Routingtabellen auf der FB und dem Server aus? In der Server-Config muss ein "route 192.168.178.0 255.255.255.0" (beachte: kein push!) enthalten sein.
Die FB darf keinesfalls eine Route für 192.168.178.0 in Richtung VPN existieren (nur in Richtung LAN).

 

[Gerdchen03]

In der Server-Config muss ein "route 192.168.178.0 255.255.255.0"

server.conf hat nur noch den route-Befehl

vpnclient.conf auf der Fritzbox enthält weder route noch push "route..."

client # wir sind Client
dev tun #
dev-node /var/tmp/tun # Hier wird das Devide angegeben. wichtig!
proto udp # wir nutzen UDP, kein TCP
remote xxx.xxx.xxx.xxx 1194 # die IP/ DNS Name der Gegenseite und Port
resolv-retry infinite # Namensauflösung immer
nobind # wir brauchen den Port nicht zu binden.
persist-key
persist-tun
ca ./ca.crt # Die Zertifikate (Pfadangabe muss richtig sein)
cert ./FritzBox.crt
key ./FritzBox.key
dh ./xxxxx.pem
comp-lzo # Komprimierung, sofern auf der Gegenseite auch aktiv.
verb 1 # Fuer Debugging ruhig bis 8 hochsetzen.
mute 20 # Nach x Wiederholungen im Log ruhe.

Fritzbox:

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xxx.xxx.xxx.xxx *               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
10.8.0.29       *               255.255.255.255 UH    0      0        0 tun0
192.168.178.202 *               255.255.255.255 UH    2      0        0 dsl
192.168.178.203 *               255.255.255.255 UH    2      0        0 dsl
192.168.178.201 *               255.255.255.255 UH    2      0        0 dsl
192.168.178.0   *               255.255.255.0   U     0      0        0 lan
192.168.179.0   *               255.255.255.0   U     0      0        0 guest
83.xx.xx.0      *               255.255.255.0   U     0      0        0 dsl
10.8.0.0        10.8.0.29       255.255.255.0   UG    0      0        0 tun0
88.xx.xx.0      *               255.255.248.0   U     2      0        0 dsl
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
67.0.0.0        *               255.0.0.0       U     0      0        0 eth0
default         10.8.0.29       128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.8.0.29       128.0.0.0       UG    0      0        0 tun0
default         *               0.0.0.0         U     2      0        0 dsl

OpenVPN-Server:

root@v45838:/etc/openvpn# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         *               0.0.0.0         U     0      0        0 venet0

 

[MaxMuster]

Hm, sieht vom Routing her gut aus.
Zum 192-er Netz: Stimmt der Name der Datei im ccd auch ganz genau mit Client-Namen überein (wegen des iroute-Eintrags)?

Warum was "durch geht", aber Client und Server sich per ping nicht erreichen können kann ich mir nicht wirklich erklären (denn auf der FB z.B. wäre im VPN-Netz auch keine FW oder sowas, die das Ping unterbinden könnte).

 

[Gerdchen03]

Beide Dateinamen in ccd sind definitiv korrekt. Wenn ich die Datei, die für die Fritzbox zuständig ist, bewusst falsch nenne, kann ich mit meinem Rechner nicht mehr surfen. Die Datei von meinem smartphone habe ich auch überprüft. Im Logfile steht route 192.168.178.0 255.255.255.0 drin, was nicht der Fall ist, wenn die Datei fehlt.

Ich bin ja nur froh, dass ich nicht immer noch einen Anfängerfehler drin hab, auch wenn das mein Problem nicht lösen wird.

Von der Fritzbox aus und vom smartphone aus kann ich jetzt die 10.8.0.0-IPs und die 192er-IPs anpingen!! Weiß nicht, wieso das jetzt geht.
Nur der Server kann irgendwie nix gescheit anpingen, was mit der Fritzbox zu tun hat. Das smartphone kann er anpingen.

Das pingen vom smartphone auf den Receiver funktioniert zwar, aber sein Webinterface kann ich dennoch nicht öffnen

 

[MaxMuster]

Aber die iptables-Regeln mit NAT "in den Tunnel" sind auch gelöscht, oder (iptables -L -t nat) ?

 

[Gerdchen03]

folgende sind in der /etc/rc.local aktiv:

iptables -I FORWARD -i tun0 -j ACCEPT
iptables -I FORWARD -o tun0 -j ACCEPT
iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to xxx.xxx.xxx.xxx
iptables -t nat -A POSTROUTING -o venet0 -s 192.168.178.0/24 -j SNAT --to xxx.xxx.xxx.xxx

Sonst nichts

 

[MaxMuster]

Wenn sicher ist, dass die "alten", die vorher drin standen, nicht mehr aktiv sind, dann ist es ja gut.
Denn das rc-file dürfte nach meiner Vermutung ja nur beim Systemstart gezogen werden und so hat eine Änderung dort auch keinen Einfluß auf die aktuelle Konfiguration, sondern greift nur nach einem Neustart.