OpenVPN hält Route nicht

[counterroot]

Hallo

Folgendes Szenario:
Client X verbunden über WLAN oder LAN

OpenVPN verbindet sich über WLAN oder LAN zu einem zentralen Server. Über diesen soll sämtlicher internet-Verkehr laufen.

Die ersten paar Minuten hält die Verbindung und alles geht bei einem Tracert zunächst über die Server-Destination.
Dann jedoch steht die OpenVPN verbindung weiterhin und mein Datenverkehr geht direkt...

Jemand schonmal sowas gehabt --> Was mache ich falsch? kann ich da einen Kontrollmechanismus einbauen? Ich merke im moment nicht, wenn die Verbindung switched...
pmb µatthias

Eingesetzt:
- Windows 7
- Tritt bei mehreren Verbindungen auf. WLAN (verschiedene Router), LAN (Verschiedene switche)
- OpenVPN v.1.0.3

 

[Ex0r]

Os ?

 

[Dystop1an]

Die ersten paar Minuten hält die Verbindung und alles geht bei einem Tracert zunächst über die Server-Destination.
Dann jedoch steht die OpenVPN verbindung weiterhin und mein Datenverkehr geht direkt...

den satz versteh ich nicht ganz, also du hast ne verbindung die von einem client direkt zu einem anderen geht, bzw. client zu server (ist aber letztendlich beides end-to-end) und das der anch ein paar minuten anstatt über den server, direkt über das dort ansässige netzwerk geht?

BTW: Wie ist das den auf beiden seiten aufgebaut? Ungefähr so:
Deine PC=>Switch/Router=>VPN<=Switch/Router<=Server?

 

[Solipsists]

Hast du schonmal was von "logfiles" gehört?!?
Check diese sogenannten Logfiles mal auf Client + Server...
Falls dir was spanisch vorkommt oder du etwas in den Logfiles nicht verstehst...
Dann darfst du das gerne hier posten...

 

[/root]

openvpn gui als admin gestartet? damit er auch die routen korrekt setzen kann.
ein reconnect kann einem auch die route table versauen

edit: poste mal deine server config und dein client.conf file

 

[counterroot]

yay. Dachte man kommt auch ohne Logs mal aus xD aber ihr habt natürlich recht. --> is wohl die englische luft....
Naja eigentlich bin ich deshalb ohne Logs gekommen, weil es nach client-problem aussah... und ich eher ein Routenproblem vermutete....

@/etc/openvpn/openvpn.log
Sun Jun 20 18:29:32 2010 certsign.domain.tld/217.41.226.51:49241 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)

das kommt hauptsächlich bevor die verbindung gekappt wird.
hier schreiben sie, dass das von Broadcasts kommt... http://openvpn.net/archive/openvpn-users/2005-07/msg00247.html

mit kappen ist gemeint:

client X verbindet sich zu server Y
Daten gehen von client X über server Y an Server Z

ist einfach dafür gedacht, dass Datenverkehr in öffentlichen WLANs nicht abgehört werden kann (zumindest incht ohne Probleme)

Die ersten paar Minuten hält das ohne Probleme. Alle daten gehn über diese "Verbindung":

Tracing route to google.de [216.239.59.104]
over a maximum of 30 hops:

1 132 ms 147 ms 130 ms 172.16.0.9
2 144 ms 151 ms 127 ms 62.2.56.2

Aber danach:
Tracing route to google.de [216.239.59.104]
over a maximum of 30 hops:

1 2 ms 1 ms 1 ms 10.14.120.1
2 * * * Request timed out.

grüße µatthias
P.S.: Danke schonmal für die Antworten

btw: Configs:

client
dev tun
proto tcp
remote domain.tld 443
resolv-retry infinite
nobind
persist-key
persist-tun

ca cacert.pem
cert certsign_domain_tld_cert.pem
key certsign_domain_tld_key.pem

cipher AES-256-CBC
comp-lzo
verb 3
ping 10

# Server conf
port 443
proto tcp
dev tun

tun-mtu 1500
mssfix

ca certs/cacert.pem
cert certs/domain_tld_cert.pem
key certs/domain_tld_key.pem
dh certs/dh4096.pem

server 172.16.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
max-clients 40

push "redirect-gateway"
push "dhcp-option DNS 91.214.168.168"
push "dhcp-option DNS 91.214.169.169"

client-to-client

keepalive 10 120
auth SHA1
cipher AES-256-CBC
comp-lzo
persist-key
persist-tun
verb 3

status openvpn-status.log
log openvpn.log

 

[/root]

ich habe die gleiche konfiguration wie du, nur ein paar kleinigkeiten sind anders.

folgende optionen habe ich NICHT:

cipher AES-256-CBC
comp-lzo
ping 10

du könntest mal versuchen die aus der client- und server.conf zu entfernen, da sie anscheinend nicht unbedingt nötig sind.
den iptables POSTROUTING befehl hast du vermutlich abgesetzt oder?

ABER: wenn ich in der FH im wlan bin, bricht bei mir auch regelmässig die verbindung zusammen, wenn das Wlan nicht stabil ist, hat man schnell probleme mit dem VPN Tunnel. im FH wlan hält mein tunnel keine 10 minuten, wenn das wlan allerdings stabil ist hält er stundenlang ohne probleme

 

[counterroot]

ich habe die gleiche konfiguration wie du, nur ein paar kleinigkeiten sind anders.

folgende optionen habe ich NICHT:

cipher AES-256-CBC
comp-lzo
ping 10

du könntest mal versuchen die aus der client- und server.conf zu entfernen, da sie anscheinend nicht unbedingt nötig sind.
den iptables POSTROUTING befehl hast du vermutlich abgesetzt oder?

ABER: wenn ich in der FH im wlan bin, bricht bei mir auch regelmässig die verbindung zusammen, wenn das Wlan nicht stabil ist, hat man schnell probleme mit dem VPN Tunnel. im FH wlan hält mein tunnel keine 10 minuten, wenn das wlan allerdings stabil ist hält er stundenlang ohne probleme

Mh.... der cipher definiert meine Verschlüsselungsmethode. den nehme ich nicht raus.
comp-lzo definiert komprimierung --> teste ich mal
und ping 10 ist ein kontrollmechanismus für die Verbindung. --> i'll try

Dass die Tunnel anfällig auf instabile Verbindungen sind musste ich leider auch schon feststellen.... welche tun-mtu habt ihr? (und welche zugehörige MTU auf der Karte (ifconfig)?)

pmb µatthias

P.S.: Ja, iptables funktioniert soweit.

 

[Solipsists]

http://www.webhostingtalk.com/showthread.php?t=650649

Hier hast du ein paar lösungsvorschläge (--> UDP, ist eh viel stabiler als TCP Tunnel über TCP)
Es gibt massenhaft Google-Antworten, arbeite dich da am besten erstmal durch
Leider sind die Tunnel bei OpenVPN fehleranfällig, besonders beim bridging!

Cheers

 

[counterroot]

mhhhh... Blöd, dass oft UDP geblockt wird. genau aus dem grund, dass TCP 443 auf den meisten Proxies erlaubt wird nutze ich es.
Bitte korrigiert mich wenn ich falsch liege...
Gibt es denn eine echte und gute Alternative zu den OpenVPN Tunnels?

grüße µatthias

 

[Solipsists]

Wozu nutzt du den Tunnel denn?
Ich hatte auf meinem Linksys WRT54GL einen OpenVPN Server auf Port 443 (UDP) laufen
War TOP mit UDP... hatte selten/nie Probleme zu connecten, und lief auch stabil!

Alternative, naja... kommt immer drauf an was du machen willst über den Tunnel, Wenns nur sicher surfen ist, dann kannst du das auch mit Squid regeln :-)

Cheers

 

[counterroot]

Naja. Aber über sqiud kriege ich nicht sämtlichen Datenverkehr z.B. von Pidgin/etc transferriert.
aber schonmal super
Danke für'n tip Das mit UDP scheint gut zu gehn.
grüße µatthias

 

[Solipsists]

Aber über sqiud kriege ich nicht sämtlichen Datenverkehr z.B. von Pidgin/etc transferriert.

Pidgin sollte kein Problem sein hinter einem Squid Proxy :-)

 

[counterroot]

möp. stimmt. gibt ja proxy-func... hrmpf okay
µatthias