einige Fragen zur OpenVPN-Konfiguration

[blacksun]

Hallo,

ich habe mir mit Freetz ein Image für meine Eumex 300 gebastelt. Im Image ist auch OpenVPN 2.1_RC07 mit dabei.

Ich habe mir folgendes durchgelesen:
http://wiki.ip-phone-forum.de/software:ds-mod:pakete:openvpn
http://wiki.ip-phone-forum.de/gateways:avm:howtos:mods:openvpn?s=openvpn

Das besondere bei mir ist, dass die Eumex mit dem OpenVPN darauf als IP-Client in meinem privaten Netzwerk daheim hängt. Die Verbindung in's Inet übernimmt eine FBF 7050.

Um der Frage gleich vorwegzugreifen, warum ich Zertifikate verwende anstatt nur den Static Key: In allen Anleitungen steht, wenn mehrere Clients gleichzeitig auf den OpenVPN-Server zugreifen wollen, dann ginge das nur mit Zertifikaten.

Mein Ziel: Der OpenVPN-Server auf der Eumex soll dazu dienen, wenn ich unterwegs mit meinem Laptop mit an einem Hotspot bin, dass sich der Laptop dann so verhält, als wäre er daheim in meinem privaten WLAN. Sprich der gesamte Netzwerkverkehr (Surfen, Emails, VoiP, auf Netzwerkfreigaben der PCs daheim zugreifen), der von meinem Laptop weg geht oder her kommt, soll über VPN laufen.
Wie ich sagte, es soll unterwegs alles so funktionieren, als wenn ich daheim im privaten LAN wäre.
Ganz wichtig: Am Laptop soll man möglichst wenig konfigurieren müssen. Sprich möglichst viel der Konfiguration soll vom Server kommen. Grund: ich bin öfters mit verschiedenen Laptops an Hotspots, da möchte ich mich nicht jedesmal die Konfiguration am Laptop neu einstellen müssen. Sprich: Verbindungsaufbau mit Hotspot, USB-Stick rein, von dort OpenVPN-Client installiert, die Zertifikate sind auch auf dem Stick, Client-Config-File öffnen, und dann hat der Laptop eine private ip-Adresse von daheim und alles läuft über den heimischen Inetzugang.

Allerdings habe ich noch einige Fragen.

1. Wo finde ich die Konfig-Datei für den OpenVPN-Server auf der FBF (Eumex) genau? Ist das die /var/mod/etc/openvpn.conf ?

2. Um mein oben geschildertes Ziel zu erreichen, muss ich doch Bridging machen, so wie es hier http://wiki.ip-phone-forum.de/software:ds-mod:pakete:openvpn unter "Routing vs. Bridging" beschrieben ist, oder?

Meine /var/mod/etc/openvpn.conf sieht so aus:

#  OpenVPN 2.1 Config, Tue May 20 04:11:31 CEST 2008
proto udp
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
dh /tmp/flash/dh.pem
tls-server
tls-auth /tmp/flash/static.key 0
port 1194
push "redirect-gateway"
ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
push "route 192.168.0.0 255.255.255.0"
max-clients 4
tun-mtu 1500
mssfix
verb 3
daemon
cipher BF-CBC
comp-lzo
float
keepalive 10 120

Zu dem Server-Konfig-File habe ich diese Fragen:

was macht der Eintrag "tls-server" genau?
Brauche ich auf der Eumex eigentlich DHCP? Weil eigentlich ist der DHCP-Server meine FBF7050, die auch die Verbindung in Inet aufbaut

Zu dem Client-Konfig-File (es ist das Muster aus der Anleitung)

client
dev tap
#udp/tcp je nachdem, was ausgewählt wurde
proto ucp
#Port entsprechend der Konfiguration
remote meinserver.dyndns.org 443
nobind
persist-key
persist-tun
#hier die Zertifikate/Schlüssel, wie beim Erstellen benannt
ca ca.crt
cert client01.crt
key client01.key
# für TLS-Remote "ServerBox1" wie beim Erstellen benannt
tls-remote ServerBox1
tls-auth static.key 1
auth SHA1
cipher AES-256-CBC
comp-lzo
verb 3

habe ich noch folgende Fragen:
- Was bedeutet "persist-key"?
- Was bedeutet "persist-tun"?
- Ist das in dem Muster zufällig der Port für https (=443)?
- Was muss ich denn für den Platzhalter "ServerBox1" genau sagen? Die ip-Adresse (192.168.x.x) der eumex? Den DynDNS-Namen?

Ich hoffe Ihr könnt mir helfen.
Vielen Dank schonmal

 

[MaxMuster]

Dieses Beispiel dort ist m.E. etwas unglücklich, weil nicht die Standard-Ports (1194) genutzt wurden. Es ist aber schon "stimmig": Der Server nutzt als Port 443, der Client verbindet sich drauf. Das wäre z.B. dann eine Möglichkeit, wenn der Client in einem eingeschränkten Netz ist, das nur Port 443 freigeschaltet hat.

1. Ja, /var/mod/etc/openvpn.conf ist die erzeugte Config der Box
2. Wenn du tatsächlich "Teil" deines Hom-Netzes sein möchtest ist TAP richtig.

TLS ist ein "Sicherheitsprotokoll", und "tls-server" und "tls-client" legen die Rolle innerhalb des TLS-Handshake fest.
Wenn die Gegenstelle auf dem virtuellen OpenVPN-Interface "DHCP" macht (z.B. mit einem Windows Client), dann kann der Client über das TAP den vorhandenen DHCP-Server nutzen.

Die "persist" Befehle sagen, dass bei einem Abbau bzw erneuten Aufbau der Verbindung die Parameter (keys) nicht neu eingelesen werden bzw. das TUN/TAP Interface bestehen bleibt.

Wenn du wirklich die zusätzliche tls-Authentifizierung nutzen willst, dann gibst du mit tls-remote den "Zertifikats-Namen" der Gegenstelle an, also den Namen, den du bei der Zertifikatserstellung angegeben hast.

Vielleicht solltest du dir mal die Seite OpenVPN.net ansehen, dort sind sehr viele Beispiele und jeder möglich Parameter erklärt.

Jörg

 

[blacksun]

TLS ist ein "Sicherheitsprotokoll", und "tls-server" und "tls-client" legen die Rolle innerhalb des TLS-Handshake fest.
Wenn die Gegenstelle auf dem virtuellen OpenVPN-Interface "DHCP" macht (z.B. mit einem Windows Client), dann kann der Client über das TAP den vorhandenen DHCP-Server nutzen.

Die "persist" Befehle sagen, dass bei einem Abbau bzw erneuten Aufbau der Verbindung die Parameter (keys) nicht neu eingelesen werden bzw. das TUN/TAP Interface bestehen bleibt.

Wenn du wirklich die zusätzliche tls-Authentifizierung nutzen willst, dann gibst du mit tls-remote den "Zertifikats-Namen" der Gegenstelle an, also den Namen, den du bei der Zertifikatserstellung angegeben hast.

Hallo Jörg,

also das mit den Parametern werde ich mal bei OpenVPN.net nachlesen.

Leider funktioniert der Verbindungsaufbau bei mir nicht so richtig. Es scheitert seltsamerweise immer am TLS-Handshake:

Tue May 20 12:15:22 2008 OpenVPN 2.1_rc7 Win32-MinGW [SSL] [LZO2] [PKCS11] built on Jan 29 2008
Tue May 20 12:15:22 2008 Control Channel Authentication: using 'C:\Programme\OpenVPN\easy-rsa\keys\Client1\OpenVPN_static_key.key' as a OpenVPN static key file
Tue May 20 12:15:22 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 12:15:22 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 12:15:22 2008 LZO compression initialized
Tue May 20 12:15:22 2008 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue May 20 12:15:22 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue May 20 12:15:22 2008 Local Options hash (VER=V4): '13a273ba'
Tue May 20 12:15:22 2008 Expected Remote Options hash (VER=V4): '360696c5'
Tue May 20 12:15:22 2008 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue May 20 12:15:22 2008 UDPv4 link local: [undef]
Tue May 20 12:15:22 2008 UDPv4 link remote: 82.212.35.145:1194
Tue May 20 12:16:22 2008 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue May 20 12:16:22 2008 TLS Error: TLS handshake failed
Tue May 20 12:16:22 2008 TCP/UDP: Closing socket
Tue May 20 12:16:22 2008 SIGUSR1[soft,tls-error] received, process restarting
Tue May 20 12:16:22 2008 Restart pause, 2 second(s

Ich bin mir nun nicht sicher, ob das daran liegt, dass ich mich gerade zum Testen/Konfigurieren im eigenen Heim-LAN bin oder ob das wirklich was falsch konfiguriert ist

- Zertifikats-Namen: Ist das der Begriff, den ich bei der Erstellung des Server-Zertifikats/-Keys als "Common Name" angegeben habe? Muss dieser Name eigentlich irgendwie auflösbar sein oder kann ich mir hier was ausdenken?

- Spielt es eigentlich eine Rolle, ob ich TCP oder UDP nehme? Gibt es eine Konstellation, die zwingend TCP oder UDP vorraussetzt? Oder ist das nur Abhängig vom jeweiligen Netz und ob nur TCP oder nur UDP erlaubt sind bzw. weitergeleitet werden.

- Du sagst, eigentlich müsste der eine DHCP (DHCP der FBF, die der Router ins Inet ist und der Adressen aus dem Bereich 192.168.0.x vergibt) ausreichen. Aber müssen nicht auch die virtuellen Adressen aus dem ip-Subnetz 192.168.200.x durch irgendjemandenvergeben werden?

- Sehe ich das richtig, dass das Thema Portweiterleitung/Firewall in meiner Konstellation relativ einfach sein müsste, da die Eumex nicht der Router ist, der die Inetverbindung herstellt, sondern lediglich wie ein normaler PC, auf dem der OpenVPN-Server läuft, im privaten WLAN hängt.
Der Router und auch DHCP-Server ist die FBF7050. Sprich eigentlich müsste bei mir doch alles erledigt sein, wenn ich in der 7050 den Port 1194 auf die private ip der eumex (192.168.0.x) weiterleite.

- Bei der Nachlade-Version von OpenVPN musste man vorher mit "mknod /var/tmp/tun0 c 10 200" vorher das tun0-Device anlegen (Bei der Verwendung von tunnel). Ist das bei der mit Freetz erzeugten Image-Version nicht mehr so bzw. passiert automatisch? Muss ich da voher eine create tap0 machen und muss das tap0 heißen
In der Serverkonfig (siehe oben) heißt es "dev tap"?
Laut der Beschreibung muss man in der brinterfaces unter brinterfaces auch tap0 Eintragen für "echtes Bridging"

- wird die Bridge auf Server (Eumex) automatisch erstellt?
Hier http://www.vpnforum.de/wiki/index.p...ridging#Laden_des_TUN-Drivers_.28nur_Linux.29
und hier
http://openvpn.net/index.php/documentation/miscellaneous/ethernet-bridging.html
steht was, dass man die Bridge auf dem Server manuell anlegen muss.
Oder macht die FBF/Eumex das automatisch, sobald man tap0 bei brinterfaces hinzufügt (siehe hier: http://wiki.ip-phone-forum.de/software:ds-mod:pakete:openvpn#routing_vs._bridging)

 

[MaxMuster]

Hi Martin,

folgendes kannst du tun:

- Cipher auf beiden Systemen gleich ;-)
- Erstmal tls-auth und tls-remote rausnehmen


Ansonsten nachschauen, was dabei im Serverlog steht (kannst du mit Experteneinstellungen als "debug" nutzen).

Zu deinen anderen Fragen:

Der "Zertifikatsname" ist der Common Name, wie schon vermutet ;-)

Wenn immer möglich rät die Openvpn-Seite zu UDP, weil performanter. TCP sollte nur genutzt werden, wenn UDP nicht funktioniert. Was über die Verbindung geht hat damit nichts zu tun.

Wenn du TAP nutzt (so dass du direkt mit deinem LAN verbunden bist), solltest du natürlich die IPs aus deinem LAN nutzen. Das Interface muss übrigens nicht angelegt, aber noch in der ar7.cfg gebrückt werden (bei den brinterfaces siehe Wiki).

Genau: Die Portweiterleitung auf der 7050 reicht.

dev tap (im Gegensatz zu "dev tun") sagt nur, ob Tunnel oder Brücke genutzt wird. Das erste freie Interface wird dann genutzt, i.d.R. tap0 oder tun0.


Jörg

 

[blacksun]

Erstmal tls-auth und tls-remote rausnehmen

Unter
/var/mod/etc/openvpn.conf

gibt es zwei Zeilen zu tls:

tls-server
tls-auth /tmp/flash/static.key 0

Wenn ich das Häkchen "TLS-Authentifizierung" rausnehme, dann verschwindet die zweite Zeile. Der Eintrag "tls-server" hingegen bleibt. Lösche ich diesen manuell raus, ist er nach einem Neustart des Servers automatisch wieder drinn. Ist dieses Verhalten so richtig? Schalte ich tls allein durch die zweite Zeile ein und aus?
Oder müsste ich noch nach dem manuellen bearbeiten sowas wie modsave machen?

Der "Zertifikatsname" ist der Common Name, wie schon vermutet ;-)

Kann ich mir da irgendwas ausdenken oder muss ich auf etwas achten?

Wenn du TAP nutzt (so dass du direkt mit deinem LAN verbunden bist), solltest du natürlich die IPs aus deinem LAN nutzen.

Mein privates LAN ist 192.168.0.x
Meine FBF 7050 hat die 192.168.0.99
Meine Eumex mit dem OpenVPN-Server darauf hat die 192.168.0.98

in /var/mod/etc/openvpn.conf steht:

ifconfig 192.168.200.1 255.255.255.0
push "route-gateway 192.168.200.1"
push "route 192.168.0.0 255.255.255.0"

ist die 1. Zeile überhaupt richtig? ipconfig brauche ich doch nur bei Routing. Oder stört das das tap nicht?
was ist denn in meinem Fall der Route-Gateway, die 192.168.200.1, die 192.168.0.99 (die FBF7050 oder 192.168.0.98 (Eumex)
Das mit push "route 192.168.0.0 255.255.255.0" stimmt dann schon, oder muss das die push "route 192.168.200.0 255.255.255.0" sein?

 

[McNetic]

Wenn immer möglich rät die Openvpn-Seite zu UDP, weil performanter. TCP sollte nur genutzt werden, wenn UDP nicht funktioniert. Was über die Verbindung geht hat damit nichts zu tun.

UDP setzt halt vorraus, daß vom Server zum Client der Port auch freigeschaltet ist. In einem Roadwarrior-Szenario kann man das nicht immer garantieren, wenn der Client auch mal hinter anderen Firewalls ins Netz geht.

 

[MaxMuster]

Wenn ich das Häkchen "TLS-Authentifizierung" rausnehme, dann verschwindet die zweite Zeile. Der Eintrag "tls-server" hingegen bleibt.

Das ist richtig. TLS benötigst du, aber die Authentifizierung ist optional (und halt eine mögliche Fehlerquelle).

Die Namen kannst du frei wählen.

Mein privates LAN ist 192.168.0.x
Meine FBF 7050 hat die 192.168.0.99
Meine Eumex mit dem OpenVPN-Server darauf hat die 192.168.0.98

Wenn du das Bridgen "ernst meinst", sollten die IPs auch aus dem LAN (192.168.0.x) sein. Also z.B. 192.168.0.97 255.255.255.0 als IP der Box im VPN (prinzipiell kann der Server sogar "nichmal" die .98 haben oder sogar ohne IP sein [geht nicht mit der GUI]) . Auch die Routen für das LAN sind überflüssig, denn der Client ist ja mit seinem virtuellen Interface Part des Netzes.

Route-Gateway ist das Ziel für Routen, die du im Client über das VPN einträgst. Das kann die Eumex-IP im LAN sein, aber auch direkt die IP der 7050 (.99).

Jörg

 

[blacksun]

Hallo Jörg,

ich habe das Problem gefunden. Ich hatte in der Client-Config bei Remote bereits die dyndns.org-Adresse eingetragen. Aber irgendwie gibt's dann Probleme, wenn man sich bereits im privaten LAN befindet.
Normalerweise funktioniert das, dass man sich von intern statt direkt auf die andere interne ip auf den dyndns.org-Namen (also die öffentliche ip) verbindet.

Ich habe gerade leider keine Möglichkeit, eine zweite Interneteinwahl durchzuführen, um das ganze mal von außen zu testen. Ich werde heute Abend mal mit meinem Laptop zu einem Bekannten gehen und dann mal testen, ob's dann immer noch funktioniert.

 

[MaxMuster]

Evtl hilft die intern ein "float" weiter.

Jörg

 

[blacksun]

Evtl hilft die intern ein "float" weiter.

Leider nicht, das ist schon aktiviert.

Mal noch was ganz anderes. Das ganze Thema rund um VPN kenne ich von einem Bekannten, der sich z.B. von meinem WinXP (über Netzwerkverbindung --> neue Verbindung --> Verbindung mit Netzwerk am Arbeitsplatz) mal eben kurz bei sich in der Firma einwählt. Dann wird auf diese Weise mal mein Rechner zu einem Rechner der Firma.

Jetzt muss man den OpenVPN-Client leider immer auf dem System installieren. Gibt's da nicht auch sowas wie einen "OpenVPN-Client Portable" für Windows, sprich den man einfach von seinem USB-Stick startet, ohne gleich was auf dem Gastrechner installieren zu müssen.

Ich denke da an die Internet-Cafes. Da darf ich nicht auf die schnell mal was installieren. Dass ich aber einen USB-Stick einstecken darf, das ist schon wahrscheinlicher.

Bzw. kann man Windows nicht so erweitern, dass nicht gleich ein zusätzlicher Netzwerkadapter entsteht und man stattdessen auch wie oben beschrieben über Netzwerkverbindung --> neue Verbindung --> Verbindung mit Netzwerk am Arbeitsplatz eine Verbindung zustande bekommt.

 

[blacksun]

Wenn du das Bridgen "ernst meinst", sollten die IPs auch aus dem LAN (192.168.0.x) sein. Also z.B. 192.168.0.97 255.255.255.0 als IP der Box im VPN (prinzipiell kann der Server sogar "nichmal" die .98 haben oder sogar ohne IP sein [geht nicht mit der GUI]) . Auch die Routen für das LAN sind überflüssig, denn der Client ist ja mit seinem virtuellen Interface Part des Netzes.

Route-Gateway ist das Ziel für Routen, die du im Client über das VPN einträgst. Das kann die Eumex-IP im LAN sein, aber auch direkt die IP der 7050 (.99).

Hallo Jörg,

leider doch zu früh gefreut. OpenVPN funktioniert doch nicht.

Trage ich in der GUI bei "VPN IP-Adressen und Routing im VPN" die ip 192.168.0.97, kommt in der openvpn.conf folgendes raus:

push "redirect-gateway"

ifconfig 192.168.0.97 255.255.255.0
push "route-gateway 192.168.0.97"
push "route 192.168.0.0 255.255.255.0"

Auf dem Client baut er dann zwar eine Verbindung zum VPN-Server auf, aber es funktioniert kein Weg in's Inet.

mit ipconfig auf dem Client ergibt sich für die Brücke:

ip: 192.168.0.40
Subnetz: 255.255.255.0
Std-Gateway: 192.168.0.99

Das vorhin hat getäuscht:
Die Verbindung ging nicht über die Brücke, sondern über die normale Inetverbindung. Deshalb gingen vorher auch webaufrufe, da ich das ganze wie in dem Screenshot konfiguriert hatte.
Da hatte ich bei Lokale ip eine 192.168.200.1 eingetragen

Beim Verbinden hat der Client dann gemeldet, dass keine Route zu 192.168.200.1 möglich wäre.

Woran liegt das? Was mache ich falsch?
Und vor wie kann ich die openvpn.conf manuell editieren, ohne dass nach jedem Start von OpenVPN bzw. beim Aufruf wieder das reingeschrieben wird, was mit der GUI eingestellt wurde?

 

[MaxMuster]

Du musst dann auch die ganzen 192.168.200.-Sachen rausnehmen, speziell den "DHCP-Range".

Das Problem dürfte sein, dass du nun zwei Default-Gateways hast, einmal das "normale lokale", dann das über den DHCP vergebene Default Gateway.
Um das zu verhindern konntest du "Clientverker umleiten" versuchen, wenn das allein nicht hilft müsstest du doch den DHCP des VPN nutzen (natürlich einen Bereich wählen, der von der 7050 verschieden ist) und "Clientverker umleiten" auswählen.

Du solltes wenn möglich die GUI zum Einstellen nehmen, eine "eigene" Config ist nur über Umwege möglich.

Deine Angeben zum Versuch sind eigentlich ganz richtig (mit 192.168.0.40 und Std-Gateway 192.168.0.99) es müsste dabei nur sichergestellt werden, dass die "normale" Netzverbindung kein Standardgateway mehr habt, sondern nur eine Route zur IP der Serverfritzbox dort eingetragen ist (das macht "redirect-gateway", was aus der GUI-Option Clientverker umleiten" folgt).

Ändert sich den das Routing dementsprechend? (ipconfig und "route print" vor und nach dem Verbindungsaufbau).

Jörg

 

[blacksun]

Das Problem dürfte sein, dass du nun zwei Default-Gateways hast, einmal das "normale lokale", dann das über den DHCP vergebene Default Gateway.
Um das zu verhindern konntest du "Clientverker umleiten" versuchen, wenn das allein nicht hilft müsstest du doch den DHCP des VPN nutzen (natürlich einen Bereich wählen, der von der 7050 verschieden ist) und "Clientverker umleiten" auswählen.

Das Häkchen bei "Clientverker umleiten" ist schon immer drinn, denn genau möchte ich ja unterwegs mit dem VPN erreichen. Dass alles pauschal über VPN läuft.
Ich habe es nun auch mal mit und ohne DHCP über den OpenVPN probiert. Das Icon der OpenVPN-Gui sagt zwar was von 192.168.0.50 (also aus dem eingestellten OpenVNC-DHCP-Adressebereich), ipconifg sagt aber was anderes

Deine Angeben zum Versuch sind eigentlich ganz richtig (mit 192.168.0.40 und Std-Gateway 192.168.0.99) es müsste dabei nur sichergestellt werden, dass die "normale" Netzverbindung kein Standardgateway mehr habt, sondern nur eine Route zur IP der Serverfritzbox dort eingetragen ist (das macht "redirect-gateway", was aus der GUI-Option Clientverker umleiten" folgt).

Ändert sich den das Routing dementsprechend? (ipconfig und "route print" vor und nach dem Verbindungsaufbau).

Vorweg:
Meine FBF hat im privaten LAN 192.168.0.101
Meine Eumex mit dem OpenVPN-Server hat im privaten LAN 192.168.0.102
Meine FBF vergibt DHCP-Adressen von 192.168.0.30 bis 192.168.0.45
Der DHCP der Eumex ist aus
Der VPN-Server auf der Eumex vergibt wohl Adressen aus dem Bereich wie im Screeshot eingetragen

Meine Konfig sieht jetzt so aus:

(in den Screenshots ist noch der DHCP-Bereich des VPN eingetragen)

ipconfig ganz vor der Verbindung:

Windows-IP-Konfiguration

        Hostname. . . . . . . . . . . . . : testmachine
        Primäres DNS-Suffix . . . . . . . : 
        Knotentyp . . . . . . . . . . . . : Unbekannt
        IP-Routing aktiviert. . . . . . . : Nein
        WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter LAN-Verbindung:

        Verbindungsspezifisches DNS-Suffix: 
        Beschreibung. . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter
        Physikalische Adresse . . . . . . : 00-0C-29-88-3C-F4
        DHCP aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse. . . . . . . . . . . . : 192.168.0.35
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . : 192.168.0.101
        DHCP-Server . . . . . . . . . . . : 192.168.0.101
        DNS-Server. . . . . . . . . . . . : 192.168.0.101
        Lease erhalten. . . . . . . . . . : Dienstag, 20. Mai 2008 23:30:45
        Lease läuft ab. . . . . . . . . . : Freitag, 30. Mai 2008 23:30:45

Ethernetadapter LAN-Verbindung 2:

        Medienstatus. . . . . . . . . . . : Es besteht keine Verbindung
        Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9
        Physikalische Adresse . . . . . . : 00-FF-CE-80-49-A7

route print ganz vor der Verbindung:

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 88 3c f4 ...... VMware Accelerated AMD PCNet Adapter - Paketplaner-Miniport
0x3 ...00 ff ce 80 49 a7 ...... TAP-Win32 Adapter V9 - Paketplaner-Miniport
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0    192.168.0.101    192.168.0.35	  10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
      192.168.0.0    255.255.255.0     192.168.0.35    192.168.0.35	  10
     192.168.0.35  255.255.255.255        127.0.0.1       127.0.0.1	  10
    192.168.0.255  255.255.255.255     192.168.0.35    192.168.0.35	  10
        224.0.0.0        240.0.0.0     192.168.0.35    192.168.0.35	  10
  255.255.255.255  255.255.255.255     192.168.0.35    192.168.0.35	  1
  255.255.255.255  255.255.255.255     192.168.0.35               3	  1
Standardgateway:     192.168.0.101
===========================================================================
St„ndige Routen:
  Keine

Während der Verbindung mit der Konfig wie ind en Screens:

Windows-IP-Konfiguration

        Hostname. . . . . . . . . . . . . : testmachine
        Primäres DNS-Suffix . . . . . . . : 
        Knotentyp . . . . . . . . . . . . : Unbekannt
        IP-Routing aktiviert. . . . . . . : Nein
        WINS-Proxy aktiviert. . . . . . . : Nein

Ethernetadapter LAN-Verbindung:

        Verbindungsspezifisches DNS-Suffix: 
        Beschreibung. . . . . . . . . . . : VMware Accelerated AMD PCNet Adapter
        Physikalische Adresse . . . . . . : 00-0C-29-88-3C-F4
        DHCP aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse. . . . . . . . . . . . : 192.168.0.35
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . : 192.168.0.101
        DHCP-Server . . . . . . . . . . . : 192.168.0.101
        DNS-Server. . . . . . . . . . . . : 192.168.0.101
        Lease erhalten. . . . . . . . . . : Dienstag, 20. Mai 2008 23:30:45
        Lease läuft ab. . . . . . . . . . : Freitag, 30. Mai 2008 23:30:45

Ethernetadapter LAN-Verbindung 2:

        Verbindungsspezifisches DNS-Suffix: 
        Beschreibung. . . . . . . . . . . : TAP-Win32 Adapter V9
        Physikalische Adresse . . . . . . : 00-FF-CE-80-49-A7
        DHCP aktiviert. . . . . . . . . . : Ja
        Autokonfiguration aktiviert . . . : Ja
        IP-Adresse. . . . . . . . . . . . : 192.168.0.40
        Subnetzmaske. . . . . . . . . . . : 255.255.255.0
        Standardgateway . . . . . . . . . : 192.168.0.98
        DHCP-Server . . . . . . . . . . . : 192.168.0.101
        DNS-Server. . . . . . . . . . . . : 192.168.0.101
        Lease erhalten. . . . . . . . . . : Dienstag, 20. Mai 2008 22:56:13
        Lease läuft ab. . . . . . . . . . : Freitag, 30. Mai 2008 22:56:13

===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0c 29 88 3c f4 ...... VMware Accelerated AMD PCNet Adapter - Paketplaner-Miniport
0x3 ...00 ff ce 80 49 a7 ...... TAP-Win32 Adapter V9 - Paketplaner-Miniport
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0     192.168.0.98    192.168.0.40	  1
          0.0.0.0          0.0.0.0    192.168.0.101    192.168.0.35	  10
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1	  1
      192.168.0.0    255.255.255.0     192.168.0.35    192.168.0.35	  10
      192.168.0.0    255.255.255.0     192.168.0.40    192.168.0.40	  30
      192.168.0.0    255.255.255.0     192.168.0.98    192.168.0.40	  1
     192.168.0.35  255.255.255.255        127.0.0.1       127.0.0.1	  10
     192.168.0.40  255.255.255.255        127.0.0.1       127.0.0.1	  30
    192.168.0.102  255.255.255.255    192.168.0.101    192.168.0.40	  1
    192.168.0.255  255.255.255.255     192.168.0.35    192.168.0.35	  10
    192.168.0.255  255.255.255.255     192.168.0.40    192.168.0.40	  30
        224.0.0.0        240.0.0.0     192.168.0.35    192.168.0.35	  10
        224.0.0.0        240.0.0.0     192.168.0.40    192.168.0.40	  30
  255.255.255.255  255.255.255.255     192.168.0.35    192.168.0.35	  1
  255.255.255.255  255.255.255.255     192.168.0.40    192.168.0.40	  1
Standardgateway:      192.168.0.98
===========================================================================
St„ndige Routen:
  Keine

Die VPN-GUi auf dem Client sagt mir im Log:

Tue May 20 23:44:54 2008 OpenVPN 2.1_rc7 Win32-MinGW [SSL] [LZO2] [PKCS11] built on Jan 29 2008
Tue May 20 23:44:54 2008 Control Channel Authentication: using 'C:\Programme\OpenVPN\easy-rsa\keys\Client1\OpenVPN_static_key.key' as a OpenVPN static key file
Tue May 20 23:44:54 2008 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 23:44:54 2008 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 23:44:54 2008 LZO compression initialized
Tue May 20 23:44:54 2008 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Tue May 20 23:44:54 2008 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue May 20 23:44:54 2008 Local Options hash (VER=V4): '13a273ba'
Tue May 20 23:44:54 2008 Expected Remote Options hash (VER=V4): '360696c5'
Tue May 20 23:44:54 2008 Socket Buffers: R=[8192->8192] S=[8192->8192]
Tue May 20 23:44:54 2008 UDPv4 link local: [undef]
Tue May 20 23:44:54 2008 UDPv4 link remote: 192.168.0.102:1194
Tue May 20 23:44:55 2008 TLS: Initial packet from 192.168.0.102:1194, sid=e7b3c97a a225e4de
Tue May 20 23:44:58 2008 VERIFY OK: depth=1, /C=DE/ST=BW/L=Buehlertann/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=BlackSunSoftwareGmbH-CA/[email protected]
Tue May 20 23:44:58 2008 VERIFY X509NAME OK: /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/[email protected]
Tue May 20 23:44:58 2008 VERIFY OK: depth=0, /C=DE/ST=BW/O=BlackSunSoftwareGmbH/OU=OpenVPN/CN=Eumex/[email protected]
Tue May 20 23:44:59 2008 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 20 23:44:59 2008 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 23:44:59 2008 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue May 20 23:44:59 2008 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 20 23:44:59 2008 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue May 20 23:44:59 2008 [Eumex] Peer Connection Initiated with 192.168.0.102:1194
Tue May 20 23:45:00 2008 SENT CONTROL [Eumex]: 'PUSH_REQUEST' (status=1)
Tue May 20 23:45:01 2008 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway,route-gateway 192.168.0.98,route 192.168.0.0 255.255.255.0,ping 10,ping-restart 120,ifconfig 192.168.0.50 255.255.255.0'
Tue May 20 23:45:01 2008 OPTIONS IMPORT: timers and/or timeouts modified
Tue May 20 23:45:01 2008 OPTIONS IMPORT: --ifconfig/up options modified
Tue May 20 23:45:01 2008 OPTIONS IMPORT: route options modified
Tue May 20 23:45:01 2008 OPTIONS IMPORT: route-related options modified
Tue May 20 23:45:01 2008 WARNING: --remote address [192.168.0.102] conflicts with --ifconfig subnet [192.168.0.50, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)
Tue May 20 23:45:01 2008 TAP-WIN32 device [LAN-Verbindung 2] opened: \\.\Global\{CE8049A7-AD96-4FCE-B597-D4D8B92F9AA2}.tap
Tue May 20 23:45:01 2008 TAP-Win32 Driver Version 9.4 
Tue May 20 23:45:01 2008 TAP-Win32 MTU=1500
Tue May 20 23:45:01 2008 Notified TAP-Win32 driver to set a DHCP IP/netmask of 192.168.0.50/255.255.255.0 on interface {CE8049A7-AD96-4FCE-B597-D4D8B92F9AA2} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
Tue May 20 23:45:01 2008 Successful ARP Flush on interface [3] {CE8049A7-AD96-4FCE-B597-D4D8B92F9AA2}
Tue May 20 23:45:06 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:06 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:12 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:12 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:13 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:13 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:14 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:14 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:16 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:16 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:17 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:17 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:18 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:18 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:19 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:19 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:20 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:20 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:21 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:21 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:22 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:22 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:23 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:23 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:24 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:24 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:25 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:25 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:26 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:26 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:27 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:27 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:28 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:28 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:30 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:30 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:31 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:31 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:32 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:32 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:33 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:33 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:34 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:34 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:35 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:35 2008 Route: Waiting for TUN/TAP interface to come up...
Tue May 20 23:45:36 2008 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Tue May 20 23:45:36 2008 route ADD 192.168.0.102 MASK 255.255.255.255 192.168.0.101
Tue May 20 23:45:36 2008 Route addition via IPAPI succeeded [adaptive]
Tue May 20 23:45:36 2008 route DELETE 0.0.0.0 MASK 0.0.0.0 192.168.0.101
Tue May 20 23:45:36 2008 Route deletion via IPAPI succeeded [adaptive]
Tue May 20 23:45:36 2008 route ADD 0.0.0.0 MASK 0.0.0.0 192.168.0.98
Tue May 20 23:45:38 2008 Route addition via IPAPI succeeded [adaptive]
Tue May 20 23:45:38 2008 route ADD 192.168.0.0 MASK 255.255.255.0 192.168.0.98
Tue May 20 23:45:38 2008 Route addition via IPAPI succeeded [adaptive]
SYSTEM ROUTING TABLE
0.0.0.0 0.0.0.0 192.168.0.98 p=0 i=3 t=4 pr=3 a=2 h=0 m=1/-1/-1/-1/-1
0.0.0.0 0.0.0.0 192.168.0.101 p=0 i=2 t=4 pr=3 a=2648 h=0 m=10/-1/-1/-1/-1
127.0.0.0 255.0.0.0 127.0.0.1 p=0 i=1 t=3 pr=2 a=15523 h=0 m=1/-1/-1/-1/-1
192.168.0.0 255.255.255.0 192.168.0.35 p=0 i=2 t=3 pr=2 a=2651 h=0 m=10/-1/-1/-1/-1
192.168.0.0 255.255.255.0 192.168.0.40 p=0 i=3 t=3 pr=2 a=8 h=0 m=30/-1/-1/-1/-1
192.168.0.0 255.255.255.0 192.168.0.98 p=0 i=3 t=4 pr=3 a=2 h=0 m=1/-1/-1/-1/-1
192.168.0.35 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=2651 h=0 m=10/-1/-1/-1/-1
192.168.0.40 255.255.255.255 127.0.0.1 p=0 i=1 t=3 pr=2 a=8 h=0 m=30/-1/-1/-1/-1
192.168.0.102 255.255.255.255 192.168.0.101 p=0 i=3 t=4 pr=3 a=4 h=0 m=1/-1/-1/-1/-1
192.168.0.255 255.255.255.255 192.168.0.35 p=0 i=2 t=3 pr=2 a=2651 h=0 m=10/-1/-1/-1/-1
192.168.0.255 255.255.255.255 192.168.0.40 p=0 i=3 t=3 pr=2 a=8 h=0 m=30/-1/-1/-1/-1
224.0.0.0 240.0.0.0 192.168.0.35 p=0 i=2 t=3 pr=2 a=2651 h=0 m=10/-1/-1/-1/-1
224.0.0.0 240.0.0.0 192.168.0.40 p=0 i=3 t=3 pr=2 a=8 h=0 m=30/-1/-1/-1/-1
255.255.255.255 255.255.255.255 192.168.0.35 p=0 i=2 t=3 pr=2 a=15523 h=0 m=1/-1/-1/-1/-1
255.255.255.255 255.255.255.255 192.168.0.40 p=0 i=3 t=3 pr=2 a=15523 h=0 m=1/-1/-1/-1/-1
SYSTEM ADAPTER LIST
TAP-Win32 Adapter V9 - Paketplaner-Miniport
  Index = 3
  GUID = {CE8049A7-AD96-4FCE-B597-D4D8B92F9AA2}
  IP = 192.168.0.40/255.255.255.0 
  MAC = 00:ff:ce:80:49:a7
  GATEWAY = 192.168.0.98/0.0.0.0 
  DHCP SERV = 192.168.0.101 
  DHCP LEASE OBTAINED = Tue May 20 22:56:13 2008
  DHCP LEASE EXPIRES  = Fri May 30 22:56:13 2008
  DNS SERV = 192.168.0.101 
VMware Accelerated AMD PCNet Adapter - Paketplaner-Miniport
  Index = 2
  GUID = {17AF4B1C-535E-4E83-9E14-6EDA2A1AEA91}
  IP = 192.168.0.35/255.255.255.0 
  MAC = 00:0c:29:88:3c:f4
  GATEWAY = 192.168.0.101/0.0.0.0 
  DHCP SERV = 192.168.0.101 
  DHCP LEASE OBTAINED = Tue May 20 23:30:45 2008
  DHCP LEASE EXPIRES  = Fri May 30 23:30:45 2008
  DNS SERV = 192.168.0.101 
Tue May 20 23:45:41 2008 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )

Was muss ich ändern, damit es funktioniert?

 

[MaxMuster]

O.k., ich hatte nicht gedacht, dass du das lokal getestet hast. Damit wird das Szenario mit TAP nicht funktionieren können, das sagt schon das log!

WARNING: --remote address [192.168.0.102] conflicts with --ifconfig subnet [192.168.0.50, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)

Denn du verbindest den virtuellen Adapter ja gerade mit deinem LAN, so dass dann sowohl LAN als auch TAP im gleichen Netz sind. Dann wird das System im Routing eine Schnittstelle zum Standardgateway frei wählen, es hat ja zwei.

Um das intern so zu testen könntest du folgendes testen: Der Eumex eine weitere IP aus einem anderen Netz geben (z.B. 192.168.222.1) und den Test-PC ebenfalls in das Netz setzen, Standardgateway auf die Eumex. Dann als "remote" in der VPN-Config diese Eumex-IP eingeben.
Als Ergebnis sollte das Standardgateway von dem LAN verschwinden und beim TAP erscheinen.

ifconfig lan:1 192.168.222.1

PC fest einstellen auf 192.168.222.50 StaddardGW 192.168.222.1

Aber bin ich leicht irritiert: Zuerst hatten 7050 und Eumex .99 und .98, jetzt haben sie .101 und .102 ???

Und nein, OpenVPN benötigt immer einen virtuellen Adapter. Wenn du da nichts installieren darfst geht es nicht.

Bei einem WIN-Betriebssystem könntest du als Alternative evtl. auf PPTP ausweichen, sofern man das auf einem solchen PC nutzen darf.

Das sind aber Vorgaben und Grundlagen, die vollkommen unabhängig von freetz und Eumex sind...


Jörg

 

[blacksun]

Hallo Jörg,

stimmt, so hat das funktioniert. Zumindest lokal im LAN. Auch über GPRS mit dem Handy von aussen hat das nun funktioniert.
Ich werde heute abend nochmal zu einem Bekannten gehen und von seinem DSL-Anschluss testen. Den mit der GPRS-Verbindung bekommt man auch nur eine private-IP zugewiesen (172.21.133.x). Darum will ich das heute abend mal von einer öffentlichen ip-Adresse ausprobieren.
Das ist der Nachteil, wenn man keinen Telefonanschluss mehr bei der Telekom hat. Man hat nur noch die Mögichkeit, über das Handy in' Inet zu kommen (zusätzlich zum normalen Breitband-Internetzugang). Früher gab's immer doch die klassische Modem-Einwahl.

Nur noch mal ein Verständnisfrage
In dieses Feld (lokale IP) kommt doch immer die ip, die das tap/tun-Device haben soll, richtig?

Das bedeutet im Unkehrschluss, dass dort nie die ip von der Eumex oder von der FBF stehen darf, da es sonst einen Adresskonflikt gibt, richtig?

Wenn ich mich nun von aussen auf den OpenVPN verbinde, dann sieht das jetzt so aus (in diesem Fall über die Handy-Verbindung):

Die eigentliche Inetverbindung hat nun keinen Gateway mehr.
Allerdings hat der TAP-Adapter nun 2 Gateways.
Einmal die .98 vom OpenVPN und dann noch die .101 vom DHCP-Server der FritzBox. Besteht da nicht die Gefahr, dass es mit den zwei Gateways zu Problemen kommt?


Thema OpenVPN-Portable:
Stimmt, ohne TAN-Device geht kein OpenVPN. Ich habe aber was nettes gefunden, das tatsächlich OpenVPN-Portable heißt:
http://sourceforge.net/projects/ovpnp
Ist im Grunde das gleiche wie beim richtigen OpenVPN, also diesselbe GUI, nur dass man nun alles auf einem USB-Stick hat. Beim Starten der OpenVPNPortable.exe wird automatisch ein TAN-Device installiert, welches aber beim Beenden automatisch wieder deinstalliert wird. Das ist ein akzeptabler Kompromiss.

Die andere Möglichkeit wären eine VM-Ware, die ohne Installation auskommt bzw. gleich ein auf einen USB-Stick installiertes WinXP. Sowas soll es geben. Auf diese Arte müsste man am Gast-Windows auch keine Veränderungen vornehmen. Aber das ist ein anderes Thema.

Wegen den ip-Adressen nicht verwirren lassen. Da ich nun sowohl reale ip-Adressen als auch virtuelle in meinem LAN habe, habe ich einmal umsortiert. Oberhalb von 100 kommen die realen Adressen (FBF .101, Eumex .102), unterhalb kommen dann die virtuellen wie nun die des TAP-Device (.98). Hat also nichts mit irgend einer Funktionalität zu tun.

Ist Dir eigentlich etwas bekannt, dass eine FBF7050 (mit Orginal-FW ohne irgendwelche Modifikationen) eine Firewall hat, die Ping-Anfragen oder auch den Zugriff auf Serverdienste sperrt?
Ich habe mehrere Versuche gebraucht, um von extern (über die Handy-Verbindung) eine PING-Antwort auf die externe ip der FBF zu bekommen. Auch der Zugriff auf Serverdienste (ftp, VNC, usw) haben nicht funktioniert, obwohl Portforwardings gesetzt sind. Erst als ich die Box neu gestartet habe, ging es?
Liegt sowas an der FBF oder muss ist das etwas von meinem Breitbandanbieter?

 

[MaxMuster]

In dieses Feld (lokale IP) kommt doch immer die ip, die das tap/tun-Device haben soll, richtig?
Das bedeutet im Unkehrschluss, dass dort nie die ip von der Eumex oder von der FBF stehen darf, da es sonst einen Adresskonflikt gibt, richtig?

Jein: Beim TAP was in "brinterfaces" steht ist das prinzipiell möglich, denn letztlich wird die Bridge genutzt, da ist das dann egal. Ansonsten würde ich immer eine "eigene" IP reinnehmen.

Allerdings hat der TAP-Adapter nun 2 Gateways.... Besteht da nicht die Gefahr, dass es mit den zwei Gateways zu Problemen kommt?

Sollte eigentlich nicht, denn letztlich ist es egal, ob die Pakete erst zur Eumx gehen oder direkt zur 7050. Du solltest das umgehen können, indem du mit "Experteneinstellungen" unten bei Zusatzparameter einträgst ein

push "route-gateway 192.168.0.101"

Dann sollte nur noch die Route zur 7050 eingebaut werden.

Ob das "portable Openvpn" ohne Admin-Rechte auskommt weiß ich nicht? So eine VM wäre natürlich möglich.
Für die meisten Dinge, die per TCP ablaufen, würde übrigens vermutlich eine SSH-Session mit Tunneln reichen. Zum Surfen dann z.B. einen Proxy im heimischen LAN und damit wäre das Thema schonmal "gegessen"....

Die originale Firewall sperrt eigentlich "fast nichts". Die "Sicherheit" kommt dadurch zustande, dass nur Dinge, für die eine Portweiterleitung eingetragen ist weitergegeben werden. Ein Ping auf die externe IP sollte standardmäßig möglich sein.

Jörg

 

[blacksun]

Hallo Jörg,

also ich wollte Dir noch Rückmeldung geben, dass alles nun wie gewünscht funktioniert. Ich habe nun von einem anderen DSL-Anschluss eine VPN-Verbindung aufgebaut. Hat alles wunderbar funktioniert.

Zum Thema portable Openvpn:
Habe ich auch gleich bei einem Bekannten ausprobiert. Admin-Rechte sind notwendig, damit das Tap-Device installiert werden kann.

Mir ist aber noch einfallen, dass ich mich noch überhaupt nicht bedankt habe, für die Hilfe von Dir. Darum jetzt mal ein ganz großes Dankeschön von mir.

Aber zwei Fragen hätte ich doch noch an Dich zum Thema:
Die Binary openvpn, die sich nun bei mir auf der Eumex befindet, das ist doch sowohl Server als auch Client, oder? Ob Server oder ob Client, das bestimmt sich doch nur durch das openvpn.conf, das beim Aufruf mitgegeben wird.

Mir ist da noch eine andere Idee gekommen. Und zwar betreibe ich bei mir zwei Hotspots (evtl. sagt Dir www.fon.com bzw. deren WLAN-Router, die Fonera was).
Diese hängen die bei mir im privaten LAN und habe so Ihre Verbindung in's Inet.
Nun gibt es den Dienst hotplots.de, der eigene OpenVPN-Server hat, die man kostenlos als hotsplots-Mitglied nutzen kann (http://www.hotsplots.de/de/support/files-links/openvpn.html).

Da sich auf auf der Eumex OpenVPN befindet, ist die Idee nun, dass man den Traffic der WLAN-Router über die OpenVPN-Server von hotsplots umleitet. Natürlich macht das ganze nur dann Sinn, wenn NUR die Verbindungen der beiden WLAN-Router umgeleitet werden. Würde der gesamte Traffic der Eumex über den OpenVPN-Server von hotsplots umgeleitet werden, dann bräuchte ich ja überhaupt keinen eingen VPN-Server.
Der eigene VPN-Server verschlüsselt meine eingenen Verbindungen, wenn ich unterwegs mit an einem Hotspot anmelde, während die VPN-Server bei hotsplots mich davor schützen, was die Hotspot-Gäste bei mir so treiben. Meinen eigenen Traffic möchte ich aber nicht über hotsplots leiten, da ich nicht weiß, was die alles aufzeichnen.

Die beiden Router haben beide eine ip-Adresse bei mir im LAN (192.168.0.16 und .15)
Daher frage ich mich, ob es möglich ist, auf der Eumex routen speziell für diese beiden ip-Adressen festzulegen. D.h. wenn eine dieser beiden Adressen in's Inet will, dann soll ein anderes Gateway benutzt werden als wenn z.B. die 192.68.0.17 in's Inet möchte.

Ist sowas machbar? Sprich Routen für bestimmte ip-Adressen festlegen?

 

[MaxMuster]

Hallo Martin,

freut mich, dass es soweit klappt.

Die Box kann (auch gleichzeitig) Server und Client sein. Ich könnte mir vorstellen, dass das "selektive Umleiten" vielleicht mit iptables möglich ist (eigentlich bin ich sogar sicher dass das klappen sollte), aber damit habe ich mich noch nicht so richtig beschäftigt. Vielleicht weiß jemand anders hier darüber was?

Jörg

 

[blacksun]

Die Box kann (auch gleichzeitig) Server und Client sein. Ich könnte mir vorstellen, dass das "selektive Umleiten" vielleicht mit iptables möglich ist (eigentlich bin ich sogar sicher dass das klappen sollte)

Misst, jetzt habe ich leider die iptables nicht im Image mit drinn. Die sind bestimmt wieder riesig, so dass sie nicht in's Image passen und ich wieder was weglassen muss.

Aber ich habe da noch eine andere Idee.
Und zwar hast Du mich oben, als es um die Sache mit den Tests aus dem lokalen LAN ging, mit

ifconfig lan:1 192.168.222.1

auf eine Idee gebracht.

Ich könnte doch die beiden Foneras in ein eigenes Subnetz hängen. Sprich die bekommen dann eine ip-Adresse z.B. 192.168.222.15 und 192.168.222.16
Dann muss ich die Eumex nur dazu bewegen, dass sie bei jedem Neustart den obigen Befehl ausführt, sprich sich selbst die ip-Adresse 192.168.222.1 gibt.
Wie mache ich das am geschicktesten?

In meine FBF7050 trage ich dann eine statische Route ein, so dass alle Clients aus 192.168.0.0 ebenfalls den Weg ins Subnetz 192.168.222.0 finden. Das kann die Orginal-FW auch schon, so dass ich dort nichts modifizieren muss.

Dann müsste ich auf der eumex nur noch sagen, dass lan:1 (und auch nur lan:1) nach tun geroutet wird.
Weißt Du zufällig, wie man sowas macht?
Ich hoffe, dass das ohne iptables funktioniert.

Das tun-interface wird ja, wenn ich das richtig gesehen habe, beim start von openvpn als client automatisch erzeugt.

Gibt's eigentlich einen Ort im Dateisystem, an dem ich die das Client-Konfig-File, die Zertifkate und den Key dauerhaft abspeichern kann, so dass es auch nach einem Reboot nicht weg ist, oder muss ich das wirklich wie bei Nachladeversion über die debug.cfg beim Booten der Eumex schreiben lassen?

 

[MaxMuster]

Dann muss ich die Eumex nur dazu bewegen, dass sie bei jedem Neustart den obigen Befehl ausführt, sprich sich selbst die ip-Adresse 192.168.222.1 gibt.

Sowas passt z.B. in die "debug.cfg", die wird bei jedem Start ausgeführt.

Dann müsste ich auf der eumex nur noch sagen, dass lan:1 (und auch nur lan:1) nach tun geroutet wird. ... Ich hoffe, dass das ohne iptables funktioniert.

Ich fürchte schon, dass du auch dafür iptables bemühen müsstest...

Gibt's eigentlich einen Ort im Dateisystem, an dem ich die das Client-Konfig-File, die Zertifkate und den Key dauerhaft abspeichern kann, so dass es auch nach einem Reboot nicht weg ist, oder muss ich das wirklich wie bei Nachladeversion über die debug.cfg beim Booten der Eumex schreiben lassen?

Das verstehe ich nicht so ganz. Du nutzt doch das openvpn der freetz, oder? Die in der GUI gemachten Einstellungen und die Zertifikate Keys usw. werden dann doch im flash abgelegt und sind nach jedem Start wieder da. Mit der "Experten-Sicht" kannst du auch mehrere Configs gleichzeitig verwalten.

Jörg