OpenVPN

Re: OpenVPN

techstep — Mon, 05 May 2014 19:05:31 GMT

1.) bei deinem Router musst du eine statische Route für das 10.8er Netz setzen.
2.) Sehe ich in der config keine cipher Direktive, startet der Server überhaupt ohne ? (Logs)
3.) Verwendest du zufällig einen OpenWRT Router ?
4.) Hast du IP Forwarding aktiviert ? [1]
5.) Schalt ggf. mal deine Firewall ab bzw. erweitere den Scope auf das 10.8 Netz.

Default werden in Windows ICMP Pakete (ping) aus fremden IP Bereichen verworfen.

[1]: http://openvpn.net/index.php/open-source/faq/77-server/265-how-do-i-enable-ip-forwarding.html

Re(6): OpenVPN

gibberish — Tue, 11 Feb 2014 18:05:05 GMT

Kentniss

Anders rum.....

Re(5): OpenVPN

ZombyKillah — Tue, 11 Feb 2014 17:58:34 GMT

Wie schon geschrieben ... ich habe nie verstanden weshalb es anfälliger sein soll.
Hatte es einfach zur Kentniss genommen und ignoriert ...

Die 1% Ack. Daten verkraftet der Tunnel eher, als wie wenn die Nachricht nicht in der richtigen Reihnfolge ankommt ... und anstelle von 1 Paket gleich mehrere neu übertragen werden müssen.

Re(4): OpenVPN

MG — Sun, 09 Feb 2014 22:10:53 GMT

UDP wird üblicherweise aus Sicherheitstechnischen Gründen genommen ... habe
zwar nie verstanden welches Problem TCP macht, aber angeblich werden Man in
the Middle Angriffe durch TCP möglich ...

Das ist aus der Luft gegriffen.
OpenVPN ist verschlüsselt. Daher sind Man in the Middle Attacken kein realistisches Szenario.
Und auch wenn dies nicht so wäre. Ein MitM Angriff verlangt, dass der Angreifer zugriff auf den Switch/Router hat. Wenn er da einfach einen Mirrorport einrichtet, dann ist es dem MitM völli9g egal, ob UDP oder TCP daherkommt. Alleine wenn er auf ARP-Spoofing oder MAC-Floodding angewiesen wäre, hätte TCP für den MitM Vorteile, weil er da sicher sein kann, alles mitzubekommen.

Der wesentliche Unterschied zwischen UDP und TCP ist, dass UDP die Datenwindows nach dem Fire&Forgett Prinzip liefert. D.h. es ist dem Sender völlig egal, ob die Daten beim Empfänger auch vollständig ankommen.

TCP hingegen wartet nach jedem gesendeten Window auf eine Bestätigung bevor das nächste Versendet wird. Und wenn es ein Problem gibt, wird die Windowsize verklei9nert und erneut gesendet.

D.h. es ist schon von daher viel langsamer, weil nach jedem Datenpackerl auf eine Bestätigung gewartet wird.

Dann kommt da noch ein zusätzliches Problem dazu. Innerhalb der OpenVPN Pakete sind ja in der Regel wieder TCP Pakete. D.h. wenn es jetzt ein Packerl verloren geht, fordert es OpenVPN nochmals an, der TCP Stream innerhalb der getunnelten Pakete tut das aber auch nochmal.

D.h. im Fehlerfall wird statt doppelt, gleich viermal gesendet. Und ebensooft mal auf Bestätigung gewartet. Entsprechend geht die Bandbreite in die Knie.

Re(4): OpenVPN

thE — Fri, 07 Feb 2014 10:29:47 GMT

aber angeblich werden Man in the Middle Angriffe durch TCP möglich ...

Also das stelle ich mir bei UDP, welches keine direkte Verbindung OFFEN hält eigentlich leichter vor als mit TCP...

Re(3): OpenVPN

ZombyKillah — Wed, 05 Feb 2014 20:24:53 GMT

Weil UDP in Zusammenhang mit nur über NAT erreichbar oft Probleme macht ...
Von der Perfomance her braucht es etwas mehr Leistung, aber alles in allen egal.

UDP wird üblicherweise aus Sicherheitstechnischen Gründen genommen ... habe zwar nie verstanden welches Problem TCP macht, aber angeblich werden Man in the Middle Angriffe durch TCP möglich ...

Re(4): OpenVPN

sum — Wed, 05 Feb 2014 10:47:05 GMT

ok werde ich testen

Re(2): OpenVPN

MG — Wed, 05 Feb 2014 10:29:15 GMT

Ich würde mal mit TCP anstelle UDP testen ...

Sehr schlechte Idee. Wieso für einen Tunnel TCP bemühen? Die Flow Control macht das je nach TTL extrem langsam.

Re(3): OpenVPN

MG — Wed, 05 Feb 2014 10:27:00 GMT

außerdem ist das Internet am Client sofort Tot wenn ich die Verbindung
aufbaue.

KLein Wunder!
Du redirectest ja das Gateway. Und am Server wird wohl kein NAT für das VPN Netz aktiv sein.
Lass diese Direktive weg, und das Problem ist behoben.

Re(4): OpenVPN

sum — Wed, 05 Feb 2014 10:19:29 GMT

egal, Verbindung wird aufgebaut, jedoch geht dann das Internet nicht und ich finde nur den server

Re(3): OpenVPN

thE — Wed, 05 Feb 2014 09:53:29 GMT

Die Verbindung steht, wenn du das push route weglässt oder allgemein steht die jetzt?

Re(2): OpenVPN

sum — Wed, 05 Feb 2014 07:45:19 GMT

Ok, werde ich umstelle.
Ich habe am Server und auch am Client den Port 1194 ein- und ausgehend freigegeben.

Re(2): OpenVPN

sum — Wed, 05 Feb 2014 07:43:51 GMT

Verbindung steht mittlerweile. Ich kann die Adressen 10.8.2.X Bereich pingen und auch die Serveradresse 192.168.1.178 kann ich pingen. Mehr jedoch nicht, außerdem ist das Internet am Client sofort Tot wenn ich die Verbindung aufbaue.

Re: OpenVPN

Somnatic — Tue, 04 Feb 2014 17:39:45 GMT

Erstmal die Logs vom Serverstart posten und auch das vom Client wenn er sich verbinden will. Kommt die Verbindung überhaupt zustande (das steht im Log). Wenn das der Fall ist, dann kümmern wir uns ums Routing. Hierzu wäre es notwendig zu wissen, welche IP-Adressbereiche du in den beiden Netzwerken verwendest.

Re: OpenVPN

ZombyKillah — Tue, 04 Feb 2014 17:11:07 GMT

Ich würde mal mit TCP anstelle UDP testen ...

Was sagt das log?
Kommt die Verbindung zu stande oder bekommst du ein Timeout?
Wie sieht die Firewall-Konfig von device tun am Server aus?

Re: OpenVPN

thE — Tue, 04 Feb 2014 16:49:37 GMT

Kann der Client überhaupt die Server-IP im 10.8.2.X Bereich ansprechen? Kann er seine 10.8.2.X Adresse selbst anpingen, bzw. bekommt er überhaupt eine?

Zum Testen lass mal das weg:
push "route 192.168.1.0 255.255.255.0"

Das sagt ja aus, dass nur Anfragen für 192.168.1.X ans VPN geschickt werden.. Mit dem haben paar Probleme. Zum Testen also mal weg machen und gucken ob VPN funktioniert!

Re(3): OpenVPN

sum — Tue, 04 Feb 2014 14:39:57 GMT

Re(2): OpenVPN

sum — Tue, 04 Feb 2014 13:43:41 GMT

intern ja, extern nicht

Re: OpenVPN

Binchen — Tue, 04 Feb 2014 13:40:42 GMT

IP von my-server-2
Beim Route Portweiterleitung eingerichtet zu 192.168.1.178

Re: OpenVPN

Binchen — Tue, 04 Feb 2014 13:40:42 GMT

Ist my-server-2 - 192.168.1.178 ?

OpenVPN

sum — Tue, 04 Feb 2014 12:54:39 GMT

Hallo, ich versuche gerade einen VPN-Server einzurichten. Als Betriebssystem dient WHS2011. Ich habe als server-config:

local 192.168.1.178
mode server
port 1194
proto udp
dev tun

dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
ca C:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt
cert C:\\Programme\\OpenVPN\\easy-rsa\\keys\\WMMTServer.crt
key C:\\Programme\\OpenVPN\\easy-rsa\\keys\\WMMTServer.key

server 10.8.2.0 255.255.255.0
ifconfig-pool-persist C:\\Programme\\OpenVPN\\ipp.txt
client-to-client

push "route 192.168.1.0 255.255.255.0"
push "redirect-gateway"

keepalive 10 120
comp-lzo
persist-key
persist-tun

status C:\\Programme\\OpenVPN\\log\\openvpn-status.log
log C:\\Programme\\OpenVPN\\log\\openvpn.log
log-append C:\\Programme\\OpenVPN\\log\\openvpn.log
verb 3

beim Client:
client
dev tun
proto udp
remote my-server-2 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert cert.crt
key key.key
ns-cert-type server
comp-lzo
verb 3

leider kommt keine Verbindung zu stande, bzw. finde ich keinen gegnerischen pc, router, etc..

vielen dank für tipps