# Wlan mit OpenVPN schützen

## Anarcho

Motivation

Da mir persönlich die Verschlüsselung und Sicherheitsfeatures von WLAN zu schwach sind, wollte ich mein WLAN mit OpenVPN absichern. Da dies mittlerweile recht gut funktioniert, möchte ich meine Erkenntnisse mit euch teilen.

Zusammenfassung

Es wird ein AP direkt an einer nur dafür vorgesehenen Netzwerkkarte angeschlossen. Danach wird ein OpenVPN Netzwerk eingerichtet und mit iptables jeder andere Netzwerkverkehr gestoppt. Dadurch ist es nur noch möglich mit gültigen Key aufs Netzwerk zuzugreifen, selbst wenn man es geschafft hat an den WLAN Sicherungen vorbeizukommen.

Die beiden IP-Adressen werden per DHCP übermittelt.

Inhalt

0. Kernel-Vorraussetzungen

1. Konfigurieren der Netzwerkkarten am Server

2. Einrichten von OpenVPN 2.0 Server 

3. Einrichten von DHCP am Server

4. Einrichten von OpenVPN am Client (Linux/Windows)

5. Konfigurieren der Netzwerkkarten am Client

6. Abdichten des Servers per iptables

0. Kernel Vorraussetzungen

OpenVPN benutzt das TUN/TAP Modul um ein virtuelles Netzwerkinterface zum tunneln zu erstellen. Dazu benötigt man die Unterstützung für das Universal TUN/TAP Device im Kernel unter Network-Support.

Wenn man es als Modul kompiliert hat, heisst es tun.

1. Konfigurieren der Netzwerkkarten am Server

Es steht mindestens eine Netzwerkkarten zur Verfügung. Ich gehe davon aus das jeder in der lage ist dieser eine IP-Adresse zuzuweisen. Ferner gehe ich davon aus das dieser Server das Gateway zum Internet darstellt und auch dieses schon eingerichtet ist (NAT, MASQUERADING, ...)

Damit sich ein eventuell vorhandes Kabelnetzwerk nicht mit dem WLAN beisst, muss sich beides an einer einzelnen Netzwerkkarte befinden. Um das VPN eindeutig zu kennzeichnen habe ich mich für das eigentliche WLAN für das Netzwerk 192.168.1.0/24 und für das VPN das Netzwerk 10.1.0.0/24 entschieden. Dadurch sind beide Netzwerke sehr einfach von einander zu unterscheiden. 

Ich gebe dem Server für das normale WLAN die IP 192.168.1.1, wobei zu sagen ist das der Server ja nicht richtig im WLAN ist sondern es sich dabei nur um die IP Adresse der Netzwerkkarte zum AccessPoint handelt.

Das eventuell vorhandensein von DHCP des AccessPoints ist auszuschalten!

Folgendes haben wir bisher getan: Die Netzwerkkarte des Servers zum AP (z.b. eth1) hat nun die IP 192.168.1.1

2. Einrichten von OpenVPN 2.0 Beta am Server

Ich habe mich für OpenVPN 2.0 entschieden da der Serverbetrieb deutlich verbessert wurde. So ist es nun möglich mehrere Clients über nur 1 Interface anzubinden. 

Wer nur einen Client verbinden möchte kann auch OpenVPN 1.5 oder 1.6 nehmen, ich werde an der entsprechenden Stelle auf den Unterschied hinweisen.

Ich empfehle das USE-Flag pthreads zu verwenden da dies die Performance erheblich steigern kann, gerade bei mehreren Clients.

Nach erfolgreicher Installation erstellen wir uns ein neues Verzeichnis in den alle Dateien abgelegt werden sollen:

```
mkdir /etc/openvpn/wireless -p
```

Für die folgende Schritte benötigt ihr OpenSSL, denn nun müssen wir die Zertifikate erstellen.

Als erstes müssen wir eine CA  (certificate authority) welche die später erzeugten Schlüssel signiert. Dazu editieren wir als erstes die Datei openssl.cnf. Diese sollte sich bei euch im Verzeichnis /etc/ssl befinden, also 

```
cd /etc/ssl
```

Angepasst werden müssen folgende Werte:

- default_days (spezifiziert wie lange das Zertifikat gültig sein soll, 3650 sind 10 Jahre)

- dir (falls ihr ein anderes Verzeichnis nehmen wollt)

- certificate (zu my-ca.crt)

- private_key (zu my-ca.key)

- default_bits (zu 2048 für mehr Sicherheit)

Nachdem wir die Änderungen vorgenommen haben können wir unsere CA erstellen. Wählt eure Angaben selber aus (Firma, Ort, usw.)

```
openssl req -nodes -new -x509 -keyout my-ca.key -out my-ca.crt -days 3650
```

Dann können wir unsere Server- und Client-Zertifikate erstellen:

```
openssl req -nodes -new -keyout server.key -out server.csr

openssl ca -out server.crt -in server.csr

openssl req -nodes -new -keyout client.key -out client.csr

openssl ca -out client.crt -in client.csr
```

Auch hier solltet ihr sinnvolle Werte selbständig finden.

Zum Schluss noch den DH-Key

```
openssl dhparam -out dh2048.pem 2048
```

Falls ihr nur 1024 in der openssl.cnf gewählt habt, solltet ihr dies hier anpassen.

Nun kopieren wir die eben erstellten Dateien in unser OpenVPN-Verzeichnis von eben.

```
cp server.crt server.key client.crt dh2048.pem /etc/openvpn/wireless/
```

Das Zertifikat der CA wird ebenfalls benötigt, per default befindet es sich in ./demoCA

```
cp ./demoCA/my-ca.crt /etc/openvpn/wireless/
```

Nun können wir ins Verzeichnis /etc/openvpn/wireless wechseln

```
cd /etc/openvpn/wireless
```

Optional

Zusätzlich empfehle ich noch einen weiteren Key hinzuzufügen. Dieser authentifiziert das anmelden und übertragen des eigenen Zertifikats. Dadurch wird die Sicherheit erhöht und mögliche DoS Attacken erschwert.

```
openvpn --genkey --secret wireless.key
```

Nun kommen wir zur eigentlichen Konfiguration von OpenVPN. Wir erstellen die Datei /etc/openvpn/wireless/local.conf mit folgendem Inhalt:

```
dev tap

ifconfig 10.1.0.1 255.255.255.0

mode server

tls-server

dh dh2048.pem

ca my-ca.crt

cert server.crt

key server.key

tun-mtu 1500

mssfix 1400

# Kompression

comp-lzo

# Die nächste Zeile ist optional, nur verwenden falls die Datei oben erzeugt wurde

tls-auth /etc/openvpn/wireless/wireless.key 0

# Die nächste Zeile erlaubt mehrere Clients mit gleichem Zertifikat. 

# Das vereinfacht die Sache erheblich.

# Nur mit Version 2.0 Beta verwenden.

duplicate-cn

chroot /etc/openvpn/wireless/newroot

user nobody

group nobody

```

Dann erstellen wir noch das neue Gefängnis für unseren OpenVPN Server:

```
mkdir /etc/openvpn/wireless/newroot
```

Nun können wir den Server starten und zum default Runlevel hinzufügen.

```
/etc/init.d/openvpn start

rc-update add openvpn default
```

3. Einrichten von DHCP am Server

Ich stelle hier nur kurz eine mögliche dhcpd.conf vor (/etc/dhcp/dhcpd.conf)

```
default-lease-time 600;

max-lease-time 7200;

option subnet-mask 255.255.255.0;

ddns-update-style interim;

# Netzwerk des normalen WLAN

subnet 192.168.1.0 netmask 255.255.255.0

{

        range 192.168.1.12 192.168.1.120;

        # Die Nameserver solltet ihr gegen die eures Providers tauschen, diese hier sind von Arcor.

        option domain-name-servers 145.253.2.203, 145.253.2.171;

        option broadcast-address 192.168.1.255;

}

# Netzwerk des VPN

subnet 10.1.0.0 netmask 255.255.255.0

{

        range 10.1.0.12 10.1.0.120;

        # Die Nameserver solltet ihr gegen die eures Providers tauschen, diese hier sind von Arcor.

        option domain-name-servers 145.253.2.203, 145.253.2.171;

        # Erst hier wird das default Gateway übergeben, da der Verkehr über das normale Device ja geblockt ist

        option routers 10.1.0.1;

        option broadcast-address 10.1.0.255;

}
```

4. Einrichten von OpenVPN am Client (Linux/Windows)

Da OpenVPN 1.5/1.6 nicht 100% kompatible zu OpenVPN 2.0 ist, benötigen wir hier auch OpenVPN 2.0, für Windows XP SP2 sowieso.

Der Client benötigt folgende Dateien, die möglichst sicher übertragen werden sollten (SSH, Diskette, USB-Stick, etc.)

- client.crt

- client.key

- my-ca.crt

- wireless.key

Linux

Diese sollten sich ebenfalls im Verzeichnis /etc/openvpn/wireless befinden.

Dann erstellen wir die config-Datei: /etc/openvpn/wireless/local.conf

```
dev tap

# IP des Servers

remote 192.168.1.1 5000

tun-mtu 1500

mssfix 1400

tls-client

ca my-ca.crt

cert client.crt

key client.key

# Kompression der Daten

comp-lzo

# Optional, siehe oben

tls-auth /etc/openvpn/wireless/wireless.key 1

user nobody

group nobody

# Wichtige Resourcen behalten nach Wechsel zum user nobody

persist-key

persist-tun
```

Nun nur noch OpenVPN starten und zum default runlevel hinzufügen:

```
/etc/init.d/openvpn start

rc-update add openvpn default
```

Windows

Hier sollten sich die Datein im Config-Verzeichnis des Installationsverzeichnisses befinden. Z.b. C:\Programme\OpenVPN\config

Dort erstellen wir die Datei local.ovpn:

```
dev tap

remote 192.168.1.1 5000

tun-mtu 1500

mssfix 1400

# Optional, s.o.

tls-auth wireless.key 1

tls-client

ca my-ca.crt

cert client.crt

key client.key

comp-lzo
```

OpenVPN installiert unter Windows einen Service(Dienst). Bei diesem solltet ihr die Startart auf "Automatisch" setzen, dann wird er beim hochfahren mit gestartet (falls erwünscht)

5. Konfigurieren der Netzwerkkarten am Client 

Linux

Da ich alles per DHCP übertragen lassen müsst ihr einfach in die Datei /etc/conf.d/net folgendes eintragen:

```
ifconfig_tap0=( "dhcp" )
```

Da wir das init-script für tap0 nach openvpn starten müssen, können wir keinen symlink anlegen.

Daher kopieren wir die Datei:

```
cd /etc/init.d

cp net.eth0 net.tap0

rc-update add net.tap0 default
```

Damit net.tap0 auch wirklich nach openvpn gestartet wird editieren wir nun die Datei net.tap0 und fügen unter depend() folgendes hinzu:

```
need openvpn
```

Nun sollte zuerst net.wlan0, dann openvpn und dann erst net.tap0 gestartet werden. Danach habt ihr das default-gateway per DHCP bekommen und könnt lossurfen.

Windows

Hier müsst ihr nichts mehr tun, da Windows automatisch nach einem DHCP Server sucht.

6. Abdichten des Servers per iptables 

Auf dem Server wollen wir ja nur noch VPN-verbindungen dulden. Daher führen wir folgendes aus:

```

iptables -t filter -A INPUT --protocol udp --dport 5000 -j ACCEPT -i eth1 # eth1 ist das Interface an dem der AP hängt

iptables -t filter -A INPUT -j REJECT -i eth1 #oder -j DROP, je nach Geschmack

/etc/init.d/iptables save

```

So, das wars schon! Ich hoffe es haben sich keine Fehler eingeschlichen und es ist alles verständlich erklärt. 

OK, das Firewall-script ist etwas flach, aber um den Rahmen nicht zu sprengen musste ich es etwas kürzen. Jedenfalls tut es genau das was es soll. Es lässt nur Verbindungen über OpenVPN durch. 

Natürlich muss man kein DHCP benutzen, sondern kann auch alle Netzwerkeinstellungen am Client selber setzen. Aber ich persönlich stehe auf DHCP, da es damit alles schön zentral gesteuert wird. Wenn neue Clients hinzukommen hat man zumindest mit der Netzwerkeinstellung weniger zu tun.

Bei Fragen, Kritik und Anregungen bitte ich doch sehr sich hier zu Wort zu melden.

EDIT:

- Universal TUN/TAP Anmerkung hinzugefügt

- OpenVPN 2.0 ist im Portage

----------

## Sonic Lux

Genial, ich danke dir.

Werde ich dieses WE gleich mal umsetzen.

----------

## Hilefoks

Echt super,

heute erwarte ich meinen neuen WLAN-Router und siehe da!

Danke

----------

## xces

Als Ergänzung: Securing an 802.11a/b/g Network with a VPN using Linux 2.6

----------

## unix

Supi,

Muss ich gleich mal testen  :Wink: 

----------

## /dev/blackhawk

Echt stark!!!

Bei so einem How-To muss man das ganze ja fast ausprobieren!   :Wink: 

MFG

/dev/blackhawk

----------

## Sonic Lux

Hallo,

ich habe jetzt 2 Netze miteinander verbunden, ist etwas anderes aber das Grundprinzip ist ja das selbe.

So und nun mein Problem:

wenn ich "dev tap" in die configs eintrage funktioniert es nicht

bei "dev tun" schon. Wie kommt das ?

----------

## Sonic Lux

Problem gelöst ....

RTFM  :Laughing: 

 *Quote:*   

> 
> 
> Hierbei arbeitet das tun-Device auf IP-Ebene, das tap-Device auf Ethernet-Ebene (z.B. für Bridging). Anders als die normalen Netwerkinterfaces besitzt das tun- bzw tap-Device ein Devicefile (/dev/tunN, /dev/tapN), so ist es aus dem Userspace nutzbar.

 

Also für meine Verbindung zwschen 2 Netzen muss ich tun verwenden, alles klar.  :Cool: 

----------

## aZZe

Ich habe versucht bei mir zu Hause auch mein WLAN mit VPN abzusichern.Serverseitig sieht das bei mir so aus:

eth0 : 192.168.1.1 --> internes Netz

eth1 : ppp0 --> DSL Verbindung

eth2 : 192.168.1.2 --> Verbindung zum AP

Dem Access-Point wurde die Adresse 192.168.1.4 zugewiesen welcher direkt mit eth2 am Server verbunden ist. Müsste ja so ok sein oder?

Serverseitig habe ich auch ein device tap0 welches die Adresse 10.1.0.1 hat wie auch im Howto beschrieben. Wenn ich allerdings meinen Client einrichten will bekomme ich kein tap0 hin. Er ordnet dies keiner Netzwerkkarte zu. Normalerweise ist meine WLAN Schnittstelle eth1 auf dem Laptop. Die Fehlermeldung im syslog sieht wie folgt aus:

```

Mar 18 14:56:43 t42 dhcpcd[16220]: dhcpStart: ioctl SIOCGIFHWADDR: No such device

```

Hier noch mal die ganzen Configs:

Auf dem Server /etc/openvpn/wireless/local.conf:

```

dev tap

ifconfig 10.1.0.1 255.255.255.0

mode server

tls-server

dh dh2048.pem

ca ca.crt

cert server.crt

key server.key

tun-mtu 1500

mssfix 1400

comp-lzo

tls-auth /etc/openvpn/wireless/wireless.key 0

duplicate-cn

chroot /etc/openvpn/wireless/newroot

user nobody

group nobody

```

dhcpd.conf auf dem server:

```

ddns-update-style interim;

ddns-domainname "dark.lan";

ddns-rev-domainname "1.168.192.in-addr.arpa";

ddns-updates on;

default-lease-time 600;

max-lease-time 7200;

option domain-name-servers 192.168.1.1, 217.237.151.225, 217.237.150.225, 194.25.2.129;

option domain-name "dark.lan";

option broadcast-address 192.168.1.255;

option broadcast-address 10.1.0.255;

option routers 192.168.1.1;

option routers 10.1.0.1;

option subnet-mask 255.255.255.0;

server-name "larry";

allow unknown-clients;

authoritative;

# normales Netzwerk

subnet 192.168.1.0 netmask 255.255.255.0 {

        range 192.168.1.10 192.168.1.50;

        }

# VPN Netzwerk

subnet 10.1.0.0 netmask 255.255.255.0 {

        range 10.1.0.10 10.1.0.50;

        }

key DHCP_UPDATER. {

         algorithm hmac-md5;

         secret "T+Uwruh6uDFNokk310uCJQ==";

         }

zone dark.lan. {

        primary 127.0.0.1;

        key DHCP_UPDATER.;

}

zone 1.168.192.in-addr.arpa. {

        primary 127.0.0.1;

        key DHCP_UPDATER.;

}

```

Auf dem Client /etc/openvpn/wireless/local.conf:

```
dev tap

remote 192.168.1.2 1194

tun-mtu 1500

mssfix 1400

tls-client

ca ca.crt

cert laptop.crt

key laptop.key

comp-lzo

tls-auth /etc/openvpn/wireless/wireless.key 1

user nobody

group nobody

```

Wie gesagt ich bekomme das device tap0 nicht gestartet da ipw2200 auf eth1 läuft und tp0 dadurch keine Netzwerkkarte in dem Sinne besitzt. Aufgrund dessen kann ich auch per DHCP keine Adresse empfangen.

Hat einer eine Idee?

----------

## Anarcho

Hi,

ich vermute das es daran liegt, das bei dir im Server 2 Netzwerkkarten im gleichen Subnet sind. Daher kann der Server nicht eindeutig routen.

Du solltest für die Netzwerkkarte die zum AP geht ein eigenes Subnet nehmen, 

(192.168.x.1 mit x <> 1)

----------

## aZZe

OK: und der AP logischerweise dann im gleichen Subnet nicht wahr?

----------

## Anarcho

Klar, wobei du die IP des APs ja nur für die Konfiguration brauchst.

----------

## aZZe

OK. Kein Problem. Nur wenn ich mein WLAN Modul starte, welches ich ja logischerweise für die VPN brauche startet dieses eth1 auf dem laptop. tap0 kann keiner HW-Adresse zugeordnet werden.

----------

## Anarcho

tap0 wird von openvpn erzeugt.

Das heisst die Reihenfolge ist wichtig:

Zuerst baust du ganz normal dein eth1 auf, inklusive IP-Adresse. 

Dann sollte (wenn die Firewall aus ist) alles funktionieren, insbesondere der Zugriff auf 192.168.x.1, also eth2 vom Server.

Danach startest du openvpn (in der Config natürlich die IP des Servers jetzt ändern) und baust somit eine VPN-Verbindung zum Server auf. Daraufhin wird tap0 erzeugt. 

Nun kannst du per dhcpcd dort eine IP-Adresse beziehen.

Ach ja, ich würde in deiner dhcpd.conf die einzelnen Optionen, die Subnet-spezifisch sind, auch dort hineinnehmen und nicht global ganz oben bestimmen.

----------

## aZZe

Genauso hab ichs gemacht. eth2 am Server hat jetzt die 192.168.0.1. Die Netzwerkkarte im Laptop eth1 hat die 192.168.0.10. Wenn ich danach tap0 starten möchte steht wieder im syslog:

```

Mar 18 16:19:11 t42 dhcpcd[27630]: dhcpStart: ioctl SIOCGIFHWADDR: No such device

```

Er kommt ja noch nicht mal dazu eine dhcp Anfrage zu senden.

----------

## Anarcho

Klappt denn die VPN Verbindung?

Wird das tap0 device erstellt?

ifconfig -a

Starte auf dem Server openvpn mal aus der Konsole, dann zeigt es verbindungsinformationen an. Gucke dort mal ob eine Verbindung hergestellt wird.

----------

## aZZe

Auf dem Server scheint es ja zu klappen. Dort hab ich ein tap0 mit der Adresse 10.1.0.1:

```

tap0      Protokoll:Ethernet  Hardware Adresse 00:FF:E5:97:2E:55

          inet Adresse:10.1.0.1  Bcast:10.1.0.255  Maske:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          Kollisionen:0 Sendewarteschlangenlänge:100

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

```

----------

## Anarcho

OK, 

da gibt es auch nur selten ein Problem...

Interessanter ist die Client-Seite.

----------

## AustrianCoder

Tja.. evt kann mir mal jemand helfen. Ich hänge schon bei den ersten Schritten, und zwar beim erstellen der Zertifikate.

openssl ca -out server.crt -in server.csr 

--->

```

x-factor ssl # openssl ca -out server.crt -in server.csr

Using configuration from /etc/ssl/openssl.cnf

Error opening CA private key ./demoCA/private/my-ca.key

16590:error:02001002:system library:fopen:No such file or directory:bss_file.c:278:fopen('./demoCA/private/my-ca.key','r')

16590:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:280:

unable to load CA private key

```

Das /etc/ssl Verzechnis sieht so aus:

```

drwxr-xr-x  2 root root 1760 Mar 18 15:47 certs

drwxr-xr-x  3 root root  136 Mar 18 15:07 demoCA

drwxr-xr-x  2 root root   48 Nov 20 13:58 lib

drwxr-xr-x  2 root root  216 Mar 13 23:30 misc

-rw-r--r--  1 root root 1281 Mar 19 11:33 my-ca.crt

-rw-r--r--  1 root root 1675 Mar 19 11:33 my-ca.key

-rw-r--r--  1 root root 7789 Mar 18 15:54 openssl.cnf

-rw-------  1 root root 7783 Mar 16 00:45 openssl.cnf.save

drwxr-xr-x  2 root root   48 Nov 20 13:58 private

-rw-r--r--  1 root root  936 Mar 19 11:34 server.csr

-rw-r--r--  1 root root 1675 Mar 19 11:34 server.key

```

Und hier noch meine openssl.cnf:

 *Quote:*   

> 
> 
> ####################################################################
> 
> [ ca ]
> ...

 

Ich weiß echt nicht, warum die Daten nicht in demoCA abgelegt werden  :Sad: 

```

*  dev-libs/openssl

      Latest version available: 0.9.7e

      Latest version installed: 0.9.7e

      Size of downloaded files: 5,105 kB

      Homepage:    http://www.openssl.org/

      Description: Toolkit for SSL v2/v3 and TLS v1

      License:     as-is

```

Danke, AC

----------

## Anarcho

Entweder du verschiebst die Datein:

cd /etc/ssl

mv my-* private demoCA/

oder du editierst die openssl.cnf und änderst ./demoCA in ./

----------

## Neo_0815

Frage: Welchen Vorteil siehst du, OpenVPN zu nutzen anstatt die native IPSec Implementierung + racoon?

MfG

----------

## Anarcho

OpenVPN läuft im Userspace und benötigt daher keine Kernelanpassung oder UNterstützung durch andere Betriebssysteme. Es muss sich nur die Software  installieren lassen.

Dadurch hat es eine grosse Unabhängigkeit und Skalierbarkeit.

Dazu kommt noch beim Kernel 2.6 IPSec das es mit den Tunneln Probleme im Zusammenspiel mit iptables gibt. Das ist bei OpenVPN nicht der Fall. 

Zudem ist es sehr einfach zu installieren und läuft fast überall (Linux, Windows 2000/XP and higher, OpenBSD, FreeBSD, NetBSD, Mac OS X, and Solaris)

Zudem ist es genauso sicher wie IPSec.

----------

## Neo_0815

 *Anarcho wrote:*   

> OpenVPN läuft im Userspace und benötigt daher keine Kernelanpassung oder UNterstützung durch andere Betriebssysteme. Es muss sich nur die Software  installieren lassen.
> 
> Dadurch hat es eine grosse Unabhängigkeit und Skalierbarkeit.
> 
> Dazu kommt noch beim Kernel 2.6 IPSec das es mit den Tunneln Probleme im Zusammenspiel mit iptables gibt. Das ist bei OpenVPN nicht der Fall. 
> ...

 

Was für Tunnel Probleme? Die Anpassungen sind denke ich vertretbar ... aber das ist jedem seine Entscheidung.

MfG

----------

## Anarcho

Im Linux-Magazin hatten sie geschrieben das IPSec Pakete nur mit erheblichem Aufwand filterbar sind, da das Paket erst nach der Filterung durch iptables ausgepackt wird. Daher hat iptables dann keinen Einfluss mehr darauf. 

Das ist bei OpenVPN anders, da dann vom tap0 device aus geroutet wird und somit die Pakete schon entpackt vorliegen und gefiltert werden können.

----------

## Neo_0815

Den Artikel habe ich gelesen - mal sehn obs noch stimmt  :Wink: .

MfG

----------

## Anarcho

Der ist noch nicht so alt, da wird sich wohl nicht viel getan haben.

Daher finde ich die OpenVPN Lösung genauso sicher aber einfacher zu installieren und zu benutzen.

----------

## Neo_0815

Naja das Mark Target war als umständlich beschrieben, die IPSec Policy war aber als adäquat genannt ... ich werd mich melden sobald ich live ausprobiert habe obs wirklich so schwer ist, derzeit nutze ich ja den nativen Stack schon für ESP Pakete, nur der Router muss noch dran kommen - mal sehn wies wird.

Denn dann finde ich ist es so schon besser, da Kernel Space meist schneller läuft als Userspace, siehe pppoe im Kernel / Userland, die im Kernel sind zig mal schneller.

MfG

----------

## Anarcho

Naja,

aber der Trend geht schon in Richtung Userland, siehe udev. 

Und generell kann man das auch nicht sagen das kernelspace schneller ist als userspace.

Und die einfache Installation ist schon ein wichtiges Argument. Ebenso die Portablilität,

z.b. wenn jetzt jemand mit nem Fedaro Core 2 connecten möchte und der keinen IPSec-Unterstützung im Kernel hat (keine Ahnung ob FC2 jetzt IPSec drinne hat oder nicht, ist nur ein Beispiel), er aber auch den Kernel nicht neukompilieren will (Firmenpolitik, Können, etc.) , geht es nicht.

Mit OpenVPN ist es egal welchen Kernel er einsetzt und welches OS ebenfalls.

----------

## Neo_0815

Die Portabilität ist nat. ein sehr gutes Argument stimmt - nunja ich werde auf jeden Fall beide Lsg. mal austesten und dann mal schauen was sich besser macht,.

MfG

----------

## Anarcho

Ich bin natürlich auch für andere Lösungen offen. Wenn du es mal durchtestest wäre ich für einen Kommentar dankbar!

Und ob das mit iptables nun geht oder nicht würde mich auch interessieren.

----------

## daemonb

habe seit ca einem halben jahr openvpn mit meinem wlan laufen und bin eher unzufrieden.

Habe unter windows schon alles mögliche probiert und habe immer mit verbindungsabbrüchen oder routingfehler zu kämpfen die keine sind.

Werde nächste WE mal forschen was ich noch machen kann, habe aber langsa genug und werde denke ich evtl mal mit ipsec und l2tp probieren was zu reissen....

Lasse mich mal überraschen....

bis denne

DaemonB

----------

## Anarcho

Bei mir läuft das jetzt seit Anfang des Jahres und ich kann deine Probleme nicht bestätigen. Bisher gab es nicht ein Problem. 

Was ich mir bei dir vorstellen kann wäre ein Verlust der Leitung auf Grund zu schwacher WLAN-Leistung. 

Wobei da gerade das auf UDP basierende OpenVPN weniger Probleme machen sollte (würde ich meinen).

----------

## daemonb

habe das problem ja nur mit dem einen windowsXP laptop.

Zuerst ging es garnicht, das lag aber daran das da SP2 drauf war.

Also deinstalliert und dann gings erst, jetzt zickt er immer rum, vonwegen routing problem packet lost....

Denke es liegt evtl auch an der Kerio FW oder ähnlichem....

Mit meinem Powerbook geht es eigentlich relativ stressfrei.

----------

## Neo_0815

@Anarcho: Kannst du eingentlich eine Lastaussage treffen?

Bei meinem P90 verbraucht ipsec mit ESP ca. 0.4 load average im Vergleich zu kein ipsec, ist openvpn besser oder schlechter? Bei schlechter scheidet es nämlich eh aus.

MfG

----------

## Anarcho

@Neo

für nen richtigen Test sollten wir wohl die Art des testes abstimmen.

Bei mir läuft es auf einem Athlon XP 2000+ mit 1 GB RAM. Aber dort läuft noch ne ganze menge anderes Zeug. Ich kann dir aber sagen wieviel CPU der openvpn-daemon nimmt.

Ist dein Wert unter Netzwerkvolllast oder unter normallast?

Edit:

Unter fast DSL-Vollast (ca. 300 kb/s) liegt der openvpn daemon bei max. 2% CPU

----------

## Neo_0815

Geht alles mittlerweile.

Größter Vorteil die Performance, IPSec frißt definitv das xx-fache im Gegensatz zu OpenVPN, das Argument für den armen P90  :Wink: .

Ein Problem gibts aber noch: Openvpn erstellt auf dem Client das tap1 Device nicht schnell genug so das das Init Script zum starten von tap1 scheitert ... was den Bootvergang verewigt da die Netzanbindung fehlt, wie kann man das beheben?

Ein sleep in den Startscripten hilft nicht.

Gruß

----------

## AcheronH

@Anarcho:

Wie siehts eigentlich aus, wenn bei deiner config das tap device mal verschwindet? Wenn ich die OpenVPN Doku richtig verstehe könnte das ja passieren, wenn OpenVPN-Server und -Client sich mal nicht mehr verstehen (einfach zu triggern, indem man die Uhrzeit mal deutlich verstellt bzw den Dienst auf dem Server einfach mal neu startet). Schonmal Probleme gehabt oder funktioniert das immer sauber? 

Ich hab das so ähnlich aufgesetzt wie du (bin zu spät auf deine FAQ gestoßen), hab aber dazu auf dem Server das WLAN mit dem LAN als bridge zusammengeführt. Das funktioniert auch recht gut, nur hab ich auf den clients keine init-scripte für tap0 sondern lasse das als route-up script vom openvpn aus starten.

Das hat bei mir den Vorteil, dass ich mit dem Notebook sowohl aus dem LAN als auch WLAN dieselbe IPV4-Adresse habe (die er vom LAN-dhcp bezieht).

Bei Interesse kann ich die configs mal posten.

----------

## Neo_0815

Naja nein die Bridge nutze ich nicht, ich route korrekt und gut.

Aber das mit dem Device ist so, wenn openvpn startet dauert es lange bis der Kernel das Device anlegt oder udev, einer von beiden mehrt, ich habe jetzt per Hand "provide, use" Direktiven in die Startscripte so eingebaut, das das Device da ist wie es soll.

Ein "sleep" im openvon hat nix geholfen, sehr interessantes Problem ...

MfG

----------

## AcheronH

 *Neo_0815 wrote:*   

> Naja nein die Bridge nutze ich nicht, ich route korrekt und gut.
> 
> Aber das mit dem Device ist so, wenn openvpn startet dauert es lange bis der Kernel das Device anlegt oder udev, einer von beiden mehrt, ich habe jetzt per Hand "provide, use" Direktiven in die Startscripte so eingebaut, das das Device da ist wie es soll.
> 
> Ein "sleep" im openvon hat nix geholfen, sehr interessantes Problem ...
> ...

 

Mein Post bezog sich auch weniger auf dein Problem. Nach deiner Aussage nehme ich an, dass du das Problem jetzt aber gelöst hast. Ansonsten fällt mir nur noch eine recht hässliche Lösung ein: man könnte z.B. in der Konfigurationsdatei vom OpenVPN-Client im "up" oder "route-up" script ein flagfile (bzw. flagdirectory, mkdir=atomar?) setzen lassen, worauf dann die folgenden initscripte testen könnten. Aber solche Kapriolen sollte man soweit möglich vermeiden.

----------

## Anarcho

Komisch,

@neo: schön das es bei dir klappt. Das der Unterschied an CPU-Last so deutlich ist, hätte ich nicht vermutet.

Aber ich habe keinerlei solche probleme mit nicht vorhandensein des tap-devices gehabt.

Und zum Thema verbindungsabbruch: Damit habe ich sehr gute Erfahrung gemacht:

Wenn ich mein Notebook mit suspend-to-disk ausschalte und wieder hochfahre, dann denkt der Server ja, das während das Notebook aus ist, das die Verbindung abgebrochen ist. Aber wenn ich es wieder hochfahre, dann wird die Verbindung ja nicht manuell wiederhergestellt, da der openvpn daemon ja noch läuft. Dieser baut dann selbstständig die Verbindung wieder her. Man muss nur kurz warten.

----------

## benjamin200

Auf dieses Howto sollte in "Dokumentationen & Tipps & Tricks" gelinked werden.

Gruß,

Benjamin

----------

## Squiddle

kommt das auch ins wiki? www.gentoo-wiki.com

----------

## Anarcho

Werde das mal ins WIKI stellen, wenn ich zeit habe.

----------

## Neo_0815

 *Anarcho wrote:*   

> Komisch,
> 
> @neo: schön das es bei dir klappt. Das der Unterschied an CPU-Last so deutlich ist, hätte ich nicht vermutet.
> 
> Aber ich habe keinerlei solche probleme mit nicht vorhandensein des tap-devices gehabt.
> ...

 

Naja das Deviceinit Script ist zu fix an der Reihe, da ist OpenVPN noch am Erzeugen ... daher ist es nicht da.

Gruß

----------

## Squiddle

Ich hab mal angefangen, ich hoffe das ist ok.

http://de.gentoo-wiki.com/Wlan_mit_OpenVPN_sch%C3%BCtzen

----------

## Anarcho

Sieht doch schon ganz gut aus.

Ich habe noch den Eintrag zu den Kernelvorraussetzungen geändert, denn bei neueren Kerneln braucht man support für das Universal TUN/TAP Device.

Ich meine das ich das damals nicht gebraucht habe, werde aber nochmal nen alten Kernel testen.

----------

## AcheronH

 *Anarcho wrote:*   

> 
> 
> [...]
> 
> Und zum Thema verbindungsabbruch: Damit habe ich sehr gute Erfahrung gemacht:
> ...

 

Man sollte einfach nicht so früh am Tag ins Forum schreiben, da hapert es immer mit dem Nachdenken.  :Wink: 

Ich sehe den Unterschied in unseren Konfigurationen: du erstellst das tap device auf den clients per Init-Script, bei mir wird das jeweils von openvpn verwaltet. Daher wirst du client-seitig keine Probleme damit haben, denn das tap-device startet sich ja auch beim boot aus dem suspend per initscript wieder einen dhcpcd (?).

Was mich aber immer noch interessiert ist, was passiert wenn du den openvpn-server neu startest. Läuft es dann auch problemlos weiter? Der dhcpcd, der auf dem tap-device läuft, ist dann vermutlich schon weg und würde sich keine neue Adresse holen oder liege ich da falsch?

Ausserdem: ich sehe, dass du in deiner Server-Config kein client-to-client keyword hast. Sollen sich deine WLAN-clients nicht gegenseitig sehen? Tun sie es auch ohne das keyword (bei mir nicht...)?

Hast du bei dir Verbindungen ins LAN vorgesehen, oder willst du die Netze absolut trennen? 

Fragen über Fragen...  :Smile: 

----------

## Neo_0815

 *AcheronH wrote:*   

>  *Anarcho wrote:*   
> 
> [...]
> 
> Und zum Thema verbindungsabbruch: Damit habe ich sehr gute Erfahrung gemacht:
> ...

 

Geht mit den richtign Routen ohne Probleme, das ist vom OpevVPN nicht abhängig.

MfG

----------

## AcheronH

 *Neo_0815 wrote:*   

>  *AcheronH wrote:*   
> 
> Hast du bei dir Verbindungen ins LAN vorgesehen, oder willst du die Netze absolut trennen? 
> 
> Fragen über Fragen...  
> ...

 

Warum willst du dafür ip-routing bemühen - das wäre doch ein ziemlich krasser Umweg?

Mir gehts auch unter anderem um direkten Zugriff im Ethernet, nicht auf IP-Ebene.

Für den Fall, dass man mal D**m übers Netz zocken will, ohne dass man lange vorbereiten müsste.  :Wink: 

----------

## Anarcho

Da müsste ich mal ethereal anwerfen wie Client-to-Client Traffic verläuft. 

Aber mir ist Client-to-Client Traffic egal, denn bei mir geht es nur um den Server (Fileserver und Router)

und das neustarten des Servers halte ich für unwahrscheinlich bzw. noch aus anderen Gründen für sehr schlecht, daher würde mir im Falle des neustarten des Servers sowieso ein wenig Handarbeit nicht erspart. 

Wenn dein Server ständig neustartet, machst du was falsch  :Twisted Evil: 

----------

## AustrianCoder

Hallo zusammen. Nachdem das OpenVPN 2.0 ebuild im portage ist, möchte ich diesen Sonntag gerne das VPN zum laufen bringen. Doch ich scheitere schon an OpenSSL  :Embarassed: 

So, dann hier mal die Änderungen in der OpenSSL config:

 *Quote:*   

> 
> 
> [ CA_default ]
> 
> dir             = ./demoCA              # Where everything is kept
> ...

 

So nun Schritt für Schritt was ich nun mache.... (putty log)

 *Quote:*   

> 
> 
> x-factor ssl # ls
> 
> certs  misc  openssl.cnf  private  privkey.pem
> ...

 

So.. nun steh ich an... wer kann mir nun einen Tipp geben?

Merci

----------

## Anarcho

Du hast das aktuelle CA-Dir als relativen Pfad angegeben (./demoCA) daher ist es wichtig in welchem Verzeichnis du dich gerade befindest.

Du solltest dir am besten vorher ein Verzeichnis anlegen (z.b. /usr/ssl/myCA) und das dann als absoluten Pfad eintragen.

----------

## AustrianCoder

Hmm.. habe nun das in der openssl.cnf:

dir             = /usr/ssl/myCA

Das Verzeichnis existiert auch, doch es wird da nichts gepseichert:

 *Quote:*   

> 
> 
> x-factor ssl # openssl req -nodes -new -keyout server.key -out server.csr
> 
> Generating a 2048 bit RSA private key
> ...

 

x-factor ssl # pwd

/etc/ssl

----------

## toskala

huhu,

ist es eigentlich wurst was für einen wlan router man seither hatte? ich habe hier einen wrt54gs rumstehen von linksys, könnte ich den für solche aktionen auch gebrauchen?

cheerios,

toskala

----------

## Sumpfdrache

Wie ist das denn, wenn mein Accesspoint am Switch hängt und als Default-Gateway meinen Router hat, dann sollte das grundsätzlich (mit entsprechenden Modifikationen) doch auch gehen, oder?

----------

## Neo_0815

 *toskala wrote:*   

> huhu,
> 
> ist es eigentlich wurst was für einen wlan router man seither hatte? ich habe hier einen wrt54gs rumstehen von linksys, könnte ich den für solche aktionen auch gebrauchen?
> 
> cheerios,
> ...

 

Jup, kannst du. Müßtest nur ein entsprechnendes Image zimmern das den Support hat und dann per Firmware Update aufspielen, man kann das ja bei der Linksys Reihe.

Das Freifunk Projekt machts ja auch so.

Gruß

----------

## toskala

 *Neo_0815 wrote:*   

>  *toskala wrote:*   huhu,
> 
> ist es eigentlich wurst was für einen wlan router man seither hatte? ich habe hier einen wrt54gs rumstehen von linksys, könnte ich den für solche aktionen auch gebrauchen?
> 
> cheerios,
> ...

 

ah, okay, ich verwende den nämlich derzeit mit openwrt. gibt es denn da fertige images? also ich meine klar, ich könnte die bridge entkoppeln, so dass er ein reiner AP ist, aber gibts da anleitungen wie man das genau mit einem wrt54gs macht?

----------

## Neo_0815

Da bin ich überfragt im Moment, aber geben wird es sie denke ich mal bestimmt. 

Gruß

----------

## Anarcho

 *Sumpfdrache wrote:*   

> Wie ist das denn, wenn mein Accesspoint am Switch hängt und als Default-Gateway meinen Router hat, dann sollte das grundsätzlich (mit entsprechenden Modifikationen) doch auch gehen, oder?

 

Nun, was in deinem AP eingetragen ist, ist relativ egal, da dieser ja nicht für's routen zuständig ist. Die Einstellungen dort beziehen sich nur auf das Webinterface bzw. den HTTP-Server der dahinter steckt. 

Wenn du nun ein Packet verschickst, dann wird das ja vom AP auf MAC-Ebene versendet und nicht auf IP-Ebene. 

Allerdings muss dein Router ein Linux-Router sein (oder vergleichbares) denn dort muss dann OpenVPN drauf laufen.

----------

## Sumpfdrache

 *Anarcho wrote:*   

> 
> 
> Nun, was in deinem AP eingetragen ist, ist relativ egal, da dieser ja nicht für's routen zuständig ist. Die Einstellungen dort beziehen sich nur auf das Webinterface bzw. den HTTP-Server der dahinter steckt. 
> 
> Wenn du nun ein Packet verschickst, dann wird das ja vom AP auf MAC-Ebene versendet und nicht auf IP-Ebene. 
> ...

 

Ah ja. Na ja hab da (Accesspoint) Default-GW gesehen und Default-GW gedacht...

Der Router "dahinter" ist natürlich ein linuxoider. Dachte halt ich käm um die dritte Netzwerkkarte rum, aber das komm ich ja auch, weil ich ja für die AP-Mac (die ja nunmal auf meinen Router zugreifen muß, sonst surf ich über jemand anderen  :Laughing:  ) filtern kann, na ja sag ich jetzt mal so...*grübel*

...ich denk mal drüber fest nach und meld mich denn wieder  :Very Happy: 

----------

## LL0rd

hmm..... anscheinend habe ich das gleiche Problem, wie AustrianCoder

```
openssl ca -out server.crt -in server.csr

Using configuration from /etc/ssl/openssl.cnf

/etc/ssl/myCA/index.txt: No such file or directory

unable to open '/etc/ssl/myCA/index.txt'

2314:error:02001002:system library:fopen:No such file or directory:bss_file.c:278:fopen('/etc/ssl/myCA/index.txt','r')

2314:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:280:

```

was ist das denn und wie kann ich es beheben?

----------

## Neo_0815

 *LL0rd wrote:*   

> hmm..... anscheinend habe ich das gleiche Problem, wie AustrianCoder
> 
> ```
> openssl ca -out server.crt -in server.csr
> 
> ...

 

http://www.pseudonym.org/ssl/ssl_env.html

Lies dort gleich den ersten Absatz, da steht was die index.txt ist und auch wie man es behebt, Suchmaschinen helfen ab und an auch mal ...

Gruß

----------

## LL0rd

Jau, ich habs schon hinbekommen.....

doch leider hat mir google dabei auch nicht weitergeholfen  :Wink:  (Aber touch  :Very Happy:  )

----------

## Neo_0815

Boah, wie googlest du denn ... "openssl index.txt" suchen und gleich der erste Treffer ists, man oh man.

Gruß

----------

## Massimo B.

Jetzt hab ich es nach einem Tag Arbeit fast geschafft, scheitere aber an der Verbindung:

Der Server meldet beim Verbinden des Clients

```
TLS ERROR: first response local/remote key_method mismatch, local key_method=1, op=P_CONTROL_HARD_RESET_CLIENT_V2
```

Der Client beendet nach einiger Zeit:

```
WARNING: file 'client.key' is group or others accessible

LZO compression initialized

TUN/TAP device tap0 opened

GID set to nobody

UID set to nobody

UDPv4 link local (bound): [undef]:1194

 UDPv4 link remote: 192.168.168.202:5000

read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

read UDPv4 [ECONNREFUSED]: Connection refused (code=111)

[...]

read UDPv4 [ECONNREFUSED]: Connection refused (code=111)Fri Jun  3 21:09:15 2005 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

TLS Error: TLS handshake failed

SIGUSR1[soft,tls-error] received, process restarting

WARNING: you are using user/group/chroot without persist-key/persist-tun -- this may cause restarts to fail

WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.

WARNING: file 'client.key' is group or others accessible

LZO compression initialized

Note: Cannot open TUN/TAP dev /dev/net/tun: Permission denied (errno=13)

Note: Attempting fallback to kernel 2.2 TUN/TAP interface

Cannot allocate TUN/TAP dev dynamically

Exiting
```

Meine Umgebung ist ein openvpn-1.6 Server auf Mandrake mit einem neuen openvpn-2.0 client auf Gentoo.

Ist dabei etwas zu beachten? Auf dem Server mußte ich in der local.conf neben duplicate-cn auch folgende Zeile auskommentieren, weil er sie nicht kennt:

```
#mode server
```

Weil die Anleitung bei mir nicht ganz gepaßt hat, hab ich bei Mandrake mit einem Perl-skript CA.pl die Dateien erstellt:

```
usage: CA -newcert|-newreq|-newreq-nodes|-newca|-sign|-verify
```

Anmerkung zur Howto:

- server local.conf -> mode server: paßt bei meinem openvpn-1.6 nicht

- das rc-skript sucht standardmäßig in /etc/openvpn nach .conf, nicht /etc/openvpn/wireless

- client local.conf -> laptop.crt:  sollte client.crt lauten, wie im Schritt vorher

 *Anarcho wrote:*   

> Dachte halt ich käm um die dritte Netzwerkkarte rum

 

Also ich verwende den WLAN-Router auch als Router: Feste IP am WAN-Port, dann an Switch. Die iptables-Regeln stelle ich zwischen WAN und LAN des Routers ein, so daß nur VPN über den Accesspoint möglich ist. Ist das sicher? So hab ich mir das 3. Interface am Linux-Router gespart, und nutze die Funktion des WLAN-Routers.

Ttrotzdem danke für die howto.

Gruß,

----------

## Anarcho

 *Quote:*   

> - server local.conf -> mode server: paßt bei meinem openvpn-1.6 nicht
> 
> - das rc-skript sucht standardmäßig in /etc/openvpn nach .conf, nicht /etc/openvpn/wireless 

 

Das es nicht mit OpenVPN 1.6 läuft hatte ich aber erwähnt, daher damals auch OpenVPN 2.0 Beta

und mein Init-script unter gentoo sucht in den unterverzeichnissen.

 *Quote:*   

> - client local.conf -> laptop.crt: sollte client.crt lauten, wie im Schritt vorher

 

Ist korrigiert.

 *Quote:*   

> Dachte halt ich käm um die dritte Netzwerkkarte rum

  das ist nicht von mir, bitte korrigiere doch deinen Thread.

Zu deinem Problem:

Seit openVPN 2.0 haben sich die Standardports geändert. Hast du beim Server und Client den Port eingestellt?

----------

## padarasa

Hi,

also ich habe mein VPN nun so weit, dass es *fast* funktioniert. Irgendetwas stimmt bei meinen iptables-Regeln nicht:

Mit dem Laptop ohne VPN kann ich den Server nicht mehr anpingen, keine ssh-Verbindung mehr aufbauen usw... Aber: Ich kann immernoch ins Internet?

Soblad ich das VPN und net.tap0 starte kann ich den Server wieder anpingen usw.

Meine Konfiguration:

Server: eth0 -> Inet ; eth1 -> 192.168.0.1 (kabel) ; eth2 -> 192.168.2.1 (wlan bzw. vpn)

Mein Firewallscript:

```

# Interface-name (Device der aktuellen Verbindung, z.B. ppp0)

DEV_INET=$1

# local-IP-address (IP-Adresse, die wir vom Provider zuegwiesen bekommen

# haben

IP_INET=$4

# remote-IP-address (unsere Gegenstelle beim Provider)

IP_GATEWAY=$5

IPTABLES=/usr/sbin/iptables

echo 0 > /proc/sys/net/ipv4/ip_forward

modprobe ip_tables &> /dev/null

modprobe ip_conntrack &> /dev/null

modprobe ip_conntrack_ftp &> /dev/null

modprobe ipt_state &> /dev/null

modprobe iptable_nat &> /dev/null

modprobe ipt_REJECT &> /dev/null

modprobe ipt_MASQUERADE  &> /dev/null

$IPTABLES -F

$IPTABLES -X

$IPTABLES -F -t filter

$IPTABLES -F -t nat

$IPTABLES -F -t mangle

$IPTABLES -t filter -X

$IPTABLES -t nat -X

$IPTABLES -t mangle -X

$IPTABLES -P INPUT ACCEPT

$IPTABLES -P FORWARD ACCEPT

$IPTABLES -P OUTPUT ACCEPT

$IPTABLES -t nat -A POSTROUTING -o $DEV_INET -j MASQUERADE

$IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

$IPTABLES -A INPUT -i $DEV_INET -m state --state NEW,INVALID -j REJECT

$IPTABLES -A FORWARD -i $DEV_INET -m state --state NEW,INVALID -j REJECT

iptables -t filter -A INPUT --protocol udp --dport 5000 -j ACCEPT -i eth2

iptables -t filter -A INPUT -j REJECT -i eth2

echo 1 > /proc/sys/net/ipv4/ip_forward

```

Wie gesagt, alle Serverdienste kann ich per WLAN ohne VPN nicht mehr erreichen (so wie sein soll), also nfs, ssh usw. Aber aus irgendwelchen Gründen kann ich ohne VPN trotzdem problemlos ins Internet.

Ich vermute, dass im obigen Script ein Fehler vorliegt - ich find ihn nun nicht  :Sad: . 

Vielleicht weiß ja jemand wo das Problem liegt und kann mir helfen *hoff*

----------

## linpacman

Hallo

Ich habe seit einiger Zeit mein WLAN zum Notebook mit Hilfe dieses Howtos durch OpenVPN geschützt. Bisher lief auch alles einwandfrei, jedoch habe ich jetzt die interne WLAN Karte, welche bisher als Access Point diente, gegen eine normale Netzwerkkarte getauscht und an diese einen Netgear Access Point angeschlossen.

Seitdem besteht das Problem, daß zwar sämtliche Verbindungen laufen, jedoch bricht die Verbindung zu einem nfs Server im Lan zusammen, sobald ein Datentransfer gestartet wird. Im Log steht nur: nfs server not responding, still trying

Breche ich den Transfer ab, wird der nfs Server wieder gefunden: nfs server OK

Ein Transfer vom Samba Server läuft nach wie vor ohne Probleme. Beende ich OpenVPN und verbinde mich direkt mit dem Access Point, läuft auch der nfs Transfer so wie es vorher auch durch den VPN Tunnel möglich war.

Woran kann das liegen oder wie kann ich den Fehler genauer einkreisen?

----------

## Anarcho

 *padarasa wrote:*   

> Hi,
> 
> also ich habe mein VPN nun so weit, dass es *fast* funktioniert. Irgendetwas stimmt bei meinen iptables-Regeln nicht:
> 
> Mit dem Laptop ohne VPN kann ich den Server nicht mehr anpingen, keine ssh-Verbindung mehr aufbauen usw... Aber: Ich kann immernoch ins Internet?
> ...

 

Du solltest die Default-regel für FORWARD auf DROP stellen und dann das interene LAN erlauben, statefull erlauben und alle über tap0 laufenden Verbindungen erlauben.

Hier mal mein firewall-script. Ist sicherlich auch nicht das Non-Plus-Ultra, aber für meine Zwecke reicht es:

```
#/bin/bash

# Flushing

iptables -F INPUT

iptables -F FORWARD

iptables -t nat -F POSTROUTING

iptables -F LOG_DROP

iptables -X LOG_DROP

echo 1 > /proc/sys/net/ipv4/ip_forward

if [ "$1" == "stop" ]; then

   iptables -P INPUT ACCEPT

   iptables -P FORWARD ACCEPT

   exit 0

fi

# define some variables

LAN=eth2

WLAN=eth1

INET=ppp0

VPNS="tap+"

AP_IP="192.168.1.245"

# Logging

iptables -N LOG_DROP

iptables -A LOG_DROP -j LOG --log-tcp-options --log-ip-options --log-prefix '[IPTABLES DROP] : '

iptables -A LOG_DROP -j DROP

### INPUT ####

# standart auf drop setzen

iptables -P INPUT DROP 

# alle lokalen verbindungen erlauben

iptables -A INPUT -j ACCEPT -i $LAN

iptables -A INPUT -j ACCEPT -i lo

iptables -A INPUT -i $VPNS -j ACCEPT

#einzelne Ports nach aussen öffnen

iptables -A INPUT --protocol tcp --dport 50145 -j ACCEPT -i $INET   # für Azureus

iptables -A INPUT --protocol tcp --dport 80 -j ACCEPT -i $INET      # Apache

iptables -A INPUT --protocol tcp --dport 22 -j ACCEPT -i $INET      # SSH

iptables -A INPUT --protocol tcp --dport 25 -j ACCEPT -i $INET      # SMTP

# iptables -A INPUT --protocol tcp --dport 465 -j ACCEPT -i $INET   # SMTPs

iptables -A INPUT --protocol tcp --dport 993 -j ACCEPT -i $INET   # IMAPs

iptables -A INPUT --protocol udp --dport 993 -j ACCEPT -i $INET   # IMAPs

iptables -A INPUT --protocol tcp --dport 995 -j ACCEPT -i $INET   # POP3s

iptables -A INPUT --protocol udp --dport 995 -j ACCEPT -i $INET   # POP3s

iptables -A INPUT --protocol tcp --dport 9552 -j ACCEPT -i $INET   # mldonkey

iptables -A INPUT --protocol udp --dport 9556 -j ACCEPT -i $INET   # mldonkey

#iptables -A INPUT --protocol tcp --dport 22333 -j ACCEPT -i $INET   # mein C-Server

iptables -A INPUT --protocol icmp -j ACCEPT -i $INET         # Ping erlauben

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -i $INET   # aktive verbindungen erlauben

#iptables -A INPUT -i $WLAN -j ACCEPT # for testing only

iptables -A INPUT --protocol udp --dport 5000 -j ACCEPT -i $WLAN   # enable openvpn

#iptables -A INPUT --protocol tcp --dport 80 -j ACCEPT -i $WLAN -d 192.168.1.1 # enable local webserver to download files

#iptables -A INPUT -j LOG_DROP

iptables -A INPUT -j REJECT

### FORWARD ####

iptables -P FORWARD DROP

iptables -A FORWARD -i $LAN -j ACCEPT   # alle Verbindungen aus dem lokalen Netz erlauben

iptables -A FORWARD -i $VPNS -j ACCEPT   # alle Verbindungen von VPN Interfaces erlauben

iptables -A FORWARD -i lo -j ACCEPT   # localhost erlauben

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT -i $INET      # aktive verbindungen erlauben

iptables -A FORWARD -i $WLAN --protocol tcp --sport 80 -s $AP_IP -j ACCEPT   # Verbindungen vom LAN zum AP Webinterface erlauben

### NAT ####

# For internetsharing/Masquerading

iptables -t nat -A POSTROUTING -j MASQUERADE -o $INET   # DSL Masquerading

iptables -t nat -A POSTROUTING -j MASQUERADE -o tap1   # Masquerading fürs externe VPN Netz zur Onkochemie
```

Ich hoffe es ist einigermassen selbsterklärend. Sonst frag nach.

----------

## linpacman

Ich habe den Fehler gefunden, wieso kein Datentransfer über den VPN Tunnel zu einem NFS Server möglich war. Es lag an der fragment Größe, welche ich nun in der Server und Client Config auf 1200 gesetzt habe. Nach der Änderung ist ein Transfer vom/zum NFS Server problemlos möglich.

----------

## toskala

also soweit so gut. nun hab ich mir nen AP geholt alles feinstens confed und unter windows bekomme ich dann vom client in der dosbox folgende fehlermeldung, leider hab ich keine wirkliche idee warum, kann mir vielleicht jemand weiterhelfen?

cheerios,

toskala

die meldung des windows clients:

```

write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)

```

die config files sehen wie folgt aus:

```
spiderman wireless # cat /etc/openvpn/wireless/local.conf

dev tap

ifconfig 10.1.0.1 255.255.255.0

mode server

tls-server

dh dh2048.pem

ca my-ca.crt

cert server.crt

key server.key

tun-mtu 1500

mssfix 1400

comp-lzo

tls-auth /etc/openvpn/wireless/wireless.key 0

duplicate-cn

chroot /etc/openvpn/wireless/newroot

user nobody

group nobody

```

```
spiderman wireless # cat /etc/dhcp/dhcpd.conf

# Netzwerk des VPN

subnet 10.1.0.0 netmask 255.255.255.0

{

        range 10.1.0.12 10.1.0.120;

        option domain-name-servers 145.253.2.203, 145.253.2.171;

        option routers 10.1.0.1;

        option broadcast-address 10.1.0.255;

}
```

```
spiderman wireless # ifconfig

eth0      Link encap:Ethernet  HWaddr 00:01:02:17:8C:D6

          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:40554 errors:0 dropped:0 overruns:1 frame:0

          TX packets:43679 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:5535901 (5.2 Mb)  TX bytes:17706601 (16.8 Mb)

          Interrupt:9 Base address:0xb800

eth2      Link encap:Ethernet  HWaddr 00:04:75:E6:26:67

          inet addr:10.10.10.10  Bcast:10.10.10.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:28 errors:0 dropped:0 overruns:0 frame:0

          TX packets:109 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:1680 (1.6 Kb)  TX bytes:8988 (8.7 Kb)

          Interrupt:10 Base address:0xa400

tap0      Link encap:Ethernet  HWaddr 12:6C:D5:75:28:A9

          inet addr:10.1.0.1  Bcast:10.1.0.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

```

und hier noch die firewall die ich seither immer verwendet habe.

```
#!/bin/bash

LOCALHOST=127.0.0.1

MYIP=192.168.0.1

INTERN=192.168.0.0/24

ALL=0.0.0.0/0

UNPRIV=1024:65535

PRIV=0:1023

IINTERFACE=ppp0

case "$1" in

    start)

        iptables -F INPUT

        iptables -F OUTPUT

        iptables -F FORWARD

        iptables -P INPUT DROP

        iptables -P OUTPUT ACCEPT

        iptables -P FORWARD ACCEPT

        echo 1 > /proc/sys/net/ipv4/ip_forward

        echo 1 > /proc/sys/net/ipv4/tcp_syncookies

        echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

        echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

        for f in /proc/sys/net/ipv4/conf/*/accept_redirects

        do

                echo 0 > $f

        done

        for f in /proc/sys/net/ipv4/conf/*/accept_source_route

        do

                echo 0 > $f

        done

        iptables -A INPUT -i lo -j ACCEPT

        iptables -A INPUT -p tcp -s $INTERN -d $INTERN -j ACCEPT

        iptables -A INPUT -p udp -s $INTERN -d $INTERN -j ACCEPT

        iptables -A INPUT -p icmp -s $INTERN -d $INTERN -j ACCEPT

        iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

        iptables -A INPUT -p icmp --icmp-type echo-reply                -j ACCEPT       # type  0

        iptables -A INPUT -p icmp --icmp-type source-quench             -j ACCEPT       # type  4

        iptables -A INPUT -p icmp --icmp-type time-exceeded             -j ACCEPT       # type 11

        iptables -A INPUT -p icmp --icmp-type parameter-problem         -j ACCEPT       # type 12

        iptables -A INPUT -p icmp --icmp-type fragmentation-needed      -j ACCEPT       # type  3

        iptables -A INPUT -p icmp --icmp-type port-unreachable          -j ACCEPT       # type  3

        #openvpn regel

        iptables -A INPUT --protocol udp --dport 5000 -j ACCEPT -i eth2

        iptables -A INPUT -j DROP -i eth2

        iptables -A INPUT -j DROP

        iptables -t nat -A POSTROUTING -s $INTERN -o $IINTERFACE -j MASQUERADE

        ;;

    stop)

        iptables -F INPUT

        iptables -F OUTPUT

        iptables -F FORWARD

        iptables -A INPUT -j ACCEPT

        iptables -A OUTPUT -j ACCEPT

        iptables -A FORWARD -j DROP

        ;;

    *)

        echo Usage: firewall start/stop

esac
```

----------

## Anarcho

 *toskala wrote:*   

> die meldung des windows clients:
> 
> ```
> 
> write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)
> ...

 

Das sieht nach nem generellen Netzwerkproblem aus. Entweder du bist nicht verbunden oder im falschen Adressraum.

Zeig dochmal die Einstellungen vom WindowsClient bzw. versuch mal den Server zu pingen ohne VPN.

Wenn ich das richtig gesehen habe erlaubst du ja ICMP.

----------

## toskala

hmm, naja, ich kann den server nicht pingen. die wlan karte hat laut ipconfig auch keine ip adresse bekommen *wunder*

muss ich vorher die wlan karte manuell auf dem AP einbuchen damit das ganze funktioniert?

also falls ja, spielt es denn eine rolle ob ich das mit dem windows werkzeug für drahtlose netze mache oder mit dem mitgelieferten intel software werkzeug?

ich werd das alles aber erst morgen wieder testen, ich muss früh raus und nu is schon kurz vor 00:00 *schauder*  :Smile: 

cheerios,

toskala

----------

## Anarcho

Also du musst natürlich vorher ganz normal mit dem AP verbunden sein. Das heisst etwaige Schlüssel (WEP/WPA) müssen eingerichtet sein, die SSID und der Channel ebenso. Dann brauchst du ne IP für das normale Interface sonst finden die OpenVPN Pakete ihren Weg ja nicht. Erst dann wird der VPN Tunnel aufgebaut und ab dann sollte dein Default-GW das andere Ende des Tunnels sein, damit alle Pakete über den Tunnel gehen.

----------

## toskala

ah okay, dann steckt da wohl das problem.

aus irgendeinem stumpfen grund will sich dieses scheisstool was bei der wlan-karte dabei war, welches den windows konfig dialog abgestellt hat, nicht mit dem ap verbinden. also naja, trotz fest eingestellter ip adresse, also gleiches netz wie der ap auch is, behauptet das ding zwar "verbindung hergestellt" aber es vergibt eine IP aus dem bereich 169.irgendwas und das passt absolut gar nicht zu meinem netz.

also wenn ich das korrekt verstehe:

die wlan karte muss verbindung zum AP haben, den AP kann ich im besten fall pingen, und auf port 1194 oder eben 5000 lass ich auf der anderen IP den openvpn horchen?

falls dem so ist stehen mir ja noch lustige stunden bevor damit das windows dingens endlich die wlan karte ordentlich verbindet... *grummel* ich probier das gleich heut abend mal aus  :Wink: 

----------

## Anarcho

Das siehst du richtig. Wobei ein kleiner Fehler noch drin steckt:

(Der AP hat nur ne IP für das Webinterface. Theoretisch kannst du dem, wenn du nicht mehr aufs Webinterface zugreifen mussst, jede beliebige IP geben. Hauptsache die IP mit dem Rechner auf der anderen Seite stimmt, also dem auf dem OpenVPN läuft. Aber in der Regel hat der AP eine IP aus dem gleichen Subnet.)

Und per Firewall kannst du dann alles ausser Port 1194 (5000) verbieten, ebenso Forwarding.

----------

## LL0rd

Anarcho, du kannst mir evtl. noch bei meinem kleinen Problem helfen. Aus irgendeinem Grund bekommt openvpn keine Verbindung mehr zum Server. 

```
Sep  9 12:53:00 book openvpn[8051]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Sep  9 12:53:00 book openvpn[8051]: TLS Error: TLS handshake failed
```

Diese Meldung taucht so einige Male auf, alle 60 Secs. Nach ca. 5 Mal auftauchen ist das tap0 Interface auch weg. Diese Meldung taucht so oft auf, bis ich openvon restartet habe. Danach geht alles wieder. Das Problem scheint auch nicht am WLAN zu hängen. Ich habe das gleiche Problem auch, wenn ich mein Notebook per Kabel an den AP anschließe. Neben Linux habe ich bei mir auf dem Notebook auch noch Windows drauf. Unter Windows funzt openvpn ohne Probleme (auch über WLAN) wenn die WLAN Verbindung sogar unterbrochen wird, dann passiert nichts mit den aktuellen Datentransfers (wenn die Unterbrechung kurz ist), die werden nach der wiederherstellung der Verbindung einfach wieder fortgesetzt.

----------

## Anarcho

Hi,

Also wenn ich das richtig verstehe, dann klappt es ne zeit lang und dann tauchen die Fehler auf, richtig?

Dann musst du restarten und dann geht es wieder ne Zeit lang.

Kann es sein das es immer ca. ne Stunde lang geht und dann die Verbindung abbricht?

hast du vielleicht was an den Firewall einstellungen geändert?

Poste mal deine .conf vom Client (bei dem Taucht das ja in den Meldungen auf, oder?)

----------

## toskala

so,

also die verbindung klappt nun mit dem openvpn server. allerdings scheint das mit dem dhcp und dem routing nicht hinhauen zu wollen.

ich bekomme vom openvpn folgende meldung

```
initialization sequence completed
```

allerdings geht dies nur, wenn ich diesem tunnel device eine feste IP aus dem vpn bereich gebe. der dhcp wird irgendwie noch nicht durchgeroutet, respektive er lauscht noch nicht am korrekten interface.

das dürfte aber auch erstmal noch kein problem sein, da ich eine korrekte feste IP aus dem vpn netz vergeben habe.

vpn netz hat die 10.1.0.0/24 

das tap0 device am server hat 10.1.0.1

das tunnel device am client hat 10.1.0.100 von mir zugewiesen bekommen und als default gw 10.1.0.1.

problem ist nun allerdings, ich kann weder das zugewiesene default gw 10.1.0.1 pingen noch sonstwas.

woran könnte der schotter denn liegen?

----------

## toskala

hmmmm kommando zurück.

also ich kann allerdings sehr wohl ins internet.

also ein ping www.linux.de

ist erfolgreich von der windows karre aus.

um sicherzugehen, dass auch mein vpn tunnel device verwendet wird hab ich frecherweise einen "tracert www.heise.de" gemacht, da wird mir in der ersten zeile auch direkt als 1. hop 10.1.0.1 angegeben.

alsogut, es geht nu über den tunnel.

wie aber komme ich nun noch an den rest meines lans welches in 192.168.0.0/24 sich befindet?

irgendwie bin ich grade saublöd oder total puzzled  :Smile: 

----------

## Anarcho

Zum DHCP:

Der Daemon muss nach dem OpenVPN gestartet werden bzw. das tap0 device muss schon existieren wenn dhcp gestartet wird. 

Alternativ dazu kann man auch einfach das OpenVPN interne DHCP verwenden (ab Version 2.0 erst glaube ich):

statt:

```
ifconfig 10.1.0.1 255.255.255.0
```

eintragen:

```
server 10.8.0.0 255.255.255.0
```

und den Eintrag tls-server entfernen.

Dann kann man noch das default gw und den DNS Server "pushen":

```
push "redirect-gateway def1"

push "dhcp-option DNS 10.1.0.1"
```

Zum "nicht pingen":

Hast du vielleicht per Firewall ping verboten oder sogar noch mehr eingeschränkt?

Was sagt denn 

iptables -L -v

----------

## toskala

porr ey... dont drink and root sach ich hier nur...

klar, ich hatte vergessen in meiner firewall folgendes zu erlauben:

```
        iptables -A INPUT -p tcp -s $VPN -d $INTERN -j ACCEPT

        iptables -A INPUT -p udp -s $VPN -d $INTERN -j ACCEPT

        iptables -A INPUT -p icmp -s $VPN -d $INTERN -j ACCEPT
```

es funktioniert nun also auch schonmal dieses, nun muss nur noch das dhcp geraffel gelöst werden dann hab ichs. *weiterbastel*

----------

## LL0rd

Also die config sieht so aus:

```
dev tap

# IP des Servers

remote 192.168.1.1 1194

tun-mtu 1500

mssfix 1400

tls-client

ca /etc/openvpn/wireless/my-ca.crt

cert /etc/openvpn/wireless/laptop.crt

key /etc/openvpn/wireless/laptop.key

# Kompression der Daten

comp-lzo

# Optional, siehe oben

tls-auth /etc/openvpn/wireless/wireless.key 1

user nobody

group nobody

```

Die Verbindung wird in ziehmlich unregelmäßigen Abständen abgebrochen. Manchmal sind es 40 min, manchmal sinds 10 Stunden

----------

## toskala

so nun hab ichs komplett.

nun geht auch dhcp. also ja, ich sollte vielleicht in zukunft erstmal die kranken firewall geschichten abstellen, kucken obs geht und danach weiterbasteln.

achja, vielleicht noch die eine oder andere ergänzug fürs howto:

1. erwähne vielleicht noch direkt, dass man für einen dhcp server noch in der /etc/conf.d/dhcp noch das eth2 tap0 device eintragen muss

2. vielleicht noch kurz die anmerkungen reintackern wenn die serial, index.txt usw. beim zertifikat erzeugen fehlen

3. man kann die certs nicht signen wenn man bei beiden client und server exakt die selben daten verwendet

ich glaub das wars? darüber bin ich ad hoc gestolpert. aber sonst super howto  :Smile: 

----------

## Anarcho

Ja stimmt, der Zertifikat-Teil ist ein wenig kurz geraten. Ich werde das ganze bald mal Grundüberholen.

Dann kommen auch Infos zum Thema revocation lists dazu.

Aber erst wenn ich meinen ISDN Netzwerk Anrufmonitor mit GTK Fenster am Client und 64x128 Pixel externem LCD am Server und MySQL Namesauflösung vom Webinterface fertig habe... (Ich hoffe das LCD kommt morgen)

----------

## Anarcho

 *LL0rd wrote:*   

> Also die config sieht so aus:
> 
> ```
> dev tap
> 
> ...

 

Hm, sieht vernünftig aus. 

Du könntest OpenVPN am Client mal in der Konsole starten (als root natürlich):

```
cd /etc/openvpn/wireless

openvpn --config local.conf --verb 3
```

Und dann warten bis der Fehler auftaucht. Poste dann mal die letzten Zeilen.

Vielleicht läuft das WLAN unter Windows aber auch einfach stabiler und daher taucht der Fehler da nicht auf.

----------

## toskala

hey hey,

ein bug/problem ist mir noch aufgefallen. und zwar wenn ich auf meinem client das interface tap0 so adde wie du im howto beschrieben hast, dann bootet mein notebook nich mehr sondern hängt sich weg genau dann, wenn irgendein dienst gestartet wird der auf need_net verweist.

booten im interactive mode und alle netzwerk-dienste skippen und ein 

```
rc-update del net.tap0 default
```

hat das problem dann gelöst.

ich verwende hier eine intel ipw2100 karte die, starte ich das device manuell, auch wunderbar funktioniert.

ich schau mal ob ich den fehler hierbei noch finde  :Smile: 

oh, wichtig: ich fahre auf dem notebook unstable  :Smile:  also von dem her, ich weiss was ich da tue und wenns ärger gibt kanns durchaus daran liegen  :Smile: .

----------

## Anarcho

Auf dem Laptop, auf dem das OpenVPN nach meiner Anleitung läuft, ist noch das alte Baselayout drauf. 

Vielleicht liegt es ja auch daran.

In welcher Reihenfolge werden denn die Dienste bei dir gestartet (net.eth0, openvpn, net.tap0)?

----------

## l3u

Ich hab mal gehört, daß auf der AVM FritzBox auch ne Linux-Variante läuft. Könnte man mit dem Ding theoretisch auch ein VPN-Netzwerk aufziehen? Also ohne, daß ständig ein Computer als Router läuft?

----------

## LL0rd

wird schwer...... auch wenn es möglich ist linux auf dem router zu installieren, wird der Speicherplatz für openvpn und alles was dazugehört scheitern.

----------

## Anarcho

Ich kenn mich mit der Fritzbox nicht aus, aber unter OpenWRT für manche WLAN-Router kannst du sehr wohl OpenVPN installieren.

----------

## LL0rd

Anarcho, ich habe openvpn nun per Hand gestartet. Schau mal, was er mir (nach ca. 7 Stunden) gesagt hat:

http://staff.rootix.de/openvpn.jpg

----------

## Anarcho

Alles klar,

war wie ich mir schon dachte:

Du wechselst nach dem starten von root zum User Nobody, was auch richtig so ist. Jedoch wird irgendwann die Verbindung resetet und dann muss das key-file neu eingelesen werden. Auf Grund der Zugriffsgeschränkungen geht das aber nicht mehr und daher bricht die Verbindung ab. Beim neustarten wird das file als root neu eingelesen und es klappt wieder usw.

Füge also folgende Zeilen in die local.conf mit ein:

persist-key

persist-tun

Dann sollte es gehen. Ich werde das auf der Hauptseite hinzufügen.

----------

## Mgiese

kurze einfache frage:

tracert x.com geht nicht, ich habe kein tracert .. wieso ? ist das nicht standard ? habe 40gb standard opensource auf dem computer und kein tracert dabei ???

wozu sind dann all die 1000 netzwertools ? ich versteh das nicht...

----------

## LL0rd

lol.. versuchs mal mit "traceroute"

----------

## Anarcho

@LLord:

Läuft es nun stabil?

@Mgiese:

Ich frage mich zwar ernsthaft ob du wirklich 40GB software drauf hast, aber das tool ist im Paket traceroute und muss erst installiert werden.

----------

## LL0rd

ja, die Verbindung ist nun stabil - DANKE!!! -, aber irgendwie stimmt bei mir etwas mit dem Routing nicht.... einige, wenige seiten sind vom Laptop aus nicht erreichbar... Keine Ahnung wieso...

----------

## Cpt_McLane

hi...

habe es soweit geschafft, das der Rechner am AP mit meinem Laptop per VPN übers WLAN kommuniziert. 

Nun wollte ich in einen weiteren Rechner an das VPN anbinden ("Normaler" PC, also kein Laptop) mit einer Ethernet/WLAN Bridge.

Habe dort aber das Problem, das OpenVPN das /dev/net/tun device nicht findet:

```
Oct 31 08:09:53 [openvpn] Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

Oct 31 08:09:53 [openvpn] Note: Attempting fallback to kernel 2.2 TUN/TAP interface

Oct 31 08:09:53 [openvpn] Cannot allocate TUN/TAP dev dynamically

Oct 31 08:09:53 [openvpn] Exiting

```

allerdings gibt ifconfg   -a u. a. folgendes aus:

```
tunl0     Link encap:IPIP Tunnel  HWaddr

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
```

hab's mit einem Vanilla 2.6.11.4 und jetzt mit einem 2.6.13-gentoo-r5 Kernel probiert, Ergebnis ist immer das gleiche. Was mich wundert, da der Laptop und der Server hinter dem AP ebenfalls 2.6.23-gentoo-5 als Kernel haben und dort OpenVPN diesen Fehler nicht meldet.

Wenn jmd. was einfällt, bin für jede Idee dankbar...

MfG McLane

----------

## LL0rd

ähm... es sieht so aus, als hättest du kein TUN Device in deinem Kernel. Überpfüf das mal bitte.

----------

## Cpt_McLane

danke für die Hilfe, sorry, dass ich erst jetzt antworte, war auf arbeit...

```
Device Drivers  --->

  Networking support  --->

    Networking options  --->

      <*>   IP: tunneling
```

und ifconfig tunl0 gibt mir

```
tunl0     Link encap:IPIP Tunnel  HWaddr

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
```

leider ist es wohl nicht ganz so einfach...

[edit]

ja, wenn man nochmal ne nacht drüber schläft, gehts meist besser... natürlich, das TUN/TAP Device... (eigen blödheit, das zu übersehen)

```
Device Drivers  --->

  Networking support  --->

    <M>   Universal TUN/TAP device driver support
```

das hatte ich bis eben nicht an. hab gerade das modul kompiliert und geladen und siehe da, ich hab ein /dev/net/tun node und openvpn startet ohne probleme...

----------

## Cpt_McLane

moin,

wie aus vorigem Beitrag ersichtlich funktioniert mein VPN über das WLAN nun. Ich bin bis auf ein paar Abweichungen strikt nach dem Howto vorgegangen, hab nur meine systemspezifischen Angaben (die Netzwerkkarten und IP-Adressen geändert, kein DHCP genutzt) angepasst. Dennoch bin ich auf ein paar Probleme gestoßen. Hier meine Lösungen:

Beim Erstellten der Zertifikate unbedingt alle Angaben ausfüllen, sonst steigt openssl mit einer Warnung aus und erstellt zwar die Dateien, aber mit leerem Inhalt

Beim Erstellen der Zertifikate kommt Fehlermeldung, dass index.txt nicht gefunden wurde

Dies lässt sich beheben, indem einfach die Datei erstellt wird:

```
touch index.txt
```

Beim Erstellen der Zertifikate kommt Fehlermeldung, dass serial nicht gelesen werden kann. 

diese Datei muss mit Inhalt 02 erstellt werden:

```
echo "02" > serial
```

Beim Erstellen des Clientzertifikats schimpft openssl dann, dass es mit dem inhalt der index.txt nichts anfangen kann. also wieder löschen und leer neu anlegen. (Anmerkung: Ich bin in Sachen openssl und ssl allgemein sehr unerfahren, wenn jmd. weiß was openssl mir hier sagen wollte, bin ich sehr dankbar. Da es aber funktioniert mache ich mir erstmal keinen Kopf drum   :Wink:  )

```
rm index.txt

touch index.txt
```

OpenVPN Client kann nicht zum Server verbinden.

Mittlerweile hat OpenVPN einen offiziellen Port zugewiesen gekriegt, der nun auch standardmäßig verwendet wird.  In der Client Konfiguration muss hinter der IP des OpenVPN Server der Port 5000 durch 1194 ersetzt werden. Dies sollte dann dementsprechend auch im IPTables Script erledigt werden.

Erweiterungsvorschlag: Der Server hinter dem AP ist ja nun durch iptables "abgedichtet" allerdings sind die Clients im WLAN noch offen.

Hier kann ebenfalls fast aller Verkehr über das normale Interface abgewiesen werden:

```
iptables -t filter -A INPUT --protocol udp --sport 1194 -j ACCEPT -i eth1 # eth1 ist das Interface an dem der AP hängt

iptables -t filter -A INPUT -j REJECT -i eth1 #oder -j DROP, je nach Geschmack

/etc/init.d/iptables save 

```

Das waren nun allesamt die Probleme mit denen ich gekämpft habe und wie ich sie behoben habe. Ob irgendein Vorgehen an dieser Stelle grundsätzlich falsch war weiß ich nicht.

MfG McLane

----------

## LL0rd

Hi,

deshalb habe ich ja auch gesagt, dass das TUN/TAP modul fehlt  :Wink: 

Nun habe ich jetzt aber auch ein Problem mit VPN, bzw. mit dem Routing. Ich habe bei mir auf dem Laptop derzeit Windows XP. Ich würde gerne eine Verbindung vom Uni Netz zu mir nach Hause herstellen. Nur leider funktioniert das nicht richtig. 

Die OpenVPN Verbindung soll so laufen.

WLAN Karte -> offenes WLAN -> (Cisco IPsec) VPN ins Internet -> OpenVPN nach Hause

Über das VPN nach Hause will ich nur auf die Rechner zugreifen, nicht online gehen. Die Verbindung zum OpenVPN Server wird aufgebaut, nur kann ich leider auf die Rechner zu Hause nicht zugreifen. Das Netzwerkinterface ist gestartet und hat sich sogar die IP vom DHCP besorgt.  Die Rechner sind einfach nicht pingbar. Gehe ich aber einen anderen Weg:

WLAN Karte -> offenes WLAN (WebAuth) ->  OpenVPN nach Hause

Dann kann ich normal auf das Netz zugreifen. Nur leider ist der Traffic zum AP nicht verschlüsselt und das sollte schon sein. Was kann / muss ich denn jetzt machen, damit ich auf das VPN Netz zugreifen kann? Ich vermute, es liegt an der Routing Tabelle. Die sieht nämlich so aus, als hätte da eine Bombe eingeschlagen:

```

===========================================================================

Schnittstellenliste

0x1 ........................... MS TCP Loopback interface

0x2 ...00 0c f1 11 aa df ...... Intel(R) PRO/Wireless LAN 2100 3B Mini PCI Adap

er - Paketplaner-Miniport

0x3 ...00 0f b5 23 b3 4e ...... NETGEAR 108 Mbps Wireless PC Card WG511T - Pake

planer-Miniport

0x4 ...00 00 f0 7e f2 a2 ...... Realtek RTL8139-Familie-PCI-Fast Ethernet-NIC -

Paketplaner-Miniport

0x5 ...00 ff b0 74 62 d0 ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport

0x20007 ...00 05 9a 3c 78 00 ...... Cisco Systems VPN Adapter - Paketplaner-Min

port

===========================================================================

===========================================================================

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl

          0.0.0.0          0.0.0.0         10.1.0.1       10.1.0.30       30

          0.0.0.0          0.0.0.0    129.13.78.243   129.13.78.243       1

          0.0.0.0          0.0.0.0   193.196.44.254  193.196.44.220       25

         10.0.0.0        255.0.0.0        10.1.0.30       10.1.0.30       30

         10.0.0.0        255.0.0.0   193.196.44.254  193.196.44.220       1

        10.1.0.30  255.255.255.255        127.0.0.1       127.0.0.1       30

   10.255.255.255  255.255.255.255        10.1.0.30       10.1.0.30       30

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

       129.13.0.0      255.255.0.0    129.13.78.243   129.13.78.243       25

      129.13.72.1  255.255.255.255   193.196.44.254  193.196.44.220       1

    129.13.78.243  255.255.255.255        127.0.0.1       127.0.0.1       25

     129.13.239.0    255.255.255.0   193.196.44.254  193.196.44.220       1

     129.13.240.0    255.255.248.0   193.196.44.254  193.196.44.220       1

   129.13.255.255  255.255.255.255    129.13.78.243   129.13.78.243       25

      172.21.12.0    255.255.252.0   193.196.44.254  193.196.44.220       1

    172.21.64.246  255.255.255.255   193.196.44.254  193.196.44.220       1

   193.196.44.128  255.255.255.128   193.196.44.220  193.196.44.220       25

   193.196.44.128  255.255.255.128    129.13.78.243   129.13.78.243       1

   193.196.44.220  255.255.255.255        127.0.0.1       127.0.0.1       25

   193.196.44.254  255.255.255.255   193.196.44.220  193.196.44.220       1

   193.196.44.255  255.255.255.255   193.196.44.220  193.196.44.220       25

        224.0.0.0        240.0.0.0        10.1.0.30       10.1.0.30       30

        224.0.0.0        240.0.0.0    129.13.78.243   129.13.78.243       25

        224.0.0.0        240.0.0.0   193.196.44.220  193.196.44.220       25

  255.255.255.255  255.255.255.255        10.1.0.30               2       1

  255.255.255.255  255.255.255.255        10.1.0.30       10.1.0.30       1

  255.255.255.255  255.255.255.255        10.1.0.30               4       1

  255.255.255.255  255.255.255.255    129.13.78.243   129.13.78.243       1

  255.255.255.255  255.255.255.255   193.196.44.220  193.196.44.220       1

Standardgateway:     129.13.78.243

===========================================================================

Ständige Routen:

  Keine

```

WLAN Karte: 193.196.44.220

IPSec VPN: 129.13.78.243

Interne IP des Notebooks im VPN Netz: 10.1.0.30

Interne IP des VPN Servers im VPN Netz: 10.1.0.1

Das Netz hat IP Adressen aus dem Bereich 10.0.0.x

----------

## Anarcho

Für die Einwahl von ausserhalb würde ich eine etwas andere OpenVPN Konfiguration nehmen. Dieses HowTO ist speziell für den Internetzugang über VPN gedacht. 

Ich würde ein 2. VPN laufen lassen auf einem anderen Port der nach aussen offen ist und natürlich auch ein anderes Subnetz verwendet. 

Die dhcp config würde ich so anpassen das über dieses netzwerk kein standardgateway verwendet wird aber openvpn eine route für das interne Netzwerk pushed.

----------

## LL0rd

ok, gesagt, getan. Aber es geht trotzdem irgendwie nicht. Windows scheint die Route irgendwie durcheinander zu bringen. Ich habe jetzt im DHCPD einfach das Standartgateway gekillt und einen zweiten VPN Daemon gestartet, der auf einem anderen Port lauscht und ein anderes IP Netz ist. Nur leider habe ich da das gleiche Problem. Authe ich mich am Web Server, so kann ich problemlos die VPN Verbindung herstellen. Wenn ich nun aber das ganze über die VPN Verbindung versuche, bekomme ich zwar noch die IP Adresse vom DHCP Server, aber das wars auch schon.

Genau das gleiche habe ich auch, wenn ich mich mit dem VPN Server des Unternehmens verbinden will, bei dem ich arbeite (IPSec). 

BTW. Ich dachte, dass es daran liegt, dass er nicht das VPN Gateway nimmt, sondern direlt über die WLAN Karte rausgehen will, aber das ist auch nicht der fall. Ich habe sowohl den Tunnel aufgebaut, als mich auch übers WEB Authentifiziert. Same...

----------

## eGore911

Folgendes wäre besser:

/etc/conf.d/net

```
ifconfig_tap0=( "dhcp" )

depend_tap0() {

        need openvpn

}

```

und dann:

```
cd /etc/init.d

ln -s net.lo net.tap0

rc-update add net.tap0 default

```

----------

## Treborius

ich stehe gerade völlig auf dem schlauch,

bei mir sieht das setup ein wenig anders aus, meine gentoo box fungiert schon als wlan router

ich habe also 

eth0 ==> WAN

ath0 ==> WLAN

eth0 <==> ath0

vor kurzem habe ich openvpn eingerichtet um ein paar services die auf eth0 laufen zu verschlüsseln

(ssh und svn verbindungen)

openvpn lauscht dabei nur auf verbindungen auf eth0

nach dem lesen dieses tutorials würde nun gerne auch sämtlichen wlan0 verkehr über openvpn laufen lassen, 

kann mir aber nichtmal die netzwerkarchitektur so richtig vorstellen   :Embarassed: 

ath0 hat immer eine statische ip, 

wlan-verbindungen werden per hostapd (WPA2) verteilt,

dhcpd vergibt dann im wlan die ips

meine gedanken waren nun folgende :

jeglichen traffic auf ath0 blocken, und nur verbindungen auf dem openvpn port zulassen,

dann das routing nichtmehr auf ath0 sondern auf tun0 umlenken

kann ich mir dann eigentlich den dhcpd irgendwie sparen? 

(eigentlich ja nicht, ich brauch ja erstmal ne ip um eine openvpn verbindung zu bekommen)

würde das so funktionieren? oder denke ich gerade in die völlig falsche richtung?

edit : warum ich das machen möchte ist folgendes : 

der router hat nur 500MHz und stösst dabei manchmal an seine grenzen wenn ich zB scp zum filetransfer verwende

vpn verbindungen kann ich aber imho über die geode-aes-engine in hardware verschlüsseln

----------

## LL0rd

Hi,

im Grunde hast du schon recht mit dem, was du da geschrieben hast. Allerdings habe ich das Gefühl, dass du die Interfaces etwas durcheinander wirfst. Deshalb mal eine kurze Erklärung. In dem Accesspoint (oder Router) hast du drei wichtige Netzwerkkarten. Einmal ist es die WLAN Karte, die WAN Verbindung zur Außenwelt und das VPN Interface.

Das Setup sagt jetzt folgendes:

Ein Client verbindet sich nun ohne eine Authentifizierung zum AP. Das ist auch in Ordnung so, jedoch darf er ausschließlich auf den VPN Server zugreifen. Deshalb werden alle Ports auf dem WLAN Interface gesperrt, außer dem Port für die VPN Verbindung und DHCP. 

Hat ein Client sich jedoch auf dem VPN Server authentifiziert, so kann der Client das AP nicht nur über den WLAN Adapter erreichen, sondern ZUSÄTZLICH auch über das VPN Interface. Deshalb richtet man hier in der Regel auch ein Routing ein, dass der Client z.B. ins Internet gelangen kann. Das richtet man auf dem AP VPN Interface ein.

Wieso du dir den DHCP sparen möchtest, verstehe ich nicht so ganz. Der DHCP bringt Komfort. Was die geode-aes-engine betrifft, so kann ich dir da nicht wirklich helfen. Ich habe leider keine großen Erfahrungen mit Hardware-Verschlüsselungskarten.

----------

## Treborius

 *LL0rd wrote:*   

> 
> 
> Wieso du dir den DHCP sparen möchtest, verstehe ich nicht so ganz. Der DHCP bringt Komfort. Was die geode-aes-engine betrifft, so kann ich dir da nicht wirklich helfen. Ich habe leider keine großen Erfahrungen mit Hardware-Verschlüsselungskarten.

 

war blödsinn was ich geschrieben habe, hab nur mal wieder was durcheinander geworfen

- dhcpcd läuft dann auf eth0 und holt ip vom modem ( als client)

- dhcpd läuft dann auf ath0 und vergibt ips für (als server für die clients im wlan)

- der interne dhcp von openvpn vergibt dann die ips für die clients im vpn

ich muss mir das mal aufmalen, aber danke, 

hab ich am wochenende was vor    :Smile: 

edit : 

kann ich nach diesem setup dann nicht sogar WPA2 und sogar WEP völlig weglassen?

kann mir ja egal sein wer sich aus meiner näheren umgebung dann im WLAN anmeldet

er hat ja nur zugriff auf den VPN port

----------

## LL0rd

 *Treborius wrote:*   

> 
> 
> kann ich nach diesem setup dann nicht sogar WPA2 und sogar WEP völlig weglassen?
> 
> kann mir ja egal sein wer sich aus meiner näheren umgebung dann im WLAN anmeldet
> ...

 

Sorry, hab dein Edit jetzt erst gesehen.

Also WEP ist ja volle Kanne für die Tonne, ob du auf WPA(2) verzichten kannst, kannst du nur selbst beurteilen, denn es kommt darauf an, was du schützen möchtest.

Ich möchte es dir mal verdeutlichen.

Ich habe an meinem WLAN "normale" Rechner angeschlossen, Smartphones, WLAN Kameras, Drucker, die PS3 und meinen Fernseher. Einige der Geräte möchten nur ins Internet gehen oder auf "unwichtige" Ressourcen des Netzwerks zugreifen. Was ich gemacht habe ist, dass ich das WLAN WPA2 verschlüsselt habe. Hat man die WPA2 Barriere überwunden, dann bekommt man Zugriff auf das Internet + auf die NAS mit Filmen, MP3 Files, etc. Die Rechner sind dan per Client Separation voneinander getrennt. Hat man sich zusätzlich per VPN authentifiziert, so hat man zusätzlich noch den Zugriff auf den Fileserver mit wichtigen Daten sowie auf die anderen Rechner.

----------

