# Openvpn...

## sewulba

Hallo...

Ich weiss, dass das kein Gentoospezifisches Problem bei mir ist. Allerdings brauch ich eure Hilfe, weil ich einfach nicht mehr weiter komme.

Ich kann mich mit dem OpenVPN-Server verbinden. Soweit kein Problem.

eth0 = 192.168.0.11, tap0 = 192.168.1.1

Ich bekomme dann eine IP zugewiesen, beispielsweise 192.168.1.4.

Ping auf 192.168.0.11 geht, ping auf 192.168.1.1 geht auch, aber ping auf 192.168.0.250 (Router an dem das OpenVPN-Kistel hängt.)

Was muss ich noch eintragen, und wo, damit ich ins komplette 192.168.0.x-Netz reinkomme über den Openvpn-Server?

Gruss Sewulba   :Wink: 

----------

## Anarcho

Ich denke folgendes:

1. Auf dem OpenVPN Server muss ip forwarding an sein

2. Auf dem Client muss für das 192.168.0.0/24 Subnetz der OpenVPN Server als gateway eingestellt sein

3. Auf dem Zielrechner muss das 192.168.1.0/24 Subnetz mit Gateway bekannt gemacht werden (ausser der OpenVPN Server ist bereits default gw)

----------

## sewulba

ok...

Das habe ich soweit ausprobiert. Aber es will einfach nicht gehen. Ich komme höchstens noch auf die IP 192.168.0.11. Dann ist aber schluss.   :Embarassed: 

Gruss Sewulba

----------

## Anarcho

Dann brauchen wir etwas genauere Informationen:

Die Ausgabe von alle 3 Systemen (Quelle, Router, Ziel)

1. ifconfig -a

2. route -n

Am router noch

1. cat /proc/sys/net/ipv4/ip_forward

2. iptables -L -v

----------

## sewulba

 *Anarcho wrote:*   

> Dann brauchen wir etwas genauere Informationen:
> 
> Die Ausgabe von alle 3 Systemen (Quelle, Router, Ziel)
> 
> 1. ifconfig -a
> ...

 

Ok...

```
PPro:/home/ruedi# ifconfig -a

eth0      Protokoll:Ethernet  Hardware Adresse 00:E0:7D:7D:54:E5

          inet Adresse:192.168.0.11  Bcast:192.168.0.255  Maske:255.255.255.0

          inet6 Adresse: fe80::2e0:7dff:fe7d:54e5/64 GÃ¼ltigkeitsbereich:Verbind                                             ung

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          Kollisionen:0 SendewarteschlangenlÃ¤nge:1000

          RX bytes:213928 (208.9 KiB)  TX bytes:373600 (364.8 KiB)

          Interrupt:185 Basisadresse:0x6000

lo        Protokoll:Lokale Schleife

          inet Adresse:127.0.0.1  Maske:255.0.0.0

          inet6 Adresse: ::1/128 GÃ¼ltigkeitsbereich:Maschine

          UP LOOPBACK RUNNING  MTU:16436  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:0

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

sit0      Protokoll:IPv6-nach-IPv4

          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

          Kollisionen:0 SendewarteschlangenlÃ¤nge:0

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

tap0      Protokoll:Ethernet  Hardware Adresse CE:FB:56:BC:F2:F7

          inet Adresse:192.168.1.1  Bcast:192.168.1.255  Maske:255.255.255.0

          inet6 Adresse: fe80::ccfb:56ff:febc:f2f7/64 GÃ¼ltigkeitsbereich:Verbin                                             dung

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

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

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

          Kollisionen:0 SendewarteschlangenlÃ¤nge:100

          RX bytes:0 (0.0 b)  TX bytes:2799 (2.7 KiB)
```

```
PPro:/home/ruedi# route -n

Kernel IP Routentabelle

Ziel            Router          Genmask         Flags Metric Ref    Use Iface

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth0
```

```
PPro:/home/ruedi# cat /proc/sys/net/ipv4/ip_forward

1
```

```
PPro:/home/ruedi# iptables -L -v

Chain INPUT (policy ACCEPT 738 packets, 150K bytes)

 pkts bytes target     prot opt in     out     source               destination

   13  2041 ACCEPT     0    --  tap0   any     anywhere             anywhere

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere

Chain OUTPUT (policy ACCEPT 853 packets, 366K bytes)

 pkts bytes target     prot opt in     out     source               destination

   15  2121 ACCEPT     0    --  any    tap0    anywhere             anywhere
```

Ich hoffe das hilft weiter...   :Wink: 

Gruss Sewulba

----------

## think4urs11

 *sewulba wrote:*   

> Ich hoffe das hilft weiter...  
> 
> 

 

Nein, denn  *Anarcho wrote:*   

> Die Ausgabe von allen 3 Systemen (Quelle, Router, Ziel)

 

Zusätzlich noch die OpenVPN-Config für den Fall das da was vergessen wurde.

----------

## 69719

Ich denke mir mal das default GW sollte 192.168.1.1 statt 192.168.0.254 sein?

----------

## sewulba

 *Think4UrS11 wrote:*   

>  *sewulba wrote:*   Ich hoffe das hilft weiter...  
> 
>  
> 
> Nein, denn  *Anarcho wrote:*   Die Ausgabe von allen 3 Systemen (Quelle, Router, Ziel) 
> ...

 

Hier nun die OpenVPN-Config

```
# Port

port 1194

# TCP oder UDP?

#proto tcp-server

proto udp

mode server

tls-server

# tun oder tap?

# Das tun Device erstellt einen IP Tunnel,

# wäend das tap Device einen Ethernet Tunnel erstellt.

#tun or tap device

#tun is an IP tunnel,

#tap an ethernet tunnel

dev tap

#Our Server IP

ifconfig 192.168.1.1 255.255.255.0

#dynamic clients from 10.0.0.2-10.0.0.254

ifconfig-pool 192.168.1.2 192.168.1.254

#Die pakete werden auf dieser grögekapselt

tun-mtu 1500

#fragment 1300

mssfix

#Paths to the certs

ca certs/vpn-ca.pem

cert certs/servercert.pem

key certs/serverkey.pem

#Clients kön miteinander kommunizieren

client-to-client

#Diffie-Hellmann Parameters

dh certs/dh1024.pem

#Same Ip in the next session

ifconfig-pool-persist ipp.txt

# RouteUP

up /etc/openvpn/route.up

#Routes the packages to the intern network, you should use iptables instead of this

# push "route 192.168.0.0 255.255.255.0 192.168.1.1"

# route 192.168.0.0 255.255.255.0 192.168.1.1

#Tests the connection with a ping like paket. (wait=120sec)

keepalive 10 120

#Authenication

auth SHA1

#Our encryption algorithm

cipher aes-256-cbc

#openvpn --show-ciphers for testing

#comp

comp-lzo

#Sets new rights after the connection

user nobody

group nogroup

#We need this because of user nobody/group nobody.

persist-key

persist-tun

#Logging 0, (testing:5)

verb 4

# Set Server as Gateway for Clients

push "route 192.168.1.0 255.255.255.0 192.168.1.1"

#route 192.168.0.0 255.255.255.0 192.168.1.1

# Logdatei

log /var/log/openvpn/openvpn.log

status /var/log/openvpn/openvpn-status.log
```

Hier noch die route.up-Datei

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

/sbin/iptables -A INPUT -i tap0 -j ACCEPT

/sbin/iptables -A FORWARD -i tap0 -j ACCEPT

/sbin/iptables -A OUTPUT -o tap0 -j ACCEPT

```

----------

## sewulba

 *escor wrote:*   

> Ich denke mir mal das default GW sollte 192.168.1.1 statt 192.168.0.254 sein?

 

Der 192.168.0.254 ist der Router fürs Internet.

----------

## think4urs11

ifconfig -a und route -n von Client und dem Router (.0.254) fehlen zwar immer noch aber so wie ich das sehe hat der Client schlicht keine Route zu 192.168.0.0/24.

Sowohl der Client braucht eine Route zu 192.168.0.0/24 als auch der Router umgekehrt eine zu 192.168.1.0/24 via 192.168.0.11, dann klappt das auch mit dem Nachbarn.

----------

## sewulba

 *Think4UrS11 wrote:*   

> ifconfig -a und route -n von Client und dem Router (.0.254) fehlen zwar immer noch aber so wie ich das sehe hat der Client schlicht keine Route zu 192.168.0.0/24.
> 
> Sowohl der Client braucht eine Route zu 192.168.0.0/24 als auch der Router umgekehrt eine zu 192.168.1.0/24 via 192.168.0.11, dann klappt das auch mit dem Nachbarn.

 

Der .0.254 ist ein Linksys WRT54GL mit Linux drauf (dd-wrt). Da gibt es erwetertes Routing, wo ich es eintragen könnte.

Ich würde das Routing aber gerne auf dem Dual Pentium Pro Rechner eintragen, wo ja das OpenVPN drauf läuft. Wie muss ich das machen?

Gruss Sewulba

----------

## 69719

client

====

eth0: 192.168.0.11

tap0: 192.168.1.4

server

====

eth0: 192.168.0.?

tap0: 192.168.1.1

router

====

eth0: 192.168.0.250

haut das erstmal hin? denn so richtig ersichtlich ist das bisher immer noch nicht.

----------

## sewulba

 *escor wrote:*   

> client
> 
> ====
> 
> eth0: 192.168.0.11
> ...

 

Nicht ganz.

Client

====

eth0: 192.168.100.21 (das kann sich ändern, je nachdem, wo ich bin. Meist aber die IP mit Gateway 192.168.100.250)

tap0: 192.168.1.4 (zugewiesen von OVPN-Server)

Server 

====

eth0: 192.168.0.11 (Gateway ist hier ins Internet 192.168.0.254)

tap0: 192.168.1.1

Router für Server

====

eth0: 192.168.0.254

Gruss Sewulba

----------

## 69719

Wie sieht denn das "route -n" auf dem OpenVPN Server und Client aus?

Und wo kommt denn das 3 Netz her?

192.168.100.0/24 auf Arbeit, Kumpel?

192.168.0.0/24 Heimnetz?

192.168.1.0/24 OpenVPN

Du baust nun aus dem 192.168.100.0/24 (Arbeit?, Kumpel?) ne Verbindung über das Internet zum Server 192.168.0.0/24 (Zuhause) auf und bekommt anschließend ne IP aus dem 192.168.1.0/24 (OpenVPN) Netz für das tap0 device auf dem Client?

----------

## sewulba

 *escor wrote:*   

> Wie sieht denn das "route -n" auf dem OpenVPN Server und Client aus?
> 
> Und wo kommt denn das 3 Netz her?
> 
> 192.168.100.0/24 auf Arbeit, Kumpel?
> ...

 

Absolut korrekt...

Auf der Arbeit 192.168.100.0/24er Netz.

Zu Hause internes Netz 192.168.0.0/Netz <--- Da drin will ich von Arbeit aus zugreifen können über VPN-Server.

192.168.1.0/24 ist das OpenVPN-Server-Netz!

Gruss Sewulba

----------

## 69719

Die routen vom client und server während einer OpenVPN verbindung währen nun mal Interesannt.

----------

## sewulba

 *escor wrote:*   

> Die routen vom client und server während einer OpenVPN verbindung währen nun mal Interesannt.

 

Route vom Server ist ja bekannt, aber Route von Geschäft kann ich frühestens in 2 Tagen liefern! Hejts nicht auch ohne Route von Client?

Aber vielleicht hilft ja auch das: Das ist die OVPN-Client-Config.

```
client

float

dev tap

#MTU

tun-mtu 1500

#fragment 1300

mssfix

#device name, unter linux nicht mehr auskommentieren (# l�schen)

dev-node OpenVPN

#tcp oder udp

proto udp

#Server IP

remote beispiel.dyndns.org 1194

#force authentication

#WICHTIG: hier den COMMON Name vom Server Zertifikat nehmen!

tls-remote server

ca vpn-ca.pem

cert t41p_cert.pem

key t41p_key.pem

auth SHA1

cipher aes-256-cbc

nobind

comp-lzo

persist-key

persist-tun

verb 3

pull 

# Nach dem Verbindungsaufbau wird eine Route zum lokalen Netz vom Server aus aufgebaut

# AUSKOMMENTIERT

# Beispiel: Subnetz 192.168.2.0/24

route 192.168.1.0 255.255.255.0 192.168.1.1

# Default route ueber VPN

# AUSKOMMENTIERT

#route remote_host 255.255.255.255 net_gateway

#route 0.0.0.0 0.0.0.0 vpn_gateway
```

----------

## think4urs11

 *sewulba wrote:*   

> Der .0.254 ist ein Linksys WRT54GL mit Linux drauf (dd-wrt). Da gibt es erwetertes Routing, wo ich es eintragen könnte.
> 
> Ich würde das Routing aber gerne auf dem Dual Pentium Pro Rechner eintragen, wo ja das OpenVPN drauf läuft. Wie muss ich das machen?

 

Auf dem Server brauchst du keine gesonderten Routen einzutragen, der kennt ja bereits alle Netze/Wege.

via eth0 hängt dieser in 192.168.0.0/24, via tap0 in 192.168.1.0/24 und via 192.168.0.254 erreicht er alles andere.

aber...

Geräte in 192.168.0.0/24 müssen natürlich wissen wie sie Geräte in 192.168.1.0/24 erreichen können. Das geht entweder dadurch das diese Geräte den Server als default-GW nutzen _oder_ dadurch das deren default-GW (vulgo dein Linksys) eine Route zu 192.68.1.0/24 kennt - eben via 'Server'/192.168.0.11 _oder_ jeder Client für sich eine Route zu 192.168.1.0/24 via 'Server'/192.168.0.11 konfiguriert bekommt.

Genauso müssen Geräte in 192.168.1.0/24 (also deine VPN-Clients) saubere Routen kennen. Entweder bekommen sie im VPN-Tunnel 'Server' als default-GW zugewiesen _oder_ dedizierte Routen in alle Netze die sie erreichen können müssen. (Wobei letzteres dann kompliziert wird wenn sie via deines Routers ins Internet sollen).

Nur wenn _alle_ beteiligten Geräte richtige und vollständige Routen haben klappt die Kommunikation.

----------

## sewulba

 *Think4UrS11 wrote:*   

>  *sewulba wrote:*   Der .0.254 ist ein Linksys WRT54GL mit Linux drauf (dd-wrt). Da gibt es erwetertes Routing, wo ich es eintragen könnte.
> 
> Ich würde das Routing aber gerne auf dem Dual Pentium Pro Rechner eintragen, wo ja das OpenVPN drauf läuft. Wie muss ich das machen? 
> 
> Auf dem Server brauchst du keine gesonderten Routen einzutragen, der kennt ja bereits alle Netze/Wege.
> ...

 

Es gibt doch die Möglichkeit im OpenVPN-Server DefaultGW einzutragen, oder nicht? Würde es da nicht reichen den 192.168.0.254 einzutragen, damit ich ins 192.168.0.0/24-Netz komme?

Gruss Sewulba   :Wink: 

----------

## think4urs11

 *sewulba wrote:*   

> Es gibt doch die Möglichkeit im OpenVPN-Server DefaultGW einzutragen, oder nicht? Würde es da nicht reichen den 192.168.0.254 einzutragen, damit ich ins 192.168.0.0/24-Netz komme?

 

Jaein - zum einen tust du es derzeit nicht wenn ich deine Configs richtig lese und zum anderen müssen auch -wie bereits mehrfach gesagt- die Geräte in 192.168.0.0/24 wissen wie sie Geräte in 192.168.1.0/24 erreichen können, d.h. im einfachsten Fall wohin sie die Antwortpakete eines ping schicken müssen.

_Alle_ relevanten Routen müssen _allen_ Geräten die an einer Kommunikation beteiligt sind bekannt sein.

----------

## sewulba

 *Think4UrS11 wrote:*   

>  *sewulba wrote:*   Es gibt doch die Möglichkeit im OpenVPN-Server DefaultGW einzutragen, oder nicht? Würde es da nicht reichen den 192.168.0.254 einzutragen, damit ich ins 192.168.0.0/24-Netz komme? 
> 
> Jaein - zum einen tust du es derzeit nicht wenn ich deine Configs richtig lese und zum anderen müssen auch -wie bereits mehrfach gesagt- die Geräte in 192.168.0.0/24 wissen wie sie Geräte in 192.168.1.0/24 erreichen können, d.h. im einfachsten Fall wohin sie die Antwortpakete eines ping schicken müssen.
> 
> _Alle_ relevanten Routen müssen _allen_ Geräten die an einer Kommunikation beteiligt sind bekannt sein.

 

Wie muss ich das grundsätzlich tun? Mit dem 'route add-Befehl'? Oder kann ich das in den Configs machen?

Gruss Sewulba

----------

## think4urs11

auf VPN-Clients siehe deine Config (die natürlich noch angepaßt werden muß ich zitiere dich hier lediglich):

```
# Set Server as Gateway for Clients 

push "route 192.168.1.0 255.255.255.0 192.168.1.1" 

#route 192.168.0.0 255.255.255.0 192.168.1.1
```

```
# Default route ueber VPN 

# AUSKOMMENTIERT 

#route remote_host 255.255.255.255 net_gateway 

#route 0.0.0.0 0.0.0.0 vpn_gateway
```

für alle anderen siehe weiter oben

----------

## papahuhn

 *sewulba wrote:*   

> 
> 
> Wie muss ich das grundsätzlich tun? Mit dem 'route add-Befehl'? Oder kann ich das in den Configs machen?
> 
> 

 

Die Routen auf dem Client gehen auch über die OpenVPN-Konfiguration via -route. Die Geräte im 192.168.0.0/24-Netz müssen natürlich manuell eingestellt werden, die haben mit VPN nichts am Hut. Wenn du wirklich Geräte im 192.168.0.0/24-Netz hast, die auf den VPN-Client zugreifen sollen, und du sowieso schon mit TAP daherkommst, kannst du dir auch das 192.168.1.0/24-Netz sparen. Stattdessen brückst du auf dem Server eth0 mit tap0 und vergibst den Clients direkt eine IP aus einer Teilmenge des 192.168.0.0/24-Netzes.

----------

## sewulba

 *papahuhn wrote:*   

>  *sewulba wrote:*   
> 
> Wie muss ich das grundsätzlich tun? Mit dem 'route add-Befehl'? Oder kann ich das in den Configs machen?
> 
>  
> ...

 

Das hört sich ja klasse an... Einen Tipp für mich wo ich ein Howto dazu finde? Auf dem Linksys habe ich PPtP laufen und da vergebe ich mit die IP 192.168.0.150. Damit komme ich überall hin, wo ich will. 

Gruss Sewulba

----------

## papahuhn

http://gentoo-wiki.com/HOWTO_setup_a_gentoo_bridge

EDIT:

Bevor du jetzt stundenlang rumprobierst, noch ein Hinweis. VPN derart zu bridgen ist nicht empfehlenswert, falls der VPN-Server auch für andere Dienste genutzt wird, oder gar wenn mehrere VPN-Clients gleichzeitig eingeloggt sind.

----------

## sewulba

 *papahuhn wrote:*   

> http://gentoo-wiki.com/HOWTO_setup_a_gentoo_bridge
> 
> EDIT:
> 
> Bevor du jetzt stundenlang rumprobierst, noch ein Hinweis. VPN derart zu bridgen ist nicht empfehlenswert, falls der VPN-Server auch für andere Dienste genutzt wird, oder gar wenn mehrere VPN-Clients gleichzeitig eingeloggt sind.

 

Es hat geklappt!   :Razz: 

Ich bin hergegangen und habe br0 angelegt. Dann habe ich nur tap0 reigelegt und br0 die IP 192.168.0.160 gegeben mit subnetmask 255.255.255.0 und broadcast 192.168.0.0.

Das wars dann auch schon.

Vielen dank an jeden einzelnen, der mir hier mit Rat zur Seite stand. Vielen dank auch.

Gruss Sewulba   :Wink: 

----------

## papahuhn

 *sewulba wrote:*   

> Ich bin hergegangen und habe br0 angelegt. Dann habe ich nur tap0 reigelegt ...

 

Wie jetzt, nur tap0, ohne eth0? Kann ich mir nicht vorstellen.  :Shocked: 

----------

## sewulba

 *papahuhn wrote:*   

>  *sewulba wrote:*   Ich bin hergegangen und habe br0 angelegt. Dann habe ich nur tap0 reigelegt ... 
> 
> Wie jetzt, nur tap0, ohne eth0? Kann ich mir nicht vorstellen. 

 

Ich gebe dir da recht... Ich habe mich zu früh gefreut. Keine Chance bis jetzt.

Bin ebenfalls hergegangen und habe mit als TAP0 die 192.168.0.160 geben lassen. Selbst dann kann ich nicht auf 192.168.0.254 zugreifen. Es kann doch eigentlich nur an einer Kleinigkeit liegen. Nur welche. Ich blicke es einfach nicht.

Ich muss doch nur von tap0 zugriff auf eth0 bekommen, aber wie?

Gruss Sewulba

----------

## papahuhn

Du musst tap0 UND eth0 in die Bridge packen.

----------

## sewulba

 *papahuhn wrote:*   

> Du musst tap0 UND eth0 in die Bridge packen.

 

Hatte ich gemacht und die Sache br0 genannt. Dann eine IP auf br0 auf 192.168.0.160 gesetzt. Dann geht aber das Internet nicht mehr. Oder muss ich br0 keine IP geben?

----------

## papahuhn

Es reicht, wenn das tap-Device des VPN-Clients die IP-Adresse bekommt; br0 braucht keine. Aber was meinste damit, dass Internet nicht geht? Zerschießt dir das das komplette interne Netzwerk?

----------

## Anarcho

 *papahuhn wrote:*   

> Es reicht, wenn das tap-Device des VPN-Clients die IP-Adresse bekommt; br0 braucht keine. Aber was meinste damit, dass Internet nicht geht? Zerschießt dir das das komplette interne Netzwerk?

 

Ich habe jetzt nur den letzten Teil über die Bridge gelesen:

Also meiner Meinung nach darf NUR br0 eine IP haben und weder tap0 noch eth0.

Zumindest ist das so bei meiner XEN Bridge. Dort hat weder das physikalische noch das virtuelle Interface eine IP, lediglich die Bridge.

----------

## papahuhn

Ok, dann geht das wohl auf mehrere Arten.

Ich hatte jedenfalls mal eine Konfiguration am laufen, in der das TAP-Device des Clients und das br0 Interface des Servers jeweils eine IP hatten, aber nicht das TAP-Device des Servers. Man kann Netzwerke allerdings auch derart bridgen, dass der brückende Rechner komplett unsichtbar ist, indem man ihm keine IP zuweist.

----------

## sewulba

 *papahuhn wrote:*   

> Ok, dann geht das wohl auf mehrere Arten.
> 
> Ich hatte jedenfalls mal eine Konfiguration am laufen, in der das TAP-Device des Clients und das br0 Interface des Servers jeweils eine IP hatten, aber nicht das TAP-Device des Servers. Man kann Netzwerke allerdings auch derart bridgen, dass der brückende Rechner komplett unsichtbar ist, indem man ihm keine IP zuweist.

 

Ohne brigding (br0) sieht das route print auf dem Client so aus:

```
===========================================================================

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

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl

          0.0.0.0          0.0.0.0  192.168.100.250  192.168.100.26       20

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

      192.168.1.0    255.255.255.0      192.168.1.2     192.168.1.2       30

      192.168.1.2  255.255.255.255        127.0.0.1       127.0.0.1       30

    192.168.1.255  255.255.255.255      192.168.1.2     192.168.1.2       30

     192.168.47.0    255.255.255.0     192.168.47.1    192.168.47.1       20

     192.168.47.1  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.47.255  255.255.255.255     192.168.47.1    192.168.47.1       20

    192.168.100.0    255.255.255.0   192.168.100.26  192.168.100.26       20

   192.168.100.26  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.100.255  255.255.255.255   192.168.100.26  192.168.100.26       20

    192.168.132.0    255.255.255.0    192.168.132.1   192.168.132.1       20

    192.168.132.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.132.255  255.255.255.255    192.168.132.1   192.168.132.1       20

        224.0.0.0        240.0.0.0      192.168.1.2     192.168.1.2       30

        224.0.0.0        240.0.0.0     192.168.47.1    192.168.47.1       20

        224.0.0.0        240.0.0.0   192.168.100.26  192.168.100.26       20

        224.0.0.0        240.0.0.0    192.168.132.1   192.168.132.1       20

  255.255.255.255  255.255.255.255      192.168.1.2     192.168.1.2       1

  255.255.255.255  255.255.255.255     192.168.47.1    192.168.47.1       1

  255.255.255.255  255.255.255.255   192.168.100.26  192.168.100.26       1

  255.255.255.255  255.255.255.255    192.168.132.1   192.168.132.1       1

Standardgateway:   192.168.100.250

===========================================================================
```

Ich komme einfach nicht ins 192.168.0.x-Netz!

Gruss Sewulba

----------

## papahuhn

Da ist ja auch keine explizite Route ins 192.168.0.0/24 Netz. Der Client versucht über den Standardgateway reinzukommen, was natürlich nicht klappen kann.

Ich kann mir allerdings keinen Reim auf die letzten vier Regeln machen (Netzwerkziel 255.255.255.255). Stellt Windows so Tunneldevices dar? Unterstützt Windows überhaupt TAP?

----------

## sewulba

 *papahuhn wrote:*   

> Da ist ja auch keine explizite Route ins 192.168.168.0/24 Netz. Der Client versucht über den Standardgateway reinzukommen, was natürlich nicht klappen kann.
> 
> Ich kann mir allerdings keinen Reim auf die letzten vier Regeln machen (Netzwerkziel 255.255.255.255). Stellt Windows so Tunneldevices dar? Unterstützt Windows überhaupt TAP?

 

Habe OpenVPN auf WindowsClient drauf und kann mich ja auch mit Server verbinden. 

Ich würde auch lieber Linux im Geschäft verwenden oder BSD. Ist halt leider Windoof. Aber es liegt ja auch nicht am Windows sondern an meinem OpenVPN server.   :Confused: 

Gruss Sewulba

----------

## papahuhn

Ok, dann wieder zurück zu den Routen ohne Bridging.

Mach auf dem Windowsclient eine Route ins 192.168.0.0/24-Netz via dem Tunnel-Interface. Wie das unter Windows geht, weiss ich nicht im Detail.

Ein Ping-Request sollte dann schon beim Standardgateway deines Hausnetzwerks ankommen (per tcpdump kontrollierbar), allerdings wird der dann versuchen, über das Internet zu antworten. Deshalb musst du dort eine Route ins 192.168.1.0/24-Netz via der (lokalen) Adresse des VPN-Servers einrichten. Ping sollte dann klappen.

Um dann über zuhause zu surfen, muss der VPN-Client die externe Adresse ("remote" in der Konfiguration) des VPN-Servers als statische Route über den Firmengateway bekommen. Den Standardgateway auf dem Client änderst du dann in den Standardgateway bei dir zuhause (interne Adresse).

----------

## sewulba

 *papahuhn wrote:*   

> Ok, dann wieder zurück zu den Routen ohne Bridging.
> 
> Mach auf dem Windowsclient eine Route ins 192.168.0.0/24-Netz via dem Tunnel-Interface. Wie das unter Windows geht, weiss ich nicht im Detail.
> 
> Ein Ping-Request sollte dann schon beim Standardgateway deines Hausnetzwerks ankommen (per tcpdump kontrollierbar), allerdings wird der dann versuchen, über das Internet zu antworten. Deshalb musst du dort eine Route ins 192.168.1.0/24-Netz via der (lokalen) Adresse des VPN-Servers einrichten. Ping sollte dann klappen.
> ...

 

Mir geht es nicht darum über zu Hause zu surfen. Ich will nur über das VPN auf jeden Computer im 192.168.0.x-Netzwerk zugreifen können. Das ist alles.

Gruss Sewulba  :Wink: 

PS.: Mittlerweile hätte ich es ja schon durch Zufall schaffen müssen, solange wie ich jetzt da schon rumdoktore!

----------

## papahuhn

Dann musst du das machen, was Think4UrS11 dir gesagt hat; dem VPN-Client und jedem Rechner in 192.168.0.1/24 die korrekten Routen geben.

----------

## sewulba

 *papahuhn wrote:*   

> Dann musst du das machen, was Think4UrS11 dir gesagt hat; dem VPN-Client und jedem Rechner in 192.168.0.1/24 die korrekten Routen geben.

 

Wie muss dann die korrekte Route aussehen? Auf dem Client oder auf dem Server?

----------

## think4urs11

wie ich bereits sagte: *Think4UrS11 wrote:*   

> Geräte in 192.168.0.0/24 müssen natürlich wissen wie sie Geräte in 192.168.1.0/24 erreichen können. Das geht entweder dadurch das diese Geräte den Server als default-GW nutzen _oder_ dadurch das deren default-GW (vulgo dein Linksys) eine Route zu 192.68.1.0/24 kennt - eben via 'Server'/192.168.0.11 _oder_ jeder Client für sich eine Route zu 192.168.1.0/24 via 'Server'/192.168.0.11 konfiguriert bekommt.
> 
> Genauso müssen Geräte in 192.168.1.0/24 (also deine VPN-Clients) saubere Routen kennen. Entweder bekommen sie im VPN-Tunnel 'Server' als default-GW zugewiesen _oder_ dedizierte Routen in alle Netze die sie erreichen können müssen. (Wobei letzteres dann kompliziert wird wenn sie via deines Routers ins Internet sollen).
> 
> Nur wenn _alle_ beteiligten Geräte richtige und vollständige Routen haben klappt die Kommunikation.

 

Oder in technisch:

auf dem OpenVPN-Server

Ziel 0.0.0.0, Router 192.168.0.254, Netzmaske 0.0.0.0

alle anderen Routen kennt der automatisch da er Teil davon ist

damit ermöglichst du prinzipiell das allen Geräte 'hinter' diesem Server (d.h. VPN-Clients) das diese auch ins Internet (oder was eben sonst hinter .0.254 ist) könnten wenn sie wollen. Damit das funktioniert muß aber auch den Clients entsprechende Routen konfiguriert werden.

auf dem OpenVPN-Client

entweder Ziel 0.0.0.0, Router 192.168.0.254, Netzmaske 0.0.0.0, damit erschlägst du alles auf einmal; 192.168.0.0/24 sowie Zugriff auf alles 'hinter' Router .0.254

oder Ziel 192.168.0.0, Router 192.168.1.1, Netzmaske 255.255.255.0 - damit erreichst du vom Client aus alle Geräte in 192.168.0.0/24 aber nichts hinter dem Router was du ja eh nicht willst

auf Geräten in 192.168.0.0/24 - entweder (auf jedem)

Ziel 192.168.1.0, Router 192.168.0.11, Netzmaske 255.255.255.0

oder auf dem Router 192.168.0.254 eine Route

Ziel 192.168.1.0, Router 192.168.0.11, Netzmaske 255.255.255.0

Letzteres geht davon aus das alle Geräte in 192.168.0.0/24 den Router als Default-GW nutzen. Sofern also ein solches Gerät auf eines in 192.168.1.0/24 zugreifen will (bzw. auf Anfragen von dort antworten will) schickt es die Packete zu seinem Default-GW und dort wird das Packet dann entsprechend 'umgebogen' in Richtung des OpenVPN-Servers da dieses Netz ja 'hinter' diesem zu finden ist.

'Gutes' Netzwerkdesign ist i.d.R. dem Client so wenig wie möglich Wissen aufzubürden, soll heißen wo immer möglich arbeite auf Clients immer mit Defaultrouten.

Ein Client muß nicht wissen das er manche Pakete nach links und manche nach rechts schicken soll - das ist der Job der/des Routers dies zu wissen. In deinem Fall hast du zwei Router, deinen Linksys und deinen VPN-Server, es genügt völlig wenn die beiden wissen wos langgeht.

----------

## Anarcho

Das ist doch alles garnicht so schwer   :Twisted Evil: 

Nach meiner Rechnernetze-Vorlesung hatte ich das alles drauf  :Wink: 

Oder aber man kauft sich ein Buch über IP-Netzwerke. Ich finde das Thema wirklich interessant.

----------

## think4urs11

 *Anarcho wrote:*   

> Das ist doch alles garnicht so schwer   

 

Stimmt, mit ein/zwei Routern ist das ganze noch geradezu trivial, aber mit 10-12 die teils gestaffelt hintereinanderstehen und Subnetzmasken von /8 bis /29 wird es dann allmählich etwas schwierig den Überblick zu behalten.  (Und dann fummeln wir noch ein wenig Firewalls, OSPF, BGP und Co ein, yippieeh)  :Mr. Green: 

----------

## sewulba

Ja suppiiii...

Danke... Werde es am Wochenende probieren. Thnx

Gruss Sewulba   :Wink: 

----------

## Anarcho

 *Think4UrS11 wrote:*   

>  *Anarcho wrote:*   Das ist doch alles garnicht so schwer    
> 
> Stimmt, mit ein/zwei Routern ist das ganze noch geradezu trivial, aber mit 10-12 die teils gestaffelt hintereinanderstehen und Subnetzmasken von /8 bis /29 wird es dann allmählich etwas schwierig den Überblick zu behalten.  (Und dann fummeln wir noch ein wenig Firewalls, OSPF, BGP und Co ein, yippieeh) 

 

Oh ja, vor allem OSPF und BGP machen Spass! Dabei geht es ja dann nicht mehr nur um "den einen richtigen Weg" sondern, und im Falle von BGP noch viel schlimmer, um Metriken und Kosten der Wege. Bei BGP dann noch Politikbehaftet ("Der Traffic über Provider X ist aber billiger als über Y, aber Z gehört meinem Neffen").

Bei vielen Routern muss man sich halt nur gute Pläne mit eingetragenen Netzwerken und vor allem Masken erstellen. Dann kann man da durchblicken.

----------

## think4urs11

 *Anarcho wrote:*   

> Bei vielen Routern muss man sich halt nur gute Pläne mit eingetragenen Netzwerken und vor allem Masken erstellen. Dann kann man da durchblicken.

 

grad mal spaßhalber auf zwei meiner dickeren Teile geschaut

a) ~400 statische Routen via 8 outgoing Interfaces (an denen wiederum insg. ca. 15 weitere Router hängen)

b) ~1800 Routen, davon 85% via BGP, 10% via OSPF und der Rest statisch

Ich hab sogar ein paar /30 Routen gefunden. NAT ist sowieso Ehrensache/ein notwendiges Übel und in einigen Ecken des Netzes wird sogar mit richtig leckerem asymetrischen Routing hantiert (FW lieben sowas)  :Wink: 

Zum Glück sind (bei uns, derzeit) im BGP nicht auch noch politisch-religiöse Kostenfaktoren zu berücksichtigen, ist so schon Gewurschtel genug.

----------

## Anarcho

 *Think4UrS11 wrote:*   

>  *Anarcho wrote:*   Bei vielen Routern muss man sich halt nur gute Pläne mit eingetragenen Netzwerken und vor allem Masken erstellen. Dann kann man da durchblicken. 
> 
> grad mal spaßhalber auf zwei meiner dickeren Teile geschaut
> 
> a) ~400 statische Routen via 8 outgoing Interfaces (an denen wiederum insg. ca. 15 weitere Router hängen)
> ...

 

Stell dich mal nicht so an. Musst du halt die Schriftgrösse auf 2pt stellen! Dann bekommst du das schon auf 2 DIN A3 Blätter. Vielleicht gibt es vom Chef noch ne Lupe spendiert!   :Twisted Evil: 

----------

## sewulba

 *Think4UrS11 wrote:*   

> wie ich bereits sagte: *Think4UrS11 wrote:*   Geräte in 192.168.0.0/24 müssen natürlich wissen wie sie Geräte in 192.168.1.0/24 erreichen können. Das geht entweder dadurch das diese Geräte den Server als default-GW nutzen _oder_ dadurch das deren default-GW (vulgo dein Linksys) eine Route zu 192.68.1.0/24 kennt - eben via 'Server'/192.168.0.11 _oder_ jeder Client für sich eine Route zu 192.168.1.0/24 via 'Server'/192.168.0.11 konfiguriert bekommt.
> 
> Genauso müssen Geräte in 192.168.1.0/24 (also deine VPN-Clients) saubere Routen kennen. Entweder bekommen sie im VPN-Tunnel 'Server' als default-GW zugewiesen _oder_ dedizierte Routen in alle Netze die sie erreichen können müssen. (Wobei letzteres dann kompliziert wird wenn sie via deines Routers ins Internet sollen).
> 
> Nur wenn _alle_ beteiligten Geräte richtige und vollständige Routen haben klappt die Kommunikation. 
> ...

 

Routen auf Server erstellt...

Ausgabe von route -n sieht jetzt folgendermaßen aus:

```
Kernel IP Routentabelle

Ziel            Router          Genmask         Flags Metric Ref    Use Iface

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth0
```

Irgendwie ändert da sich nichts!

Stimmt das soweit?

Eintragsänderungen in Config von OpenVPN...

```
push "route 0.0.0.0   0.0.0.0   192.168.0.254"

route 0.0.0.0   0.0.0.0   192.168.0.254
```

Der routeeintrag sorgt für die route am Server. Und wenn ich es richtig verstanden habe sorgt das 'push route' dasfür, dass der Client die Route setzt!

Testen kann ich es leider erst vorrassichtlich am Montag, wenn ich wieder Arbeiten bin!

Gruss Sewulba  :Wink: 

----------

## sewulba

Hallo...

Ich denke jetzt bin ich schon ein ganzes Stück weiter. 

Habe folgendes eingestellt:

Netz 192.168.0.0 mit Subnetmask 255.255.255.0 erreichbar über 192.168.1.1

Aber genau an der 192.168.1.1 bleibt es hängen.

Habe folgende Firewallregel erstellt:

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

/sbin/iptables -A INPUT -p udp --dport 1194 -j ACCEPT

/sbin/iptables -A INPUT -i tap0 -j ACCEPT

/sbin/iptables -A OUTPUT -o tap0 -j ACCEPT

/sbin/iptables -A FORWARD -i tap0 -j ACCEPT
```

Das ist alles, was ich an iptables habe...

Wo liegt jetzt noch der Fehler?

Gruss Sewulba   :Wink: 

----------

## Anarcho

 *sewulba wrote:*   

> Hallo...
> 
> Ich denke jetzt bin ich schon ein ganzes Stück weiter. 
> 
> Habe folgendes eingestellt:
> ...

 

Und wie sehen die Default-Einstellungen aus? Sprich was ist mit iptables -P gesetzt worden?

Herrausfinden kann man das auch mit "iptables -L -v"

----------

## sewulba

 *Anarcho wrote:*   

>  *sewulba wrote:*   Hallo...
> 
> Ich denke jetzt bin ich schon ein ganzes Stück weiter. 
> 
> Habe folgendes eingestellt:
> ...

 

Mit iptables -P habe ich gar nichts gemacht!

ausgabe von iptables -L -v sieht folgendermaßen aus:

```
 iptables -L -v

Chain INPUT (policy ACCEPT 342K packets, 485M bytes)

 pkts bytes target     prot opt in     out     source               destination                                              

  399 56059 ACCEPT     udp  --  any    any     anywhere             anywhere                                                         udp dpt:openvpn

  205 29152 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere                                                         udp dpt:openvpn

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere                                                         udp dpt:openvpn

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere                                                         udp dpt:openvpn

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere                                                         udp dpt:openvpn

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)

 pkts bytes target     prot opt in     out     source               destination                                              

    7   484 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  tap0   any     anywhere             anywhere                                                 

Chain OUTPUT (policy ACCEPT 180K packets, 9893K bytes)

 pkts bytes target     prot opt in     out     source               destination                                              

   59  9274 ACCEPT     0    --  any    tap0    anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  any    tap0    anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  any    tap0    anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  any    tap0    anywhere             anywhere                                                 

    0     0 ACCEPT     0    --  any    tap0    anywhere             anywhere
```

Was fehlt noch?

Gruss Sewulba

----------

## Anarcho

Dann liegt es schonmal nicht an iptables.   :Razz: 

----------

## sewulba

 *Anarcho wrote:*   

> Dann liegt es schonmal nicht an iptables.  

 

Woran könnte es denn noch liegen? Er bleibt definitiv beim Tracerouten an 192.168.1.1 hängen. Er geht einfach nicht ins 192.168.0.0-Netz rein. Aber 192.168.0.11 (interne IP des Servers) ist anpingbar!

----------

## Anarcho

OK, dann gib doch nochmal, um auf nummer sicher zu gehen, die Routingtabelle des Rechners aus dem 192.168.0.0/24 Netz den du anpingen willst.

----------

## sewulba

 *Anarcho wrote:*   

> OK, dann gib doch nochmal, um auf nummer sicher zu gehen, die Routingtabelle des Rechners aus dem 192.168.0.0/24 Netz den du anpingen willst.

 

Ok. Route print vom Rechner von dem ich aus ins 192.168.0.0-Netz will.

```
H:\>route print

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

Schnittstellenliste

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

0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8

0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1

0x4 ...00 0d 60 dd 68 23 ...... Broadcom NetXtreme Gigabit Ethernet - Paketplane

r-Miniport

0x5 ...00 ff 32 46 b6 b7 ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport

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

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

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl

          0.0.0.0          0.0.0.0  192.168.100.250  192.168.100.26       20

        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.1.1     192.168.1.2       1

      192.168.1.0    255.255.255.0      192.168.1.2     192.168.1.2       30

      192.168.1.2  255.255.255.255        127.0.0.1       127.0.0.1       30

    192.168.1.255  255.255.255.255      192.168.1.2     192.168.1.2       30

     192.168.47.0    255.255.255.0     192.168.47.1    192.168.47.1       20

     192.168.47.1  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.47.255  255.255.255.255     192.168.47.1    192.168.47.1       20

    192.168.100.0    255.255.255.0   192.168.100.26  192.168.100.26       20

   192.168.100.26  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.100.255  255.255.255.255   192.168.100.26  192.168.100.26       20

    192.168.132.0    255.255.255.0    192.168.132.1   192.168.132.1       20

    192.168.132.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.132.255  255.255.255.255    192.168.132.1   192.168.132.1       20

        224.0.0.0        240.0.0.0      192.168.1.2     192.168.1.2       30

        224.0.0.0        240.0.0.0     192.168.47.1    192.168.47.1       20

        224.0.0.0        240.0.0.0   192.168.100.26  192.168.100.26       20

        224.0.0.0        240.0.0.0    192.168.132.1   192.168.132.1       20

  255.255.255.255  255.255.255.255      192.168.1.2     192.168.1.2       1

  255.255.255.255  255.255.255.255     192.168.47.1    192.168.47.1       1

  255.255.255.255  255.255.255.255   192.168.100.26  192.168.100.26       1

  255.255.255.255  255.255.255.255    192.168.132.1   192.168.132.1       1

Standardgateway:   192.168.100.250

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

Ständige Routen:

  Keine
```

----------

## Anarcho

Ich meinte eigentlich die Routingtabelle des anderen Endes, also des Rechners der auch tatsächlich die IP 192.168.0.x hat. Mach am besten dann auch von diesem aus einen traceroute auf den anderen Rechner.

Also im Prinzip 2 traceroutes, jeweils von beiden enden aus.

----------

## bbgermany

Hi,

hier mal zwei Konfigurationen, die beide bereits im Einsatz waren und funktionieren bzw funktionierten:

1. TUN Interface, kein bridging:

server.conf. 

```
local 192.168.0.1

port 1194

proto udp

dev tun0

crl-verify /etc/openvpn/crl.pem

ca /etc/openvpn/ca.crt

cert /etc/openvpn/server.crt

key /etc/openvpn/server.key

dh /etc/openvpn/dh2048.pem

server 192.168.1.1 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp-ext.txt

keepalive 10 120

tls-server

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

cipher AES-256-CBC

comp-lzo

user nobody

group nobody

verb 2

status /etc/openvpn/openvpn-status.log

client-config-dir /etc/openvpn/ccd

push "route 192.168.0.0 255.255.255.0"

persist-key

persist-tun

reneg-sec 1200

keepalive 10 120

client-to-client
```

client.ovpn (Windows):

```
client

dev tun 

proto udp

remote ovpn-server 1194

ca ca.crt

cert client.crt

key client.key

comp-lzo

cipher AES-256-CBC

verb 2

ns-cert-type server

tls-auth tls.key 1

pull

nobind
```

2. TAP Interface, mit bridging:

/etc/conf.d/net:

```

modules=( "iproute2" )

config_eth0=( "null" )

tuntap_tap0="tap"

tunctl_tap0="-u adm"

config_tap0=( "null" )

tuntap_tap1="tap"

tunctl_tap1="-u adm"

config_tap1=( "null" )

bridge_br0="eth0 tap0"

config_br0=( "192.168.0.1")

routes_br0=( "default via 192.168.0.1" )

depend_br0()

{

        need net.eth0 net.tap0

}

```

server.conf:

```

port 1194

proto udp

dev tap0

dev-type tap

ca /etc/openvpn/ca.crt

cert /etc/openvpn/herkules.crt

key /etc/openvpn/herkules.key

dh /etc/openvpn/dh1024.pem

server-bridge 192.168.0.1 255.255.255.0 192.168.0.250 192.168.0.251

ifconfig-pool-persist /etc/openvpn/ipp-ext.txt

keepalive 10 120

tls-server

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

cipher AES-256-CBC

comp-lzo

user nobody

group nobody

verb 2

status /etc/openvpn/openvpn-status.log

client-config-dir /etc/openvpn/ccd

persist-key

persist-tun

reneg-sec 1200

keepalive 10 120

client-to-client
```

client.ovpn (Windows):

```

client

dev tap

proto udp

remote ovpn-server 1194

ca ca.crt

cert client.crt

key client.key

comp-lzo

cipher AES-256-CBC

verb 4

ns-cert-type server

tls-auth tls.key 1

pull

nobind
```

Wenn du bridging haben willst, sind Client und Server im gleichen Netzwerk. Ohne Bridging brauchst du 2 Netzwerke.

MfG. Stefan

----------

## sewulba

Ahaaaaaa...   :Very Happy: 

Werde es als bald als möglich ausprobieren. Danke   :Wink: 

Gruss Sewulba

----------

## sewulba

 *bbgermany wrote:*   

> Hi,
> 
> hier mal zwei Konfigurationen, die beide bereits im Einsatz waren und funktionieren bzw funktionierten:
> 
> 1. TUN Interface, kein bridging:
> ...

 

Ich habe mich für die letzte Version entschieden. Bekomme die IP 192.168.0.250 zugewiesen. Aber ich komme trotzdem nicht ins 192.168.0.0er-Netz.

```
routing-tabelle auf Client

H:\>route print

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

Schnittstellenliste

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

0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8

0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1

0x4 ...00 0d 60 dd 68 23 ...... Broadcom NetXtreme Gigabit Ethernet - Paketpla

r-Miniport

0x5 ...00 ff 32 46 b6 b7 ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport

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

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

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl

          0.0.0.0          0.0.0.0  192.168.100.250  192.168.100.26       20

        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.250   192.168.0.250       30

    192.168.0.250  255.255.255.255        127.0.0.1       127.0.0.1       30

    192.168.0.255  255.255.255.255    192.168.0.250   192.168.0.250       30

     192.168.47.0    255.255.255.0     192.168.47.1    192.168.47.1       20

     192.168.47.1  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.47.255  255.255.255.255     192.168.47.1    192.168.47.1       20

    192.168.100.0    255.255.255.0   192.168.100.26  192.168.100.26       20

   192.168.100.26  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.100.255  255.255.255.255   192.168.100.26  192.168.100.26       20

    192.168.132.0    255.255.255.0    192.168.132.1   192.168.132.1       20

    192.168.132.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.132.255  255.255.255.255    192.168.132.1   192.168.132.1       20

        224.0.0.0        240.0.0.0    192.168.0.250   192.168.0.250       30

        224.0.0.0        240.0.0.0     192.168.47.1    192.168.47.1       20

        224.0.0.0        240.0.0.0   192.168.100.26  192.168.100.26       20

        224.0.0.0        240.0.0.0    192.168.132.1   192.168.132.1       20

  255.255.255.255  255.255.255.255    192.168.0.250   192.168.0.250       1

  255.255.255.255  255.255.255.255     192.168.47.1    192.168.47.1       1

  255.255.255.255  255.255.255.255   192.168.100.26  192.168.100.26       1

  255.255.255.255  255.255.255.255    192.168.132.1   192.168.132.1       1

Standardgateway:   192.168.100.250

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

Ständige Routen:

  Keine
```

Es will einfach nicht. Ich dreh noch durch!

Gruss Sewulba

----------

## Anarcho

Mach doch bitte mal ein Traceroute von beiden Enden aus:

client1# traceroute client2

client2# traceroute client1

(Oder tracert wie es unter Win heisst)

----------

## bbgermany

Hi,

hast du IP-Forwarding auch eingeschaltet?

MfG. Stefan

----------

## sewulba

 *bbgermany wrote:*   

> Hi,
> 
> hast du IP-Forwarding auch eingeschaltet?
> 
> MfG. Stefan

 

Ich denke ja!

```
cat /proc/sys/net/ipv4/ip_forward

1
```

Gruss Sewulba

----------

## sewulba

Hat keiner mehr eine Idee?   :Embarassed: 

----------

## manuels

versuch doch mal mit tcpdump zu schaun wer welches Paket versendet und ob es beim anderen ankommt.

----------

## bbgermany

Mal eine ganz andere Frage. Welche IP-Adresse hat der Client auf seiner Netzwerkkarte bevor du dich einwählst? Also nicht die IP-Adresse des tun/tap Interface sonder von eth0 bzw "Lan Verbindung"!

MfG. Stefan

----------

## Anarcho

Warum gibst du mir denn nicht einfach mal die, bereits mehrfach angeforderten, traceroutes aus beiden richtungen?

----------

## sewulba

 *bbgermany wrote:*   

> Mal eine ganz andere Frage. Welche IP-Adresse hat der Client auf seiner Netzwerkkarte bevor du dich einwählst? Also nicht die IP-Adresse des tun/tap Interface sonder von eth0 bzw "Lan Verbindung"!
> 
> MfG. Stefan

 

Der client hat die IP 192.168.100.21 (anderer Standort)

Der Server intern die IP 192.168.0.11 eth0 und 192.168.1.1 tap0

Gruss Sewulba   :Wink: 

----------

## sewulba

 *Anarcho wrote:*   

> Warum gibst du mir denn nicht einfach mal die, bereits mehrfach angeforderten, traceroutes aus beiden richtungen?

 

Sorry...

Sobald ich nicht soviel Arbeit habe mach ich das. Sorry!

Gruss Sewulba

----------

## bbgermany

 *sewulba wrote:*   

>  *bbgermany wrote:*   Mal eine ganz andere Frage. Welche IP-Adresse hat der Client auf seiner Netzwerkkarte bevor du dich einwählst? Also nicht die IP-Adresse des tun/tap Interface sonder von eth0 bzw "Lan Verbindung"!
> 
> MfG. Stefan 
> 
> Der client hat die IP 192.168.100.21 (anderer Standort)
> ...

 

Genau das ist eins der Probleme! 

1. Wenn du ein TAP Interface hast, dann willst du Bridging: Ergo keine IP auf dem Interface!

2. Wenn du ein TUN Interface hast, dann willst du kein Bridging: Ergo OpenVPN setzt die IP auf dem Interface!

MfG. Stefan

----------

## Anarcho

 *bbgermany wrote:*   

>  *sewulba wrote:*    *bbgermany wrote:*   Mal eine ganz andere Frage. Welche IP-Adresse hat der Client auf seiner Netzwerkkarte bevor du dich einwählst? Also nicht die IP-Adresse des tun/tap Interface sonder von eth0 bzw "Lan Verbindung"!
> 
> MfG. Stefan 
> 
> Der client hat die IP 192.168.100.21 (anderer Standort)
> ...

 

Quatsch. Ich habe immer ein Tap Interface benutzt und das völlig ohne Bridging. Bridging dient nur dem "verstecken". Bei korrektem Routing braucht man kein Bridging.

Der Hauptunterschied zwischen TUN und TAP ist der, dass TAP ganze Ethernetframes überträgt und TUN nur die IP Pakete.

----------

## bbgermany

Leider ist das nicht so:

```

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:10.1.1.1  P-t-P:10.1.1.2  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:100

          RX bytes:103127270 (98.3 Mb)  TX bytes:484468580 (462.0 Mb)

```

```

tap0      Protokoll:Ethernet  Hardware Adresse 00:FF:00:D1:CD:3D

          inet6 Adresse: fe80::2ff:ff:fed1:cd3d/64 Gültigkeitsbereich:Verbindung

          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

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

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

          Kollisionen:0 Sendewarteschlangenlänge:100

          RX bytes:0 (0.0 b)  TX bytes:1217489 (1.1 Mb)

```

MfG. Stefan

EDITH: Als Zusatzinfo dazu: http://vtun.sourceforge.net/tun/faq.html#1.1

----------

## Anarcho

 *bbgermany wrote:*   

> Leider ist das nicht so:
> 
> ```
> 
> tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> ...

 

Was genau soll das nun belegen? Ich habe nichts gefunden was meiner Aussage wiederspricht. Und ich habe bereits selber mit TUN/TAP programmiert, weiss also daher was die können. Dabei musste ich niemals bridging einsetzen.

Das TUN nur ein Punkt-zu-Punkt-Verbindung ist, ist klar. Daher gehen auch nur IP Frames übers Netz und nicht ganze Ethernetframes wie es bei TAP der Fall ist.

----------

## b3cks

In der Regel gilt folgendes:

- TAP-Device: Bridging

- TUN-Device: Routing

So steht es zumindest in jeder Doku und auch im OpenVPN HOWTO/Manual. TAP kann aber auch Routing! Deswegen wird es bei Anarcho wohl auch so funktioniert haben.

----------

## Anarcho

Warum sollte es das auch nicht können? Es verhällt sich wie ein normales Netzwerkinterface.

----------

## sewulba

 *Anarcho wrote:*   

> Mach doch bitte mal ein Traceroute von beiden Enden aus:
> 
> client1# traceroute client2
> 
> client2# traceroute client1
> ...

 

Hallo hier nun das Trancerouten vom Client aus:

```
C:\>tracert 192.168.0.11

Routenverfolgung zu 192.168.0.11 über maximal 30 Abschnitte

  1    57 ms    25 ms    25 ms  192.168.0.11

Ablaufverfolgung beendet.

C:\>tracert 192.168.1.1

Routenverfolgung zu 192.168.1.1 über maximal 30 Abschnitte

  1    25 ms    25 ms    25 ms  192.168.1.1

Ablaufverfolgung beendet.

C:\>route print

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

Schnittstellenliste

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

0x2 ...00 50 56 c0 00 08 ...... VMware Virtual Ethernet Adapter for VMnet8

0x3 ...00 50 56 c0 00 01 ...... VMware Virtual Ethernet Adapter for VMnet1

0x4 ...00 0d 60 dd 68 23 ...... Broadcom NetXtreme Gigabit Ethernet - Paketplane

r-Miniport

0x5 ...00 ff 32 46 b6 b7 ...... TAP-Win32 Adapter V8 - Paketplaner-Miniport

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

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

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl

          0.0.0.0          0.0.0.0  192.168.100.250  192.168.100.26       20

        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.1.1     192.168.1.2       1

      192.168.1.0    255.255.255.0      192.168.1.2     192.168.1.2       30

      192.168.1.2  255.255.255.255        127.0.0.1       127.0.0.1       30

    192.168.1.255  255.255.255.255      192.168.1.2     192.168.1.2       30

     192.168.47.0    255.255.255.0     192.168.47.1    192.168.47.1       20

     192.168.47.1  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.47.255  255.255.255.255     192.168.47.1    192.168.47.1       20

    192.168.100.0    255.255.255.0   192.168.100.26  192.168.100.26       20

   192.168.100.26  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.100.255  255.255.255.255   192.168.100.26  192.168.100.26       20

    192.168.132.0    255.255.255.0    192.168.132.1   192.168.132.1       20

    192.168.132.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.132.255  255.255.255.255    192.168.132.1   192.168.132.1       20

        224.0.0.0        240.0.0.0      192.168.1.2     192.168.1.2       30

        224.0.0.0        240.0.0.0     192.168.47.1    192.168.47.1       20

        224.0.0.0        240.0.0.0   192.168.100.26  192.168.100.26       20

        224.0.0.0        240.0.0.0    192.168.132.1   192.168.132.1       20

  255.255.255.255  255.255.255.255      192.168.1.2     192.168.1.2       1

  255.255.255.255  255.255.255.255     192.168.47.1    192.168.47.1       1

  255.255.255.255  255.255.255.255   192.168.100.26  192.168.100.26       1

  255.255.255.255  255.255.255.255    192.168.132.1   192.168.132.1       1

Standardgateway:   192.168.100.250

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

Ständige Routen:

  Keine

```

Hier nun vom Server aus:

```
PPro:/home/ruedi# traceroute 192.168.1.2

traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 40 byte packets

 1  192.168.1.2 (192.168.1.2)  29.440 ms  27.839 ms  25.955 ms

PPro:/home/ruedi# traceroute 192.168.100.26

traceroute to 192.168.100.26 (192.168.100.26), 30 hops max, 40 byte packets

 1  router (192.168.0.254)  1.034 ms  0.651 ms  0.575 ms

 2  * * *

 3  *

PPro:/home/ruedi# route -n

Kernel IP Routentabelle

Ziel            Router          Genmask         Flags Metric Ref    Use Iface

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 eth0
```

Echt sonderbar...

Gruss Sewulba   :Wink: 

----------

## bbgermany

Sage mal, kann es sein, dass einer von den VMWare Adaptern im 192.168.0.0/24 Netz ist?

MfG. Stefan

----------

## sewulba

 *bbgermany wrote:*   

> Sage mal, kann es sein, dass einer von den VMWare Adaptern im 192.168.0.0/24 Netz ist?
> 
> MfG. Stefan

 

Das ist richtig... Da ist der VMWare-Server drauf. Aber nicht im Betrieb!   :Laughing: 

----------

## bbgermany

Wie soll er denn dann in das Netz via OpenVPN routen, wenn er lokal Netzwerkschnittstellen hat, die diese IP aufweisen? Die Netzwerkadapter sind so wie es aussieht anscheinend doch im Betrieb!

MfG. Stefan

----------

## Anarcho

Daher sagte ich ja, gib mal einen traceroute. Da hat man ja gesehen das überhaupt nicht richtig geroutet wurde.

Du solltest dir dafür also ein anderes Netz aussuchen.

----------

## sewulba

 *Anarcho wrote:*   

> Daher sagte ich ja, gib mal einen traceroute. Da hat man ja gesehen das überhaupt nicht richtig geroutet wurde.
> 
> Du solltest dir dafür also ein anderes Netz aussuchen.

 

Ich werde es mal von meiner Freundin aus probieren mit meinem Laptop! Mal sehen, obs anders wird. Glaube es aber nicht!

----------

## bbgermany

 *sewulba wrote:*   

> 
> 
> Ich habe mich für die letzte Version entschieden. Bekomme die IP 192.168.0.250 zugewiesen. Aber ich komme trotzdem nicht ins 192.168.0.0er-Netz.
> 
> ```
> ...

 

Glaubst du, wenn du den Client in ein anderes Netz schiebst, dass der VMWare Adapter eine andere IP bekommt, als die, die er schon vorher hatte? Du musst die VMWare Netzwerkkonfiguration ändern.

MfG. Stefan

----------

## sewulba

 *bbgermany wrote:*   

>  *sewulba wrote:*   
> 
> Ich habe mich für die letzte Version entschieden. Bekomme die IP 192.168.0.250 zugewiesen. Aber ich komme trotzdem nicht ins 192.168.0.0er-Netz.
> 
> ```
> ...

 

Kann es vielleicht auch daran liegen, dass er den Eintrag für den Gateway nicht ändert? Bei meinem PPtP-VPN andert er nämlich den Gatewayeintrag und da komme ich in 192.168.0.0er Netz!

Anyway... Ich werde es am Wochenende mal von der Freundin aus probieren mmit dem Laptop.

Gruss Sewulba   :Shocked: 

----------

## bbgermany

Das ist durchaus möglich!

MfG. Stefan

----------

## sewulba

 *bbgermany wrote:*   

> Das ist durchaus möglich!
> 
> MfG. Stefan

 

Hallo...

Ich habe es endlich mal geschafft und habe mich von meiner Freundin aus mit meinem Laptop auf den Openvpn verbunden. Gleiches Phenomen wie auch vom Geschäft aus. Ich komme einfach nicht ins 192.168.0.x-Netz rein.

Alle Versuche den Gatewayeintrag beim Verbinden mit dem OpenVPN-Server auf 192.168.1.1 zu setzen laufen. schief. Ich finde einfach nicht die korrekte Einstellung in der Server.conf um den Gatewayeintrag auf 192.168.1.1 zu pushen. Er macht es einfach nicht. Gibt aber auch keinen Fehler aus.

Wie muss der Eintrag den korrekt aussehen?

Gruss Sewulba   :Crying or Very sad: 

----------

## bbgermany

Hast du endlich die VMWare Netzwerkeinstellungen geändert?

MfG. Stefan

----------

## sewulba

Ich habe die Lösung.

Windows selbst ist daran schuld. Es scheint so als würde Windoof dem OpenVPN nicht erlauben die Routen zu setzten:

```
Sun Mar 16 01:31:20 2008 route ADD 192.168.0.0 MASK 255.255.255.0 192.168.2.5

Sun Mar 16 01:31:20 2008 ROUTE: route addition failed using CreateIpForwardEntry: Ein oder mehrere Argumente sind ungültig.   [if_index=11]

Sun Mar 16 01:31:20 2008 Route addition via IPAPI failed

Sun Mar 16 01:31:20 2008 route ADD 192.168.1.1 MASK 255.255.255.255 192.168.2.5

Sun Mar 16 01:31:20 2008 ROUTE: route addition failed using CreateIpForwardEntry: Ein oder mehrere Argumente sind ungültig.   [if_index=11]

Sun Mar 16 01:31:20 2008 Route addition via IPAPI failed

Sun Mar 16 01:31:20 2008 Initialization Sequence Completed
```

Habe diese dann per Hand dazugefügt, und siehe da: Es funktioniert...

```
IPv4-Routentabelle

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

Aktive Routen:

     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik

          0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.100     25

        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306

        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306

  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306

      192.168.0.0    255.255.255.0      192.168.2.5      192.168.2.6     31

      192.168.1.0    255.255.255.0   Auf Verbindung     192.168.1.100    281

    192.168.1.100  255.255.255.255   Auf Verbindung     192.168.1.100    281

    192.168.1.255  255.255.255.255   Auf Verbindung     192.168.1.100    281

      192.168.2.1  255.255.255.255      192.168.2.5      192.168.2.6     31

      192.168.2.4  255.255.255.252   Auf Verbindung       192.168.2.6    286

      192.168.2.6  255.255.255.255   Auf Verbindung       192.168.2.6    286

      192.168.2.7  255.255.255.255   Auf Verbindung       192.168.2.6    286

        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306

        224.0.0.0        240.0.0.0   Auf Verbindung       192.168.2.6    286

        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.1.100    281

  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306

  255.255.255.255  255.255.255.255   Auf Verbindung       192.168.2.6    286

  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.1.100    281

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

Ständige Routen:

  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik

      192.168.2.1  255.255.255.255      192.168.2.5       1

      192.168.0.0    255.255.255.0      192.168.2.5       1

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

```

Außerdem verwende ich nun nicht mehr tap0, sondern tun0.

Werde in einem Windoof-Forum, wie ich Windows dazu bringe die Routen von OpenVPN zu akzeptieren.

Habe aber dennoch noch irgendwo einen Fehler drin... Möchte ich zugriff auf den Router nehmen mit der IP 192.168.0.254 komme ich leider nicht hin.

```
>tracert 192.168.0.254

Routenverfolgung zu 192.168.0.254 über maximal 30 Abschnitte

  1    42 ms    31 ms    18 ms  192.168.2.1

  2     *        *        *     Zeitüberschreitung der Anforderung.

  3     *        *        *     Zeitüberschreitung der Anforderung.

  4     *        *        *     Zeitüberschreitung der Anforderung.

  5     *        *        *     Zeitüberschreitung der Anforderung.

  6     *     ^C
```

192.168.2.1 ist der OpenVPN-Server. 192.168.0.11 kann ich anpingen. Das ist die interne IP des VPN-Servers... Woran hängt es jetzt noch?

Gruss Sewulba   :Embarassed: 

----------

## sewulba

Habe ich hier vielleicht einen Fehler drin?

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

/sbin/iptables -A INPUT -p udp --dport 1194 -j ACCEPT

/sbin/iptables -A INPUT -i tun0 -j ACCEPT

/sbin/iptables -A OUTPUT -o tun0 -j ACCEPT

/sbin/iptables -A FORWARD -i tun0 -j ACCEPT
```

Gruss Sewulba

----------

## sewulba

Juchhu ich habe die Lösung...

Also für meinen Fall geht TAP0 gar nicht. Habe alles auf Tun0 umgestellt. Interne IP OVPN-Server ist 192.168.0.11.

Tun0 ist 192.168.2.1.

Der eigentlich Fehler bei mir war, dass ich eine Statische Route erstellen musste auf meinem Router. 192.168.2.0 255.255.255.0 192.168.0.11.

Das war der eigentliche Fehler. Von außerhalb ging zwar 192.168.0.11 anzupingen und zu verwenden, aber ins 192.168.0.xer Netz kam ich nicht. Weil die Pakete nicht mehr den Weg zum OVPN-Server gefunden haben. Deswegen die statische Route auf meinem Router. Mein OVPN-Server ist nicht der Router.

Ich komme also nun von Außerhalb ins komplette Netz 192.168.0.0 bei mir zu Hause über das OVPN.

2ter schöner Nebeneffekt ist, dass wenn ich mich vom internen Netz aus einwähle, dann wird die Verbindung auch getunnelt. Für den Fall, dass ich irgendwo mal WLAN einsetze und das verwendete Teil nicht mein WPA2-TKIP kann ist das OVPN nen Klasse ersatz finde ich.

Wenn Interesse an meiner Konfiguration besteht, kann ich sie gerne hier posten.

Gruss Sewulba   :Wink: 

----------

