OpenVPN und Routing

[orangutanklaus]

tach zusamm,

ich habe ein Routingproblem in einem Netzwerk und kann einfach keine Lösung finden...
Erklärung (siehe beigefügtes Bild):
WS3 ist OpenVPN-Client und kann mit der derzeitigen Konfiguration auf das hinter einer Firewall liegende Netz 10.1.5.0/24 (Server1, Server2 und WS1) zugreifen, nicht aber auf 172.24.4.0/24. Für OpenVPN wird das Subnet 10.2.6.0 verwendet.
Server2 hängt in den Netzen 10.1.5.0/24 und 172.24.4.0/24 und fungiert zwischen beiden Netzen als Router.
Der OpenVPN-Client soll aber auch Zugriff auf das Netz 172.24.4.0/24 haben. Wie muss ich die Konfiguration ändern, damit dies funktioniert? Ich komme selbst irgendwie nicht weiter. Danke Euch für jede Hilfe :-)

openvpn.conf Server1:

port 1194
proto udp
mode server
ifconfig 10.2.6.1 255.255.255.0
ifconfig-pool 10.2.6.2 10.2.6.10
dev tap
mssfix
client-to-client
tls-server
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0
keepalive 10 60
float
comp-lzo
verb 0

openvpn.conf Client:

port 1194
proto udp
remote xxx.xxx.xxx.xxx
dev tap0
mssfix
tls-client
ns-cert-type server
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
ping-exit 10
comp-lzo
pull
float
route 10.1.5.0 255.255.255.0 10.2.6.1
verb 2

 

[h0sch1]

Hi


Möglichkeit 1:
Server openvpn.conf

port 1194
proto udp
mode server
ifconfig 10.2.6.1 255.255.255.0
ifconfig-pool 10.2.6.2 10.2.6.10
push "route 10.1.5.0 255.255.255.0 10.2.6.1"
push "route 172.24.4.0 255.255.255.0 10.1.5.28"
dev tap
mssfix
client-to-client
tls-server
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0
keepalive 10 60
float
comp-lzo
verb 0

Möglichkeit 2:

Client openvpn.conf

port 1194
proto udp
remote xxx.xxx.xxx.xxx
dev tap0
mssfix
tls-client
ns-cert-type server
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
ping-exit 10
comp-lzo
pull
float
route 10.1.5.0 255.255.255.0 10.2.6.1
route 172.24.4.0 255.255.255.0 10.1.5.28
verb 2

========================================
Hier sind noch meine OpenVPN.conf's

Server

port 1194
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
mode server
ifconfig 192.168.80.1 255.255.255.0
ifconfig-pool 192.168.80.11 192.168.80.17 255.255.255.0
push "route 192.168.80.0 255.255.255.0 192.168.80.1"
push "route 192.168.5.0 255.255.255.0 192.168.80.1"
push "dhcp-option DNS 192.168.5.3"
tun-mtu 1300
tun-mtu-extra 32
tls-server
keepalive 10 120
cipher AES-256-CBC
comp-lzo
verb 3

Client

client
dev tap
proto udp
remote SERVER 1194
ca ca.crt
cert CLIENT.crt
key CLIENT.key
cipher AES-256-CBC
comp-lzo
tun-mtu 1300
tun-mtu-extra 32
pull
verb 4

 

[Binfort]

Hallo,

ich habe zu dem Thema mal ne andere Frage.

Ich versuch gerade in ner Testumgebung einen Win2k Rechner als OpenVPN Client mit nem FreeBSD Rechner als OpenVPN Server zu verbinden.
Verschlüsselung und Authentifizierung über OpenSSL.
Die Konfig-Dateien von H0sch1 waren nachvollziehbar.

Frage:

Müssen die tap-Devices an beiden Rechnern auch eine IP zugewiesen bekommen, oder bekommen sie die IP aus dem jeweiligen .conf - File?

Könnt ihr einmal in verständlichen Worten beschreiben wie die Tunnelung im Beispiel funktioniert? Damit meine ich hauptsächlich wie die Daten im Rechner weitergegeben werden, also wann welche Netzwerkverbindung wie arbeitet...

Hoffe mal das ich bei euch richtig bin, thx

 

[h0sch1]

Hi Binfort

Also, du musst bei der OpenVPN keinem Device eine IP geben, egal welches OS.
Das übernimmt die OpenVPN für dich.
Beim Server ist diese Zeile dafür verantwortlich:
( Aus meiner Server OpenVPN.conf )

ifconfig 192.168.80.1 255.255.255.0

Und diese Zeile Teilt dem Client eine IP aus dem Pool 11-17 zu

ifconfig-pool 192.168.80.11 192.168.80.17 255.255.255.0

Könnt ihr einmal in verständlichen Worten beschreiben wie die Tunnelung im Beispiel funktioniert? Damit meine ich hauptsächlich wie die Daten im Rechner weitergegeben werden, also wann welche Netzwerkverbindung wie arbeitet...

Ok, ich probier mal mein Glück

Als erstes zum Server:
OpenVPN wird gestartet --> OpenVPN vergibt die IP aus der OpenVPN.conf dem Device Tap/Tun --> OpenVPN wartet auf einen Client der über ein Device ( Lan / Inet ) auf dem Port aus der OpenVPN.conf zugreifen möchte.

Client:
OpenVPN wird als Client gestartet --> OpenVPN versucht einen Verbindung zu dem in der Openvpn.conf stehenden Server zu bekommen --> der Client versucht sich mit den SSL-Schlüsseln zu authentifizieren
--> Authentifizierung war erfolgreich --> Server teilt dem Client seine IP, Routen
und den DNS-Eintrage mit --> VPN steht!
--> Authentifizierung war nicht erfolgreich --> Server lässt keine Verbindung zu
und bricht mit einem Fehler ab

Jetzt gehen wir einmal davon aus, dass die VPN steht!
Wenn mein Client nun die IP 192.168.80.11 bekommen hat und mein Server hat die 192.168.80.1, dann sieht es so aus:

Wenn ich nun vom Client einen Ping an den Server sende, wird dieser über das tun/tap
device mit dem ssl zertifikat von dem Client verschlüsselt und an den Server geschickt, dieser entschlüsselt mit seinem ssl zertifikat wieder das Packet und beantwortet den Ping mit einem Pong. Dieser Pong wird dann wieder verschlüsselt und zum Client geschickt.


Naja, vieleicht hilft es dir ja.

 

[Binfort]

Spitze, jetzt wird mir einiges klar....

Kannst Du mir mal bitte noch kurz die Routenkonfiguration beschreiben?

Ich würde die "push_route" Möglichkeit aus der server.conf bevorzugen.

Meine Frage:

Wie müsste, ausgehend von der ServerIP 192.168.80.1/24, die Route dem Client übergeben werden, damit dieser ein Netz: z.B. 192.168.10.0/24 hinter dem OpenVPN Server erreichen kann? Welche IP's müssen in der Route alles eingetragen werden?

thx

 

[h0sch1]

Hi Binford

Deine Server OpenVPN.conf müsste dann so aussehen:

port 1194
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
mode server
ifconfig 192.168.80.1 255.255.255.0
ifconfig-pool 192.168.80.11 192.168.80.17 255.255.255.0
push "route 192.168.80.0 255.255.255.0 192.168.80.1"
push "route 192.168.10.0 255.255.255.0 192.168.80.1"
tun-mtu 1300
tun-mtu-extra 32
tls-server
keepalive 10 120
cipher AES-256-CBC
comp-lzo
verb 3

Jetzt sollte der/die Client(s) auf das Netz 192.168.10.0/24 zugreifen können.
Das funktioniert natürlich nur wenn dein OpenVPN-Server auch auf diese Netz zugreifen kann.

Kannst Du mir mal bitte noch kurz die Routenkonfiguration beschreiben?

Zu deiner Frage!

Ist eigentlich kanns einfach. Mit dem "push" kannst du veranlassen, wenn sich ein Client anmeldet,dass er automatisch die Anweisung bekommt, alles was nach dem "push" steht bei sich lokal ( auf dem Client) auszuführen.

auf dem Client würdest du um in das netz 192.168.10.0/24 folgende Zeile eingeben:

route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.80.1

Ein Eintrag für die push Zeile sieht genauso aus, nur dass du einfach alle Optionen für den route Befehl weg lässt.
Die musst du deswegen weglassen, weil die Befehlssyntax unter z.B. Windows ganz anders aussieht. Die OpenVPN über gibt jedem Client automatisch die richtige Syntax, je nachdem verwendeten OS.

Die push Option nutze ich eigentlich ganz gern, weil wenn mal eine neue Route hinzukommt oder es sich etwas ändert muss ich es nur an einer Stelle ändern.
( Der Mensch ist halt doch faul! )

 

[orangutanklaus]

tach zusamm,

Danke für Eure Antworten und special thanks an h0sch1! Dank dieser Ansätze läuft jetzt alles so, wie ich mir das vorgestellt habe.
Ich verwende fogende configs:
OpenVPN-Server:

port 1194
proto udp
mode server
ifconfig 10.2.6.1 255.255.255.0
ifconfig-pool 10.2.6.2 10.2.6.20
push "route-gateway 10.2.6.1"
route 172.24.4.0 255.255.255.0 10.1.5.28
push "route 10.1.5.0 255.255.255.0"
push "route 172.24.4.0 255.255.255.0"
dev tap
mssfix
client-to-client
tls-server
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
tls-auth ta.key 0
keepalive 10 120
float
comp-lzo
verb 0

OpenVPN-Client:

port 1194
proto udp
remote xxx.xxx.xxx.xxx
dev tap
mssfix
tls-client
ns-cert-type server
ca ca.crt
cert client.crt
key client.key
tls-auth ta.key 1
ping-exit 10
comp-lzo
pull
float
verb 2

 

[Binfort]

Die push Option nutze ich eigentlich ganz gern, weil wenn mal eine neue Route hinzukommt oder es sich etwas ändert muss ich es nur an einer Stelle ändern.
( Der Mensch ist halt doch faul! )

Genau aus diesem Grund werd ich die "push route" Konfiguration auch benutzen und weil ich dies dann bei ner Fehlermeldung auch gleich mal als Erstes ausschliessen kann.

Ich werd das Ganze Dienstag Abend mal an die beiden Rechner übergeben und das Ergebnis posten.

thx für die Antworten

 

[h0sch1]

Hi Binford und orangutanklaus

hab hier noch ein kleines Script für euch gebaut.
Das erleichtert euch auf jedenfall das erstellen der Zeritfikate!

Einfach auspacken und die create_openvpn_keys.sh Datei anpassen und danach starten

Viel Spaß dabei

P.S. Vor dem entpacken die Endung .zip entfernen

 

[Binfort]

die Verschlüsselung läuft bei mir komplett über OpenSSL, kann ich denn eine sichere Verschlüsselung auch mit OpenVPN gewährleisten?

 

[h0sch1]

Hi Binfort

Bei meiner Konfig läuft nur die Authentifizierung über SSL die Daten Packete werden mit AES 256Bit verschlüsselt.

In dem Create_OpenVPN_Keys kannste die Zeit einstellen, wie lange die Schlüssel gültig sein sollen.

 

[Binfort]

In dem Create_OpenVPN_Keys kannste die Zeit einstellen, wie lange die Schlüssel gültig sein sollen.

Das ist im Moment noch gar nicht mein Problem...

Habe gestern die Konfigurationen in die Testumgebung übertragen, nach ner Weile hab ich dann auch gesehen, das ich eigentlich einen IP Tunnel und keinen Netzwerktunnel brauche. Das bedeutet ich arbeite mit "dev tun".
Die Erläuterungen aus den Beiträgen haben aber dazu beigetragen, das ich den IP Tunnel ohne Probleme konfiguriert habe, nicht zuletzt weil die Optionen annähernd gleich sind .

Einzig die Routen machen mir noch ein paar Probleme. Folgendes Problem:
zwei Testrechner befinden sich per Crossover in einem 10.0.0.0 / 24er Netz
ein Rechner OpenVPN Client und einer OpenVPN Server
der Server zusätzlich eine zweite Netzwerkkarte: 192.168.20.** / 24er Netz
das OpenVPN Netz: 192.168.10.0 Server mit 1 und der Client zwischen 2 und 10

wie muß ich jetzt dem Client mit push "route ...." die Route übergeben, will sagen welche Schnittstelle ist für die Weiterleitung ins 192.168.20.0 Netz verantwortlich?

 

[h0sch1]

Hi Binford

Sorry hat einbischen gedauert, war ein paar Tage unterwegs.

Also so wie ich den Text von dir jetzt verstanden habe, musst du folgende Zeilen
hinzufügen:

Server:

push "route 192.168.10.0 255.255.255.0 192.168.10.1"
push "route 192.168.20.0 255.255.255.0 192.168.10.1"

Bei den PC's aus dem Netz 192.168.20.0/24 musst du die Default route auf den VPN-Server legen oder einen Routingeintrag vornehmen:
z.B.

Linux

route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.20.1

Windows

route add 192.168.10.0 mask 255.255.255.0 192.168.20.1

Vergiss nicht auf deinem Server das Forwarding zu aktivieren!

 

[Binfort]

@ h0schi: danke für die Antwort sooo lange war das gar nicht...

forwarding ist aktiviert, der Routingablauf ist mir jetzt auch klar,

nur noch zwei kleine Sachen:

Wenn ich Deine vorherigen Antworten richtig deute muß ja der Server in der .conf das push "route..." bekommen nicht der Client, oder?

Bei den PC's aus dem Netz 192.168.20.0/24 musst du die Default route auf den VPN-Server legen oder einen Routingeintrag vornehmen

Muß dieser Eintrag auch in die .conf des OpenVPN Clients, oder muß dieser Eintrag ins Betriebssystem übergeben werden?

morgen kann ich das erst wieder testen, also lass Dir Zeit

 

[h0sch1]

Hi Binfort

Jup du hast recht, der Eintrag muss natürlich in .conf des Servers und nicht in die des clients.
Zählt das, wenn ich sage, ich wollte dich nur mal testen? *G*

 

[Binfort]

Ich habe es auch nicht anders verstanden meine zweite Frage hat sich übrigens erledigt, der Eintrag für die Rechner im zwanziger Netz wird wohl gebraucht damit die Rechner auch in mein "virtuelles" zehner Netz kommen - das will ich ja erst mal gar nicht erreichen...

 

[Binfort]

Hallo nochmal,

ich habe die Konfiguration in die Testumgebung übertragen. Anfangs übernahm der VPN Client die Route nicht vom Server und ich konnte die zweite Netzwerkkarte des Servers, zu Erinnerung: die im 20er Netz... , nicht anpingen!
Beim Starten des VPN Clients konnte ich im Log sehen das dem Client zwar versucht wird die Route zu übergeben, dieser aber mit der Fehlermeldung: "Gateway ist not reachable....." ablehnte.

Ich bekam dann aber den Tip im pusch "route...." das Gateway wegzulassen. Danach übernahm der Client anstandslos die Route und ich konnte ohne Probleme die 192.168.20.1 anpingen!!!

so sieht der Teil in meiner verwurschtelten server.conf jetzt aus...

push "route 192.168.10.0 255.255.255.0"
push "route 192.168.20.0 255.255.255.0"

als Gateway wurde nicht die originale SerevrIP genommen, sondern eine aus dem virtuellen Subnetz... (gw: 192.168.10.5 - aber Server lauscht direkt auf der 1)

im Moment kann der VPNClient aber nur eine Adresse aus dem 20er Netz erreichen, nämlich die zweite Netzwerkkarte des VPNServers. Niemanden sonst Forwarding ist aktiviert.

Bei netstat -r zeigt er auch die passenden Routen an!

Müssen jetzt noch zusätzliche Routing - Konfigurationen am Server selber getroffen werden???
Und warum muß ich dem Client überhaupt die erste Route (die für das virtuelle Netz) übergeben???

hoffe mal das ich Dir wieder ne schöne Denksportaufgabe gestellt hab, und teste mich bitte nicht wieder

 

[h0sch1]

Hi Binfort

als Gateway wurde nicht die originale SerevrIP genommen, sondern eine aus dem virtuellen Subnetz... (gw: 192.168.10.5 - aber Server lauscht direkt auf der 1)

Das ist aber komisch.
Also bei mir funktioniert das mit dem Routen super.
Was ich bis jetzt festgestellt habe ist, dass windows einbischen länger braucht um die IP + Routen zuzuweisen, vieleicht liegt es ja daran.
Im Fall Windows als OVPN Client hab ich die Routen zusätzlich manuell mit der Option "-p" --> persistent vergeben

Müssen jetzt noch zusätzliche Routing - Konfigurationen am Server selber getroffen werden???
Und warum muß ich dem Client überhaupt die erste Route (die für das virtuelle Netz) übergeben???

Zu 1:
Normal nicht!
Zu 2:
Ist eigentlich nur zur Sicherheit, die Route ( 192.168.10.0 ) sollte der Client eigentlich automatisch erstellen. Hat bei mir jedoch nicht immer funktioniert ( beim Mac OS X 10.4.x )
Deswegen schreib ich das jetzt eigentlich immer mit rein, bis jetzt hat es noch keinen Client gestört

 

[Binfort]

alles klar - die OpenVPN Verbindung steht, die Routen haben wunderbar hingehauen und ich erreiche jetzt auch die Rechner im 192.168.20.0er Netz - mußte nur auf den Routern im Netz ne Route in mein virtuelles VPN Netz übergeben, wenn ich Deinen Thread vom 13.03. richtig gelesen hätte

Bei den PC's aus dem Netz 192.168.20.0/24 musst du die Default route auf den VPN-Server legen oder einen Routingeintrag vornehmen...

hätte ich gestern gar keine Probleme gehabt - heißt nich umsonst: wer lesen kann ist klar im Vorteil...

als wir beim VPN Client in die Netzwerkverbindung 10.0.0.2 als Standardgateway die 10.0.0.1 (... der VPN-Server...) eingetragen hatten, konnten alle push "route..." Einträge in der server.conf auskommentiert werden

soll heißen: in der physikalisch vorhandenen LANVerbindung auf dem VPN Client wird als Standardgateway die IP des VPN Servers, und zwar die auf welcher er lauscht, eingetragen und man braucht dann, vorrausgesetzt der Server kennt sein eigenes Standardgateway/default_router, keine Routen übergeben

allerdings sollte man die Erfahrung mit den Routen einmal gemacht haben, schon vom allg. Verständnis her

ich schreib gerade noch die confs ins Reine, dann poste ich sie im Thread und dann sollte die Sache abgeschlossen sein, denke ich

danke für Deine Hilfe H0schi

Gruß

 

[h0sch1]

Hi Binfort

Super dass es jetzt bei dir klappt!

Ja ich glaub das mit dem posten von deinen *.conf Files kann nicht schaden.
So können andere das ganze besser nachvollziehen.

 

[skockiii]

Hallo jungs,

da ich gerade auch ziemlich am verzweiflen bin dachte ich, ich stell meine Frage auch mal hier.

Situation ist wie folgt:
Ich habe einen Linux server (Suse9.1) auf dem openvpn 2.0.5 installiert ist mit 3 Netzwerkkarten.
1 fürs Internet und die anderen beiden gehen jeweils in ein lokales netzt. (192.168.0.* und 1.*). Die Internet ip adresse ist dynamisch aber durch dyndns halt immer zu erreichen.
Der Clinet ist ein Windows XP Rechner.

Ich habe das hier mal als Testumgebung aufgebaut und es hat auch geklappt. Bloß 30 min Später ging nix mehr da er immer sagt TLS handshake failed.

edit: oO Gerade nochmal getestet nun gehts wieder. Woran kann das liegen.

Hier meine configs:
server.conf

port 5000
proto udp
dev tap

#dev-node openvpn
mode server
tls-server

ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.2 10.0.0.5

push "route 192.168.1.0 255.255.255.0 10.0.0.1"

cipher AES-256-CBC

ca ca.crt
cert server.crt
key server.key

dh dh1024.pem

keepalive 10 120
float
verb 3

#####################################

client config

remote 192.168.1.27 5000

client
float
dev tap
proto udp
cipher AES-256-CBC
tls-client


ca "C:\\bla\\ca.crt"
cert "C:\\bla\\client1.crt"
key "C:\\bla\\client1.key"

pull
verb 3

###############################

Nicht von den ips verunsichern lassen... Ist erstmal nur eine Testumgebung und Verbindung von innen.
Aber woran kann das liegen das der mir sagt TLS-handshake failed. Das ging den ganzen abend nicht vorgestern.
Ich habe auch mit hoshis script die certifikate neu erstellt etc.

Da es sehr dringend ist und auch stabil laufen muss wäre ich über eine schnelle antwort sehr verbunden.

Mit freundlichem Gruß
johannis

 

[h0sch1]

Hi skockiii

Das Problem hab ich vor kurzem auch bei 2 XP Kisten von einem Kunden gehabt.
Hab dann alle Hotfixes für das SP2 installiert und seit dem keine Probleme mehr.

Auch kommt es im Zusammenhang mit VMWare ( egal ob Player, Workstation oder Server)
zu dem Problem. Anscheinend vertragen sich der VMware TUN/TAP treiber mit dem von OpenVPN nicht.

Bei WindowsXP mit SP1 hatte ich bis jetzt noch nie Probleme, ausser wenn VMWare installiert war.

Wenn keins der oben genannten Sachen zutrifft, könnte es auch noch an einer unterschiedlichen Uhrzeit liegen.


mfg Hoschi

 

[Binfort]

Moin Moin

das Problem mit dem TLS Handshake hatte ich bei mir auch, und zwar genau dann wenn ich dem OpenVPN Server die virtuelle IP fest zuweisen wollte.

In Deiner .conf sind diese Zeilen dafür verantwortlich:

mode server
tls-server

ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.2 10.0.0.5

wenn Du statt dessen folgende Zeilen eingibst:

mode server
server 10.0.0.0 255.255.255.0

lauscht der OpenVPN Server im 10er Netz und gibt dem Server automatisch eine daraus, (99% die 10.0.0.1) und die ganze TLS Geschichte fällt dann aus (ich weiß auch nicht was die bewirkt, finde das aber noch raus

die "tls-client" Zeile in der VPN Client .conf mußt Du dann auskommentieren oder löschen

danach sollte der VPN Tunnel stabil laufen, einen Dauertest mache ich die Tage

Gruß

 

[Binfort]

meine Konfigurationen

nach Abschluß der Konfiguration poste ich nun meine .conf Zeilen:

zuerst die server.conf

port 443

proto udp

dev tun

tun-mtu 1492
fragment 1300
mssfix

ca /usr/local/etc/openvpn/vpn-ca.pem
cert /usr/local/etc/openvpn/servercert.pem
key /usr/local/etc/openvpn/serverkey.pem

dh /usr/local/etc/openvpn/dh1024.pem

mode server
server 192.168.10.0 255.255.255.0

push "redirect-gateway local def1"
push "dhcp-option DNS 192.168.20.2"
push "dhcp-option WINS 192.168.20.3"

# push "route 192.168.10.0 255.255.255.0"
# push "route 192.168.20.0 255.255.255.0"

auth SHA1
cipher AES-256-CBC
comp-lzo

# max-clients 100

# user nobody
# group nobody

persist-key
persist-tun

status openvpn-status.log

verb 6

und hier die client.ovpn (für Win2k):

client
float
dev tun
tun-mtu 1492

fragment 1300
mssfix
dev-node tap_device

proto udp
remote 10.0.0.1 443

ca vpn-ca.pem
cert testclientcrt.pem
key chefkey.pem

auth SHA1
cipher aes-256-cbc

nobind
comp-lzo
persist-key
persist-tun
verb 3

das wars, hat Spass gemacht, jetzt kämpf ich mich nochmal durch die Verschlüsselung mit OpenSSL...

 

[skockiii]

Hallo Jungs,

ich komme bei der Sache mit den Routen nicht weiter.
Hier erstmal meine configs....

Server
###################################################

port 5000
proto udp
dev tap

mode server
tls-server

ifconfig 10.0.0.1 255.255.255.0
ifconfig-pool 10.0.0.2 10.0.0.5

push "route 192.168.200.0 255.255.255.0 10.0.0.1"
push "route 10.0.0.0 255.255.255.0 10.0.0.1"

cipher AES-256-CBC

ca ca.crt
cert server.crt
key server.key

dh dh1024.pem

keepalive 10 120
float
verb 3

###############################################

Client

###############################################

port 5000
remote name.dyndns.org

client
float
dev tap
proto udp
cipher AES-256-CBC
tls-client


ca "C:\\bla2\\ca.crt"
cert "C:\\bla2\\client1.crt"
key "C:\\bla2\\client1.key"

pull
verb 3

############################################

Ich will im 192.168.200.0 netz auf einen rdp server aber die route klappt nicht

Es ist sehr wichtig das das diese woche noch klappt.

Wäre über eine schnelle antwort sehr erfreut

mfg
skocki