Freetz: OpenVPN-Client-Netzwerk im Server erreichbar machen

[dipsy]

Hallo MaxMuster,

ich hab mal meine Config rauskopiert,

#  OpenVPN 2.1 Config, Sun Nov 30 14:40:17 CET 2014
proto udp
dev tap1
dev-node /dev/tun
ca /tmp/flash/openvpn/server_ca.crt
cert /tmp/flash/openvpn/server_box.crt
key /tmp/flash/openvpn/server_box.key
dh /tmp/flash/openvpn/server_dh.pem
tls-server
tls-auth /tmp/flash/openvpn/server_static.key 0
port 1196
ifconfig 10.10.0.1 255.255.255.0
push "route-gateway 10.10.0.1"
push "route 192.168.11.0 255.255.255.0"
max-clients 5
mode server
ifconfig-pool 10.10.0.100 10.10.0.200
push "route 10.10.0.0 255.255.255.0"
client-config-dir clients_openvpn_server
route 192.168.178.0 255.255.255.0 10.10.0.10
route 192.168.10.0 255.255.255.0 10.10.0.11
client-to-client
tun-mtu 1500
mssfix
log /var/tmp/debug_openvpn_server.out
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
status /var/log/openvpn_server.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key

Die clients sind wie folgt


vpnclient01 vpn-ip 10.10.0.11 192.168.10.0 Subnet (fritzbox 7170 als client über Lan1 hinter einem Telecolumbusmodem welches eine DHCP-Anfrage benötigt)
vpnclient02 vpn-ip 10.10.0.10 192.168.178.0 Subnet (gefreetze W701V als client über Lan1 hinter meiner Fritte(192.168.4.0 Subnet)
vpnclient03 vpn-ip über DHCP mein Notebook über LTE-Hotspot (192.168.1.0 Subnet)

Der server läuft mit der vpn-ip 10.10.0.1 192.168.11.0 Subnet (7390 über T-Com mit VDSL)

ich dachte die config stimmt soweit.

greetz dipsy

 

[MaxMuster]

Der "interessante" Teil fehlt hier, das sind die eingetragenen Namen der Clients.

Ich versuche es nochmal ganz deutlich zu sagen: Der in der GUI eingetragene Name muss genau mit dem CN des Zertifikats übereinstimmen.
Und (laut dem Log) gibt es keinen Eintrag für "vpnclient03", sondern der Server nutz den "allgemeinen Pool" für Geräte ohne spezielle Konfig.

Mach doch bitte mal ein
"ls /tmp/openvpn/clients_openvpn_server" bzw schau, was
"cat /tmp/openvpn/clients_openvpn_server/vpnclient03" ergibt.

EDIT
Achwas, hab nicht richtig gelesen, das Netz 192.168.10.0 wird ja zur 10.10.0.11 geroutet, also zu vpnclient01. Der fehlte in deinem Log, da kann ich lange suchen.

Also neu: Wenn sich vpnclient01 verbindet, bekommt der korrekt die 10.10.0.11? Nur dann ist dessen LAN-IP 192.168.10.1 auch erreichbar...

 

[dipsy]

Hallo MaxMuster,

ich sehe zu, dass ich den vpnclient01 gestartet bekomme. rein von der örtlichkeit könnte das ein zwei Tage dauern. Mein Problem war und ist bis zum Schluß das ich bei einem Ping zu der 10.10.0.11 nicht weiter komme. Ich melde mich mit einem neuen debug-log.
Danke für deine Hilfe.

greetz dipsy

 

[MaxMuster]

Das gleiche sollte aber mit dem vpnclient02 und dem Netz dahinte (192.168.178.0/24) zu testen sein.
Geht ein Ping auf die LAN-IP bei diesem Client (vermutlich 192.168.178.1?!?)?

 

[dipsy]

Hallo MaxMuster,

nein der schlägt fehl, auch ein Tracert wird nicht beantwortet.

greetz dipsy

 

[MaxMuster]

Also, da gibt es zwei Möglichkeiten: Die Pakete kommen nicht vom Server zum Client oder der Client antwortet nicht. Aber nochmal zur Sicherheit:
Du testest aber von der Server-Fritzbox zur Client-FB und nicht von irgendeinem Geräte "dahinter" (nur weil tracert ein Windows-Befehl ist).
Also: Geht der Ping von der Server-Box auf die LAN-IP der Client-Box nicht? Oder geht es um Geräte "hinter" dem Server?

Wenn der Ping vom Server geht, ist der nächste Test, vom Server mit dessen LAN-IP auf die LAN-IP der Client-Box zu pingen

ping -I <LAN-IP des Servers> <LAN-IP der Client-Box>

 

[dipsy]

Hallo MaxMuster,

das funktioniert. Man bin ich blöd, hoffentlich bekomme ich den client01 morgen an.

ich meld mich zurück.

greetz dipsy

 

[MaxMuster]

Naja, das ist ja erst der erste Schritt. Wenn der Server mit seiner LAN-IP den Client mit dessen LAN-IP erreicht ist das Routing zwischen beiden schonmal o.k.
Dann müsste im nächsten Schritt der PC aus dem Server-LAN die Client-LAN-IP erreichen können. Geht das nicht, tippe ich auf Firewall-Einstellungen auf dem Gerät oder das Routing geht doch nicht auf den VPN-Server. Ein Trace aus Server-LAN ins Client-LAN sollte zumindest einen Hop (den VPN-Server) anzeigen...

 

[dipsy]

Hallo MaxMuster,

heute konnte ich nun endlich die Clientbox starten. Der Ping bis zur Lan Ip der Clientbox gelingt mir auch nur in das Netz dahinter komme ich nicht.
Ich hab mal die Config rauskopiert.

#  OpenVPN 2.1 Config, Tue Dec 16 21:23:40 CET 2014
proto udp
dev tap0
#Helperline for rc.openvpn to add tap0 to lan bridge
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
tls-client
ns-cert-type server
tls-auth /tmp/flash/openvpn/static.key 1
remote xxxxxxx.spdns.de 1196
nobind
pull
route 192.168.11.0 255.255.255.0
tun-mtu 1500
mssfix
verb 3
cipher AES-256-CBC
comp-lzo
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key[CODE]

Kannst du einen Fehler erkennen?.

 

[MaxMuster]

Wenn du bis ins LAN der Client-Box kommst, tippe ich auf das Routing dort oder auf eine Firewall am "Ziel" des Pings.

Wegen Routing: Diese Client-Box ist aber auch das Default-Gateway in diesem Netz?
Wenn du es "andersrum" versuchst, ein tracert aus dem Netz beim "vpnclient01" (also aus 192.168.10.x) ins Netz beim Server, dann kommt als erster Hop die IP der dortigen "Client-FB"?!?
Das müsste so sein, sonst stimmt das Routing nicht und "Antworten" aus diesem Netz kommen gar nicht zum VPN.

Zudem wird ein Windows-PC nicht unbedingt auf Anfragen aus "fremden Netzen" antworten, wenn dieses Netz nicht in der Firewall freigeschaltet wurde...

Einen "Fehler" sehe ich in der Config nicht, aber wenn du nicht unbedingt für eine Anwendung "Bridging" benötigst ("tap"), wäre ein Tunnel ("tun") die bessere Wahl für das VPN.

 

[dipsy]

Hallo MaxMuster,

ich habe auf tun umgestellt. Ein Ping von der Clientbox ins IP Netz des Servers ist auch erfolgreich. Bis zur Einführung von IPv6 des Kabelbetreibers war diese Clientbox ja der Server, da kam ich immer auf die Netzwerkgeräte.
Diese Clientbox ist mit Lan 1 am Kabelmodem im Router/NAT Betrieb mit DHCP(das ist nötig).
Leider komme ich schlecht an die Clientbox um aus dem Netzwerk ein Tracert abzusetzen, von der box selbst ist mir der befehl nicht bekannt ein "traceroute" kennt sie nicht. Langsam gehen mir die Ideen aus.

Edit: Hätte ich fast vergessen es sind keine Windowsrechner es sind Netzwerkplayer (Vitex).

greetz dipsy

 

[MaxMuster]

Diese Clientbox ist mit Lan 1 am Kabelmodem im Router/NAT Betrieb mit DHCP(das ist nötig).

Ist mir noch nicht 100% klar, in welcher Betriebsart, also wer DHCP macht: Hängt die Box an LAN1 mit der Einstellung "Verbindung selbst aufbauen" (Kabelmodem wirklich als "Modem") oder vielleicht doch mit "Verbindung mitbenutzen" (die Kabelbox ist also "Router" und damit das Default-Gateway im LAN)?
Nur im ersten Fall, wenn also die FB selbst als Router agiert und alle Geräte an der FB und deren DHCP hängen wird das so funktionieren. Dann "müssen" alle Rückpakete durch die FB und die sollte alles korrekt routen.

Im zweiten Fall müsste, soweit das überhaupt geht, auf dem Kabelrouter eine Route eingetragen werden für die Netze beim/hinter dem Server auf die LAN-IP der Fritzbox. Dann wäre eine "feste" IPder FB natürlich wichtig...

 

[dipsy]

Hallo MaxMuster,

das Kabelmodem ist ein dummer HF-Umsetzer, ohne ein Netzwerkgerät welches die dhcp Anfragen stellt würde es keinen Zentimeter ins Netz finden. Aus diesem Grund ist die Fritzbox auf dem Anschluss Lan1 als WAN eingestellt sie verhandelt mit dem dhcp Server des Kabelanbieters und setzt diese als Router ins LAN 192.168.10.x um. In dem LAN ist diese Fritte der Chef es gibt noch einen Windows PC der auch auf dhcp läuft, die zwei Vitex mit fester IP-Adresse und zeitweise meine Handy oder Notebook. Die Fritte nutzt den eigenen dhcp-Server ich habe Dnsmasq nicht aktiviert, dass wäre aber kein Problem.

greetz dipsy

 

[MaxMuster]

So weit so gut (oder auch "nicht gut").
Da du routingtechnisch vom Server-LAN bis in das Client-LAN kommst (LAN-IP der FB ist erreichbar), bleibt die Frage, warum es nicht weiter geht.
Könntest du vom Windows-PC dort einen trace in das Netz beim Server machen?
Wichtig ist, dass der erste Hop von dort aus die FB (der VPN-Client) ist.

 

[dipsy]

Hallo MaxMuster,

heute ist es mir gelungen. Der Tunnel steht und du hattest zu 100% Recht. Mein Problem bestand in den Geräten. Die zwei Vitex habe ich schlecht konfiguriert und damit konnten die eine Anfrage über den Tunnel nicht beantworten. Der Gateway fehlte.
Die Windows PCs waren alle über die Firewall geblockt. Nach einer Anständige Konfig läuft jetzt alles. Vielen Dank für die Hilfe.

greetz dipsy