Routing Probleme:Clients hinter Fitzbox durch OpenVPN an bestehenden Server leiten???

Nuke_off

Neuer User
Mitglied seit
31 Mrz 2009
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Hallo,

ich habe das grosse Problem das ich seit einer Woche versuche eine Fritzbox 7270 mit OpenVPN mit einem bestehenden OpenVPN Server zu verbinden, sodass die Rechner hinter der Fritzbox ins Netz des Servers zugreifen können. Die VPN Bridge steht soweit aber die Rechner werden einfach nicht ins Servernetz geleitet. Ping von der Fritzbox auf Rechner im Servernetz und umgekehrt funktioniert.

Ip des Heimnetzes(Fritzbox): 192.168.10.1
Rechner des Heimnetzes: 192.168.10.2-254

Ip des Servernetzes(OpenVPN Server): 192.168.0.5
Rechner des Servernetzes: 192.168.0.11 z.B.

Ip des Tap Devices : 192.168.0.91


Meine Client Config:

Code:
#  OpenVPN 2.1 Config, Sat Jan  1 01:00:48 CET 2000
proto udp
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
tls-client
tls-auth /tmp/flash/static.key 1
remote xxx.xxx.xxx.xx
nobind
route 192.168.0.0 255.255.255.0
ifconfig 192.168.0.91 255.255.255.0
tun-mtu 1500
mssfix
fragment 1300
log /var/tmp/debug_openvpn.out
verb 4
daemon
cipher BF-CBC
keepalive 10 120
resolv-retry infinite
status /var/log/openvpn.log
client
persist-key
persist-tun

Routingtabelle:

Code:
192.168.180.1   *               255.255.255.255 UH    2      0        0 dsl
89.15.83.121    *               255.255.255.255 UH    2      0        0 dsl
192.168.180.2   *               255.255.255.255 UH    2      0        0 dsl
192.168.0.0     *               255.255.255.0   U     0      0        0 tap0
192.168.10.0    *               255.255.255.0   U     0      0        0 lan
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

Debug Output:

Code:
Thu Apr  9 21:26:14 2009 us=743077 OpenVPN 2.1_rc13 mipsel-linux [SSL] [LZO2] [EPOLL] built on Apr  6 2009
Thu Apr  9 21:26:14 2009 us=744153 WARNING: using --pull/--client and --ifconfig together is probably not what you want
Thu Apr  9 21:26:14 2009 us=744465 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm f
Thu Apr  9 21:26:14 2009 us=750415 WARNING: file '/tmp/flash/box.key' is group or others accessible
Thu Apr  9 21:26:14 2009 us=760087 Control Channel Authentication: using '/tmp/flash/static.key' as a OpenVPN static key file
Thu Apr  9 21:26:14 2009 us=760525 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Apr  9 21:26:14 2009 us=760857 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Apr  9 21:26:14 2009 us=763083 Control Channel MTU parms [ L:1577 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Apr  9 21:26:14 2009 us=765389 Data Channel MTU parms [ L:1577 D:1300 EF:45 EB:4 ET:32 EL:0 ]
Thu Apr  9 21:26:14 2009 us=765722 Fragmentation MTU parms [ L:1577 D:1300 EF:45 EB:4 ET:32 EL:0 ]
Thu Apr  9 21:26:14 2009 us=770043 Socket Buffers: R=[108544->131072] S=[108544->131072]
Thu Apr  9 21:26:14 2009 us=771016 UDPv4 link local: [undef]
Thu Apr  9 21:26:14 2009 us=771382 UDPv4 link remote: XXX.XXX.XXX.XX:1194
Thu Apr  9 21:26:14 2009 us=861205 TLS: Initial packet from XXX.XXX.XXX.XX:1194, sid=7ccfc3e8 5fe5195c
Thu Apr  9 21:26:15 2009 us=741123 VERIFY OK: depth=1, /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Thu Apr  9 21:26:15 2009 us=746408 VERIFY OK: depth=0, /XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Thu Apr  9 21:26:17 2009 us=111458 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Apr  9 21:26:17 2009 us=111820 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Apr  9 21:26:17 2009 us=112751 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Thu Apr  9 21:26:17 2009 us=113089 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Apr  9 21:26:17 2009 us=114629 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Apr  9 21:26:17 2009 us=115113 [server] Peer Connection Initiated with XXX.XXX.XXX.XX:1194
Thu Apr  9 21:26:18 2009 us=145000 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Apr  9 21:26:18 2009 us=229647 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.0.5,ping 10,ping-restart 120,ifconfig 192.168.0.92 255.255.255.0'
Thu Apr  9 21:26:18 2009 us=230279 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr  9 21:26:18 2009 us=230539 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr  9 21:26:18 2009 us=230734 OPTIONS IMPORT: route-related options modified
Thu Apr  9 21:26:18 2009 us=241573 TUN/TAP device tap0 opened
Thu Apr  9 21:26:18 2009 us=242230 TUN/TAP TX queue length set to 100
Thu Apr  9 21:26:18 2009 us=242760 /sbin/ifconfig tap0 192.168.0.92 netmask 255.255.255.0 mtu 1500 broadcast 192.168.0.255
Thu Apr  9 21:26:18 2009 us=265417 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.5
Thu Apr  9 21:26:18 2009 us=274162 Initialization Sequence Completed


Server Config kann ich leider im Moment nicht posten da ich keinen Zugriff darauf habe. Nach Ostern sollte das aber auch möglich sein.

Hoffe jemand kann mir helfen, bin mit meinem Latein am Ende :)

Viel Dank schon mal im Vorraus und frohe Ostern ;)
 
Zuletzt bearbeitet:
Moin,

ist im Servernetz die Route für dein LAN (192.168.10.0 255.255.255.0) auf die IP des VPN-CLients ( 192.168.0.91) gesetzt?
Sonst ist vermutlich deine Vermutung falsch ;): Es wird natürlich alles brav "ins Servernetz geleitet", aber dort kennt man nicht den Rückweg zu deinem Netz.
Du musst immer bedenken, das nur der Client direkt mit dem Servernetz verbunden ist und dort eine IP hat, alle anderen PC's nutzen ihre "normale" IP.
Wenn das nicht auf dem Deafultgateway im Servernetz möglich ist musst du ggf. auf den PC's im Servernetz eine Route eintragen.


Jörg
 
Vielen Dank für die schnellen Antworten, echt ein super Forum hier :)


Max, dein Vorschlag hat auf Anhieb funktioniert. Hab die route per Hand auf einen der Rechner im Servernetz eingetragen und dann ging es.


Schöne Feiertage euch beiden ;)
 
OpenVPN + NAT

Also das mit der Route eintragen hat ja schon mal funktioniert nur habe ich mich gefragt ob es nich eine elegantere Lösung gibt ohne auf dem Server jedesmal eine Route für die Subnetze eintragen zu müssen. Mit NAT z.B wäre es doch bestimmt möglich das alles Clientseitig geregelt wird so das beim Server nur noch die IP der Fritzbox erscheint und die wird ja schon korrekt geroutet. Muss man dazu zwangsläufig Iptables auf der Fritzbox haben oder geht das auch mit dem vorhandenen NAT der Fritzbox?

Hat da jemand Erfahrung mit ?

Vielen Dank schon mal im vorraus :)
 
Mit dem Paketfilter der Fritz!Box wird da wohl nix zu machen sein und ich vermute du wirst um ein Mapping via SNAT nicht herumkommen. Ob das aber elleganter ist als eine Route auf dem Gateway des Servernetzes?
 
Naja bin mir auch nich so sicher ob das wirklich eleganter ist, aber zumindest ist es bei Änderungen der Clientnetze oder neuen unbekannten Clients unkomplizierter. Man müsste ja nicht jedesmal eine neue Route für jedes Clientnetz eintragen. Mein Problem ist halt das ich gar nicht oder nur über den Serveradmin Änderungen an den Routen vornehmen kann.

Werde mal versuchen iptables zu konfigurieren.
 
Okay habe iptables konfiguriert. läuft einwandfrei.

habe diese Zeilen in die debug.cfg eingetragen:

Code:
modprobe ip_tables
modprobe iptable_nat
modprobe iptable_filter
modprobe ipt_MASQUERADE
iptables -t nat -A POSTROUTING -o tap0 -s 192.168.10.0/24 -j MASQUERADE

Internetverkehr läuft nach wie vor übers dsl device und die clients werden auch ins VPN geleitet bei Anfragen auf den 192.168.10.0er Bereich.

Hoffe das hilft allen weiter die das gleiche Problem haben. ;)
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
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.