OpenVPN auf FBF als Client / Probleme hinter FB

bags

Neuer User
Mitglied seit
18 Nov 2006
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen.

Ich habe auf meiner FBF 7170 (FW: 29.04.49) erfolgreich OpenVPN installiert. Hiermit möchte ich mich als Client zu unserem Firmenserver verbinden. Die Box soll keinen VPN Server bereitstellen.

So weit so gut. Habe so ziemlich alles befolgt. (hoffe ich).
  • openvpn installiert
  • virtual ip installiert (192.168.178.253)
  • in der FB den Port 1194 auf die o. a. IP geforwardet
  • und noch die brücke auf tap0 geschlagen
Die Box verbindet sich auch erfolgreich mit dem Firmenserver. Das tap0 Device erhält erfolgreich eine IP-Adresse und auch die die virtuelle Netzwerkkarte ist in ifconfig zu sehen.

Allerdings kann ich nur von der Box aus die Server im Firmenlan anpingen. Und auch das nur mit der IP-Adresse. Probiere anstatt der IP-Adresse den Namen eine Servers anzupingen, kommt gleich die Meldung "unknown Host".

Vom WindowsPC der hinter meiner FB steckt, kann ich gar keinen Server im Firmenlan anpingen. Weder mit IP noch mit dem Namen.

Ausschnitt meiner debug.cfg:

Code:
mknod /var/tmp/tun c 10 200
cd /var/tmp
mkdir vpn
cd vpn
wget -P ./ [URL]http://192.168.0.101/openvpn/openvpn[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/brctl[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/ca.crt[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/peter.crt[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/peter.key[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/ta.key[/URL]
wget -P ./ [URL]http://192.168.0.101/openvpn/muk.ovpn[/URL]
chmod 0600 ./*
chmod +x ./openvpn
chmod +x ./brctl
./openvpn --config ./muk.ovpn
sleep 30
ifconfig tap0 0.0.0.0 promisc up
./brctl addif lan tap0
# write 'secret.key' to file
cat > /var/tmp/vpn/ca.crt << 'ENDSECRETKEY'
cat > /var/tmp/vpn/peter.crt << 'ENDSECRETKEY'
cat > /var/tmp/vpn/peter.key << 'ENDSECRETKEY'
cat > /var/tmp/vpn/ta.key << 'ENDSECRETKEY'
ENDSECRETKEY
# write 'server.ovpn' to file
cat > /var/tmp/vpn/muk.ovpn << 'ENDSERVERCONF'
ENDSERVERCONF
# make FBF accessable from the internet (192.168.178.253)
sleep 10
ifconfig eth0:1 192.168.178.253 netmask 255.255.255.0 broadcast 192.168.178.255 up
# start OpenVPN
/var/tmp/vpn/openvpn --config /var/tmp/vpn/muk.ovpn
# Bridging
/var/tmp/vpn/brctl addif lan tap0

Hier mal die client.conf:
Code:
daemon
client
proto udp
local 192.168.178.253
remote *.*.*.* 1194
ns-cert-type server
dev tap0
dev-node /var/tmp/tun
resolv-retry infinite
#nobind
remote-random
persist-key
persist-tun
ca /var/tmp/vpn/ca.crt
cert /var/tmp/vpn/peter.crt
key /var/tmp/vpn/peter.key
tls-auth /var/tmp/vpn/ta.key 1
comp-lzo
verb 3

Und hier noch die Routintabelle der FB nach dem erfolgreichen verbinden:
Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
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
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0
192.168.0.0     *               255.255.255.0   U     0      0        0 lan
10.17.7.0       *               255.255.255.0   U     0      0        0 tap0
10.5.0.0        10.17.7.230     255.255.0.0     UG    0      0        0 tap0
169.254.0.0     *               255.255.0.0     U     0      0        0 lan
default         *               0.0.0.0         U     2      0        0 dsl

Bisher machte ich das ganze ohne Probleme mit dem OpenVPN Client für Windows.
 
Hi,

erstmal: du hast schon mehr getan, als notwendig (für den Client brauchst du keine Portweiterleitung).

Dein eines "Problem" ist, dass nur die Box mit dem Server verbunden ist, d.h. dein PC "weiss" erstmal nichts davon (das war anders, als der PC verbunden war). Der PC ist in einem anderen IP Netz, daher kann er zwar theoretisch über den Weg zur Box und das VPN ins Firmennetz, das Netz dort aber vermutlich dein "Heimnetz" nicht kennt, und daher nicht "antworten" kann. Wenn das gehen sollte, müsste der IP im gleichen (gebrückten) IP-Netz sein, wie die Box.

Irgendwie fehlt mir auch was in deiner Config, z.B. woher die Box ihre IP für das TAP bezieht? Oder hast du das "ausgeblendet"?

Jörg
 
Hallo Jörg.

Erstmal danke für Deine Antwort. Das Portforwarding nehme ich dann wieder raus.

Was meinst Du genau "wo die Box Ihre IP für das TAP herbezieht"? Falls Du den Firmenserver meinst (remote *.*.*.* 1194), dann muss ich Deine Frage bejahen, was das Ausblenden der IP betrifft.

Hab ich das jetzt mit der Brücke nicht richtig gemacht? -->

# Bridging
/var/tmp/vpn/brctl addif lan tap0

Meines erachtens wird doch hier eine Brücke zwischen dem VPN (TAP) und meiner Box hergestellt... Oder nicht.

Welche IP müsste im gleichen Bereich sein wie die Box? Die vom PC?!?

Wie gesagt, bisher läuft das ganze Problemlos mit OpenVPN für Windows. Dort ist ja auch der TAP32 Adapter der eine Brücke auf meine Netzwerkkarte schlägt.

So in der Art sollte das doch auch auf der Box ablaufen oder?!? Jedenfalls bekommt das TAP Device in der Box genau die IP-Adresse, die ich auch sonst mit dem WIN OpenVPN Client bekomme.

Ich hoffe Du kannst mir da noch ein bisl genauer helfen...

Gruß Peter
 
Hallo Peter,

In deinen Infos sind Routen über das TAP eingetragen. Dein TAP hat momentan lt. der Config aber die IP "0.0.0.0".
Im Gegensatz zu einem PC, der standardmäßig auf einem Interface versucht, per DHCP eine IP zu bekommen macht das die Box nicht, das würde aber (ebenso wie das Übernehmen des Routings vom Server) z.B. ein "pull" in der Config machen, was ich aber nicht gesehen habe, deshalb die Frage nach der IP.

Die Brücke ist so o.k., aber die internen Geräte (alos deine PCs im LAN) müssen daran dann auch "teilnehmen", indem sie auch z.B. "über die Brücke" eine IP beziehen oder so eine zulässige IP aus dem gebrückten Netz bekommen.

Muss jetzt leider weg...

Jörg
 
So... Ich hab das "pull" jetzt mal in der client config integriert und folgendes aus der debug.cfg entfernt:
Code:
ifconfig tap0 0.0.0.0 promisc up

Das scheint bei meiner Art des VPN Verbindunsaufbaus da eh nicht hinzugehören. Ich hätte Dir noch den Auszug aus der ifconfig schicken sollen. Das tap0 hatte zwar laut debug.cfg die IP 0.0.0.0 allerdings nach dem Starten des OVPN Client hat es eine reguläre IP aus dem Adresspool der Firma bekommen.
Code:
tap0      Link encap:Ethernet  HWaddr B6:B8:7D:75:D7:09
          inet addr:10.17.7.232  Bcast:10.17.7.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:262 errors:0 dropped:0 overruns:0 frame:0
          TX packets:236 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:21131 (20.6 KiB)  TX bytes:54309 (53.0 KiB)

Ergebnis bleibt eigentlich gleich. Nach dem Starten vom ovpn Client erhält das tap0 erfolgreich seine IP. Dann schlage ich noch die Brücke.

Korrektur zum ersten Post von mir: Ich kann gar kein Ping mehr zum Firmenlan absetzen. Ausser auf die IP-Adresse des tap0 der FB.

Was ist nu kaputt?!? Liegt das daran, dass ich das PortFW von Port 1194 entfernt habe?!?

Hier mal die Ausgabe vom ovpn client während des Verbindungsaufbaus:
Code:
# /var/tmp/vpn/openvpn --config /var/tmp/vpn/muk.ovpn
Tue Mar 25 14:32:25 2008 OpenVPN 2.1_rc1 mipsel-linux [SSL] [LZO2] [EPOLL] built on Jan  5 2007
Tue Mar 25 14:32:27 2008 Control Channel Authentication: using '/var/tmp/vpn/ta.key' as a OpenVPN static key file
Tue Mar 25 14:32:27 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 25 14:32:27 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 25 14:32:27 2008 LZO compression initialized
Tue Mar 25 14:32:27 2008 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue Mar 25 14:32:27 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Mar 25 14:32:27 2008 Local Options hash (VER=V4): 'bbb'
Tue Mar 25 14:32:27 2008 Expected Remote Options hash (VER=V4): 'zzz'
Tue Mar 25 14:32:27 2008 Socket Buffers: R=[110592->131072] S=[110592->131072]
Tue Mar 25 14:32:27 2008 UDPv4 link local (bound): 192.168.178.253:1194
Tue Mar 25 14:32:27 2008 UDPv4 link remote: x.x.x.x:1194
Tue Mar 25 14:32:27 2008 TLS: Initial packet from x.x.x.x:1194, sid=ae683070 e6201206
Tue Mar 25 14:32:28 2008 VERIFY OK: depth=1, /C=DE/ST=xxx/L=xxx/O=xxx/CN=xxx/emailAddress=xxx
Tue Mar 25 14:32:28 2008 VERIFY OK: nsCertType=SERVER
Tue Mar 25 14:32:28 2008 VERIFY OK: depth=0, /C=DE/ST=xx/L=xxx/O=xxx/CN=xxx/emailAddress=xxx
Tue Mar 25 14:32:30 2008 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 25 14:32:30 2008 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 25 14:32:30 2008 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Mar 25 14:32:30 2008 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Mar 25 14:32:30 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Mar 25 14:32:30 2008 [xyz] Peer Connection Initiated with x.x.x.x:1194
Tue Mar 25 14:32:31 2008 SENT CONTROL [xyz]: 'PUSH_REQUEST' (status=1)
Tue Mar 25 14:32:31 2008 PUSH: Received control message: 'PUSH_REPLY,route 10.5.0.0 255.255.0.0,dhcp-option DOMAIN xyz.xyz.de,dhcp-option DNS 10.17.7.33,dhcp-option WINS 10.17.7.40,route-gateway 10.17.7.230,ping 10,ping-restart 120,ifconfig 10.17.7.232 255.255.255.0'
Tue Mar 25 14:32:31 2008 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar 25 14:32:31 2008 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar 25 14:32:31 2008 OPTIONS IMPORT: route options modified
Tue Mar 25 14:32:31 2008 OPTIONS IMPORT: route-related options modified
Tue Mar 25 14:32:31 2008 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Tue Mar 25 14:32:31 2008 TUN/TAP device tap0 opened
Tue Mar 25 14:32:31 2008 TUN/TAP TX queue length set to 100
Tue Mar 25 14:32:31 2008 /sbin/ifconfig tap0 10.17.7.232 netmask 255.255.255.0 mtu 1500 broadcast 10.17.7.255
Tue Mar 25 14:32:31 2008 /sbin/route add -net 10.5.0.0 netmask 255.255.0.0 gw 10.17.7.230
Tue Mar 25 14:32:31 2008 Initialization Sequence Completed
 
Ansich sieht das ganz o.k. aus, du bekommst IP und Routen vom Server, soweit so gut. Eigentlich sollte als erstes mal der Ping von der Box auf das Gateway (10.17.7.230) klappen, lt. deinem "ifconfig" geht ja auch Traffic über das VPN?!? Zählen denn RX und TX vom TAP hoch?

Das Forwarding sollte beim Client nicht nötig sein, eigentlich braucht der Client nicht auf einem Port zu lauschen (das muss nur der Server), das "nobind" in der Client-Config würde das so einstellen.

Kannst du mal (sofern deine Box den Befehl kann) mit einem einen "arp -a" auf der Box nachsehen, ob sie andere IPs auf dem TAP sieht?

Jörg
 
So... komischer Weise geht das pingen jetzt eingeschränkt wieder...

Und zwar kann ich nicht das Gateway (10.17.7.230) anpingen. Aber die einzelnen Clients bzw. Server. Von denen weiß ich die IP so aus dem Kopf.

Trotzdem hier mal die Ausgabe von busybox arping (arp ist leider nicht drauf):
Code:
# /var/tmp/busybox arping -A 10.17.7.230
arping: bind

nur mal zur Info die Routintabelle unter Windows wenn ich mich mit WIN Ovpn Client verbinde:
Code:
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.0.1   192.168.0.100       20
         10.5.0.0      255.255.0.0      10.17.7.230     10.17.7.232       1
        10.17.7.0    255.255.255.0      10.17.7.232     10.17.7.232       30
      10.17.7.232  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255      10.17.7.232     10.17.7.232       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      169.254.0.0      255.255.0.0     192.168.20.1    192.168.20.1       30
      192.168.0.0    255.255.255.0    192.168.0.100   192.168.0.100       20
    192.168.0.100  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.0.255  255.255.255.255    192.168.0.100   192.168.0.100       20
     192.168.20.0    255.255.255.0     192.168.20.1    192.168.20.1       20
     192.168.20.1  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.20.255  255.255.255.255     192.168.20.1    192.168.20.1       20
    192.168.229.0    255.255.255.0    192.168.229.1   192.168.229.1       20
    192.168.229.1  255.255.255.255        127.0.0.1       127.0.0.1       20
  192.168.229.255  255.255.255.255    192.168.229.1   192.168.229.1       20
        224.0.0.0        240.0.0.0      10.17.7.232     10.17.7.232       30
        224.0.0.0        240.0.0.0    192.168.0.100   192.168.0.100       20
        224.0.0.0        240.0.0.0     192.168.20.1    192.168.20.1       20
        224.0.0.0        240.0.0.0    192.168.229.1   192.168.229.1       20
  255.255.255.255  255.255.255.255      10.17.7.232     10.17.7.232       1
  255.255.255.255  255.255.255.255      10.17.7.232               5       1
  255.255.255.255  255.255.255.255    192.168.0.100   192.168.0.100       1
  255.255.255.255  255.255.255.255     192.168.20.1    192.168.20.1       1
  255.255.255.255  255.255.255.255    192.168.229.1   192.168.229.1       1
Standardgateway:       192.168.0.1
===========================================================================
 
Eine mögliche Erklärung dafür könnte sein, dass du dich in kurzer Zeit mehrfach verbunden hast, einmal per PC, einmal per Box. Die jeweiligen "MAC-Adressen" werden wohl verschieden sein, wenn ein Gerät noch die andere Adresse in ARP-Cache hat, könnte genau das auftreten, dass du einige Geräte nicht erreichen kannst (das sollte sich aber nach ein paar Minuten geben).

Wenn du nun aber vom PC über die Box in das Netz willst, fehlt dir noch immer was: Es sind zwar, wenn die Brücke steht, PC und Firmennetz quasi "direkt verbunden", aber in verschiedenen IP-Netzen. Du müsstest für den PC auch eine IP aus dem "Brücken-Netz" haben, die sich nicht mit den anderen Geräten überschneidet. Vielleicht gibt es dort in dem Netz einen DHCP-Server (damit würdest du aber ggf den "lokalen" Zugriff abschießen und nur noch "über die Firma" arbeiten können)??

Jörg
 
So... Hab mal mit meinem Linux-Admin Oberguru gequatscht.

Der sagte mir. Man müsste das mit NAT lösen. Also irgendwie NAT für das tap0 realisieren. Dann würde das klappen.

Dazu müßte ich dann aber irgendwie in der FW der FB rumfummeln. Kein Plan wie das gehen soll, dass ich in den Regeln etwas für ein Device (tap0)definiere, was beim Start der Box ja noch nicht geladen ist.

Gibt es ein FW Paket für die Box, dass man nachladen kann sobald das tap0 steht und dort dann NAT einstellt?!?
 
Hi,

für die Box ginge das nicht mit "Bordmitteln" sondern mit "iptables". Ich weiß nicht, ob es das auch zum "Nachladen" gibt, zudem ist das nicht gerade das Einfachste in der Konfiguration. Außerdem gibt es mit den neueren Kernels auch noch Probleme mit iptables (gab es zumindest)...

Ohne freetz (also eine selbstgebaute Firmware) sehe ich da leider keine Möglichkeiten.

Jörg
 
Kostenlos!

Statistik des Forums

Themen
248,926
Beiträge
2,305,432
Mitglieder
378,654
Neuestes Mitglied
najsai