Openvpn- Route von Server Fritzbox ins LAN Client Windows klappt nicht

boesi666

Neuer User
Mitglied seit
13 Jun 2007
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

versuche nun sein mehreren Wochen bereits ein Routing in das Client Netz herzustellen... trotz unzähliger Versuche bisher ohne Erfolg.

Habt ihr Tipps?
Meine Konfigs:

Server Fritzbox, Client Windows XP mit bereits in der Registry freigeschalteten IPForwarding und deaktivierter Firewall.

LAN IP FritzBox:192.168.0.100
VPN IP Fritzbox 10.0.0.2

LAN IP Openvpn WinXP Client: 172.x.x.100
VPN IP Openvpn WinXP Client: 10.0.0.1

Was geht bisher: pings vom client ins komplette LAN des Fritzbox Servers
Was nicht geht: pings vom client ins komplette LAN des WinXP Client. Es geht von Fritzbox nur die vpn ip des client und (immerhin) die lokale LAN IP des Client, aber nicht die Rechner hinter des Client.

Mit Netzwerkbrückenkonfiguration würde das zwar gehen, ist aber nicht erwünscht, da bei dieser Lösung alle rechner im gleichen netz sein müssten.

meine Server.conf auf fritzbox:

# OpenVPN 2.1 Config
proto tcp-server
port 1194
dev tun
secret /tmp/flash/static.key
ifconfig 10.0.0.2 10.0.0.1
route 10.0.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.100"
push "dhcp-option DNS 192.168.0.100"
push "redirect-gateway"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher BF-CBC
route 172.x.0.0 255.255.0.0
comp-lzo
keepalive 10 120
status /var/log/openvpn.log

meine client.conf auf winxp client:

ifconfig 10.0.0.1 10.0.0.2
remote blubb.dyndns.org# (Internet-)Adresse der Fritz!Box eintragen
secret secret.key # Pfad zur 'secret.key' angeben ('\' muss als '\\' geschrieben werden!)
#dev tun0
dev tun
proto tcp-client
port 1194
ping 15
ping-restart 300 # 5 minutes
resolv-retry 300 # 5 minutes
#resolv-retry infinite
tun-mtu 1500
mssfix
persist-tun
persist-key
verb 4
route 10.0.0.0 255.255.255.0
push "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.2"
route-gateway 10.0.0.2

comp-lzo
# Einschalten der Komprimierung

redirect-gateway
#redirect-gateway -> alles über vpn tunnel umleiten

route 192.168.0.0 255.255.255.0 10.0.0.2
 
Also, du möchtest vom Netz hinter dem Openvpn-Server (aus dem Netz 192.168.0.0) in das Netz hinter dem Client (172.x.0.0)?
Dann müssen natürlich alle Geräte im "Client-LAN" auch wissen, dass sie das "Server-LAN" über deinen Client routen müssen.
Am einfachsten wäre das durch eine Route auf dem Defaultgateway in dem Client-LAN zu erledigen, die auf den Client zeigt.

Wenns das nicht ist, auf jeden Fall bitte die Routingtabellen von beiden Seiten posten.

Jörg
 
Danke für den Tipp!! Tatsache, es hat geholfen den Gateway zu setzen und nun ist jeder Client welcher den gateway auf den Windows VPN Server gesetzt hat dann auch aus dem entfernten vpn netz zu erreichen.

Ganz erklären kann ich mir das aber nicht. Damit eine anfrage vom client rechner ins entferne netz heraus gehen kann ist das setzen des gateways ja mir logisch.

aber eingehende anfragen sind mir nicht klar. wenn die lokale IP Adresse meines windows vpn server im gleichen bereich wie ein dahinter angeschlossener client ist, sind die beiden doch im gleichen netz. warum muss der client dann noch den gateway explizit auf den winvpnserver gesetzt haben für EINGEHENDE anfragen?

aber es wird schon so sein. und wenn ich mir so recht überlege, im entfernten netzt wo der vpnserver auf der fritzbox ist haben die dahinterliegenden rechner ja auch den gateway auf die fritzbox..
 
Du brauchst diese Route für die Antwort-Pakete. Denn die Geräte in deinem Client-LAN müssen ja auch antworten können.
Die Antwort-Pakete sollen dann in das "Server-Netz" (192.168.0.x) gehen. Das ist den Geräten im Client-Netz aber ja nicht bekannt, und sie schicken es zu ihrem Default-Gateway. Wenn das (wie in deinem Fall) ungleich dem VPN-Client ist, kennt der das Netz nicht und wird es (weil privat) verwerfen oder ins Internet routen, was aber beides falsch ist ;-)
Daher müssen die Rechner im Client-Netz über das Netz slebst Bescheid wissen, oder aber das Defaultgateway muss die Route kennen.
Wie du schon richtig erkannt hast: Für dein Servernetz ist das schon gegeben, weil Defaultgateway = VPN Endpunkt.

Jörg
 
super erklärung!! Mit den Antwort-Paketen das klingt logisch und das Ganze hat mir riesig geholfen!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.