9
OpenVPN mit Web n Walk Handyflat geht seit Mai 2012 nicht mehr ?!?
Hallo,
Ich habe auf meinem Handy die Web n Walk Handyflat für ca 10 Euro im Monat.
Habe bewusst diesen Tarif, obwohl er nicht die beste Bandbreite bietet. Wird aber nicht wie diese unsinnigen und überteuerten 300 MB Tarife auf nahezu unbrauchbare 64 Kbit gedrosselt.
In diesem Tarif ist aber z.B. Mailabruf per Pop3 geblockt. Also musste OpenVPN her, welches mir einen Tunnel auf TCP Port 443 (HTTPS) versteckt.
Das ganze lief bis mitte Mai ohne Probleme, jetzt bekomme ich auf BEIDEN (!) Seiten. Also Handy und Fritzbox immer folgende Fehlermeldung, wenn ich den Tunnel aufbauen möchte.
Sun May 27 10:54:39 2012 us=416133 Connection reset, restarting [-1]
Sun May 27 10:54:39 2012 us=418123 TCP/UDP: Closing socket
Sun May 27 10:54:39 2012 us=418798 SIGUSR1[soft,connection-reset] received, process restarting
Da ich auf beiden Seiten diese Meldung bekomme, kann es sich um keine normale Portsperre handeln. Irgendwas auf der Verbindungsstrecke trennt die Verbindung während der Tunnel ausgehandelt wird.
Wenn ich über ein offenes Wlan oder über meinen Vodafon UMTS Vertrag den Tunnel aufbaue, dann funktioniert es tadellos. Mit der SELBEN Config.
Ich erreiche auch meinen Webserver über meine W&W Handyflat, wenn ich den Server von aussen erreichbar mache.
Wenn ich die ganze OpenVPN Config aber mal auf UDP 443 umstelle, dann baut sich der Tunnel auf. Aber es ist grottenlahm und nahezu unbrauchbar. Das einzigste was relativ gut läuft ist der Ping über den Tunnel. Aber die Antwortzeiten überschreiten meist die 1000 ms. Wenn das ganze über UDP läuft, dann fällt mir folgende Fehlermeldung von der Fritzbox auf:
Sat Jul 14 01:39:03 2012 us=615590 galaxy/80.187.107.120:60978 MULTI: bad source address from client [31.234.109.98], packet dropped
Die 31.234.109.98 ist die IP, die ich von der Telekom bekomme. Diese finde ich auch mit dem Befehl Ifconfig auf meinem Galaxy S3 wieder.
Nur wo kommt die 80.187.107.120 her ?
Jedenfalls sind laut Whois beide IPs von der Telekom.....
Kann es sein, dass das ein Proxy ist ?
Und gibts einen Weg, den irgendwie zu umgehen ? Daran liegt es wohl, dass der Tunnel dermassen schlecht läuft.
Nur wenn es ein Proxy ist, ist es sehr seltsam, dass ich in meiner Fritzbox auch die andere IP sehe. Also die 31.234.109.98, die ich auch auf meinem Handy wieder finde.
Und warum lässt dann der Proxy (falls es einer ist) den Tunnelaufbau über UDP zu und über TCP nicht ?
Hoffe hier kann mir jemand weiterhelfen. Es besteht leider nahezu kein Interesse im Internet an OpenVPN mit der Handyflat.
Lg
Chris
Ich habe auf meinem Handy die Web n Walk Handyflat für ca 10 Euro im Monat.
Habe bewusst diesen Tarif, obwohl er nicht die beste Bandbreite bietet. Wird aber nicht wie diese unsinnigen und überteuerten 300 MB Tarife auf nahezu unbrauchbare 64 Kbit gedrosselt.
In diesem Tarif ist aber z.B. Mailabruf per Pop3 geblockt. Also musste OpenVPN her, welches mir einen Tunnel auf TCP Port 443 (HTTPS) versteckt.
Das ganze lief bis mitte Mai ohne Probleme, jetzt bekomme ich auf BEIDEN (!) Seiten. Also Handy und Fritzbox immer folgende Fehlermeldung, wenn ich den Tunnel aufbauen möchte.
Sun May 27 10:54:39 2012 us=416133 Connection reset, restarting [-1]
Sun May 27 10:54:39 2012 us=418123 TCP/UDP: Closing socket
Sun May 27 10:54:39 2012 us=418798 SIGUSR1[soft,connection-reset] received, process restarting
Da ich auf beiden Seiten diese Meldung bekomme, kann es sich um keine normale Portsperre handeln. Irgendwas auf der Verbindungsstrecke trennt die Verbindung während der Tunnel ausgehandelt wird.
Wenn ich über ein offenes Wlan oder über meinen Vodafon UMTS Vertrag den Tunnel aufbaue, dann funktioniert es tadellos. Mit der SELBEN Config.
Ich erreiche auch meinen Webserver über meine W&W Handyflat, wenn ich den Server von aussen erreichbar mache.
Wenn ich die ganze OpenVPN Config aber mal auf UDP 443 umstelle, dann baut sich der Tunnel auf. Aber es ist grottenlahm und nahezu unbrauchbar. Das einzigste was relativ gut läuft ist der Ping über den Tunnel. Aber die Antwortzeiten überschreiten meist die 1000 ms. Wenn das ganze über UDP läuft, dann fällt mir folgende Fehlermeldung von der Fritzbox auf:
Sat Jul 14 01:39:03 2012 us=615590 galaxy/80.187.107.120:60978 MULTI: bad source address from client [31.234.109.98], packet dropped
Die 31.234.109.98 ist die IP, die ich von der Telekom bekomme. Diese finde ich auch mit dem Befehl Ifconfig auf meinem Galaxy S3 wieder.
Nur wo kommt die 80.187.107.120 her ?
Jedenfalls sind laut Whois beide IPs von der Telekom.....
Kann es sein, dass das ein Proxy ist ?
Und gibts einen Weg, den irgendwie zu umgehen ? Daran liegt es wohl, dass der Tunnel dermassen schlecht läuft.
Nur wenn es ein Proxy ist, ist es sehr seltsam, dass ich in meiner Fritzbox auch die andere IP sehe. Also die 31.234.109.98, die ich auch auf meinem Handy wieder finde.
Und warum lässt dann der Proxy (falls es einer ist) den Tunnelaufbau über UDP zu und über TCP nicht ?
Hoffe hier kann mir jemand weiterhelfen. Es besteht leider nahezu kein Interesse im Internet an OpenVPN mit der Handyflat.
Lg
Chris
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 188331
Url: https://administrator.de/forum/openvpn-mit-web-n-walk-handyflat-geht-seit-mai-2012-nicht-mehr-188331.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
9 Kommentare
Neuester Kommentar
Vermutlich cacht der Provider tatsächlich sämtlichen Web Traffic über einen Zwangsproxy. Klar das dann ein SSH Tunnel nicht zustandekommt.
UDP 443 ist ja logischerweise kein Standard Web Traffic bzw. Web Traffic Port, vermutlich geht das dann am Proxy vorbei. Generell ist es nicht sinnvoll OVPN Traffic über TCP zu senden wegen des erheblich größeren Overheads und damit verbundenen schlechter Performance.
Besser also du legst den OVPN Traffic auf einen der freien IANA ephemeral ports von 49152 bis 65535 mit einer UDP Encapsulation oder benutzt den OVPN Standardport UDP 1194.
Dann sollte das Problem nicht mehr auftreten.
UDP 443 ist ja logischerweise kein Standard Web Traffic bzw. Web Traffic Port, vermutlich geht das dann am Proxy vorbei. Generell ist es nicht sinnvoll OVPN Traffic über TCP zu senden wegen des erheblich größeren Overheads und damit verbundenen schlechter Performance.
Besser also du legst den OVPN Traffic auf einen der freien IANA ephemeral ports von 49152 bis 65535 mit einer UDP Encapsulation oder benutzt den OVPN Standardport UDP 1194.
Dann sollte das Problem nicht mehr auftreten.
Bevor die Probleme auftraten, habe ich das ganze über TCP 443 laufen lassen, damit es wie HTTPS Traffic aussieht.
Dann habe ich es über UDP 443 probiert und der Tunnel baute sich problemlos auf. Nur ist es bei mir genau umgekehrt. Über TCP ist der Tunnel so schnell wie mein Upload. Über UDP ist es nahezu unbrauchbar.
Bei UDP fällt mir auch noch auf, dass ich den Tunnel nicht sauber trennen kann, wenn ich im Handy auf Disconnect gehe.
Die Fritzbox zeigt keinerlei Reaktion auf den Disconnect. Kurz darauf tauchen dann Fehlermeldungen im Fritzbox Log auf.
"Connection Denied" oder so. Weil die Box was an den Client schicken will, der Client aber die Verbindung für sich ja schon beendet hat. Die Box bekommt von dem Disconnect Kommando irgendwie nichts mit.
Über TCP steht im Logfile "Session Closed" oder so. Also ein sauberer Disconnect und es kommen keine weiteren Meldungen mehr.
Es ist auch so, wenn ich über UDP 443 z.B. eine Verbindung aufbaue, dann taucht trotzdem diese 80.187.107.120 im Connect Log der Fritzbox auf. Das ist definitiv nicht die IP, die ich von der Telekom auf das Handy bekomme. Das ist so gut wie immer eine 31.x.x.x, 269.x.x.x, oder eine 10.x.x.x. Die 80.x.x.x sind also entweder Proxyserver, oder es sind Gateways über die die ganzen Mobilen User ins Internet geroutet werden. Ich gehe fast eher von zweiterem aus, weil die IP auf allen Ports auftaucht. Habe schon TCP und UDP 80, 21, 25, 443 probiert.
Heute nach Feierabend werde ich dann mal die 5 Stelligen Ports probieren und den 1194.
Jetzt ist es nur noch seltsam, warum die Performance dermassen schlecht ist.
Ich habe den TUN-MTU auf 1500 und mit mmsfix schon von 1200 - 1400 alles probiert.
Lg
Chris
Dann habe ich es über UDP 443 probiert und der Tunnel baute sich problemlos auf. Nur ist es bei mir genau umgekehrt. Über TCP ist der Tunnel so schnell wie mein Upload. Über UDP ist es nahezu unbrauchbar.
Bei UDP fällt mir auch noch auf, dass ich den Tunnel nicht sauber trennen kann, wenn ich im Handy auf Disconnect gehe.
Die Fritzbox zeigt keinerlei Reaktion auf den Disconnect. Kurz darauf tauchen dann Fehlermeldungen im Fritzbox Log auf.
"Connection Denied" oder so. Weil die Box was an den Client schicken will, der Client aber die Verbindung für sich ja schon beendet hat. Die Box bekommt von dem Disconnect Kommando irgendwie nichts mit.
Über TCP steht im Logfile "Session Closed" oder so. Also ein sauberer Disconnect und es kommen keine weiteren Meldungen mehr.
Es ist auch so, wenn ich über UDP 443 z.B. eine Verbindung aufbaue, dann taucht trotzdem diese 80.187.107.120 im Connect Log der Fritzbox auf. Das ist definitiv nicht die IP, die ich von der Telekom auf das Handy bekomme. Das ist so gut wie immer eine 31.x.x.x, 269.x.x.x, oder eine 10.x.x.x. Die 80.x.x.x sind also entweder Proxyserver, oder es sind Gateways über die die ganzen Mobilen User ins Internet geroutet werden. Ich gehe fast eher von zweiterem aus, weil die IP auf allen Ports auftaucht. Habe schon TCP und UDP 80, 21, 25, 443 probiert.
Heute nach Feierabend werde ich dann mal die 5 Stelligen Ports probieren und den 1194.
Jetzt ist es nur noch seltsam, warum die Performance dermassen schlecht ist.
Ich habe den TUN-MTU auf 1500 und mit mmsfix schon von 1200 - 1400 alles probiert.
Lg
Chris
Diese Fehlermeldung lässt mir keine Ruhe....
Fri Jul 20 19:44:23 2012 us=310472 galaxytab/109.84.62.189:39538 MULTI: bad source address from client [109.84.62.189], packet dropped
Wie und was muss ich jetzt genau machen, um dieses Problem zu lösen ? Bitte keine "Google-Tips"
Das bringt mich nicht wirklich weiter. Weil ich jedem Suchergebnis was anderes steht und man so oft man will da oben FRITZBOX eingibt, dieses verdammte Google alles mögliche ausspuckt, was auf der Fritzbox gar nicht praktikabel ist
Fri Jul 20 19:44:23 2012 us=310472 galaxytab/109.84.62.189:39538 MULTI: bad source address from client [109.84.62.189], packet dropped
Wie und was muss ich jetzt genau machen, um dieses Problem zu lösen ? Bitte keine "Google-Tips"
Das bringt mich nicht wirklich weiter. Weil ich jedem Suchergebnis was anderes steht und man so oft man will da oben FRITZBOX eingibt, dieses verdammte Google alles mögliche ausspuckt, was auf der Fritzbox gar nicht praktikabel ist
Trotz Google Verbot aber hast du das mal versucht:
http://www.void.gr/kargig/blog/2008/05/17/openvpn-multi-bad-source-addr ...
Der Grund des Fehlers wird hier erklärt:
http://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-s ...
Sieht so aus als ob du das "push route..." Kommando in der Servercfg vergessen hast !!
Ein Beispiel für eine sauber funktionierende Konfig findest du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Plattform spielt für die OVPN Konfig keinerlei Rolle !
http://www.void.gr/kargig/blog/2008/05/17/openvpn-multi-bad-source-addr ...
Der Grund des Fehlers wird hier erklärt:
http://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-s ...
Sieht so aus als ob du das "push route..." Kommando in der Servercfg vergessen hast !!
Ein Beispiel für eine sauber funktionierende Konfig findest du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Plattform spielt für die OVPN Konfig keinerlei Rolle !
Meine Config gleich nahezu der Beispielconfig.
Bei meiner Server Config ist nur ein "route 192.168.11.0 255.255.255.0 192.168.11.1" nötig.
Weil sonst der Traffic vom OpenVPN Server direkt zum Zielrechner im LAN geht. Dieser muss seine Antwort über den Router schicken. Der wirft das Packet aber raus, weil die Anfrage nicht über den Router kam, sondern direkt vom OpenVPN Server.
Leider kann ich nicht bei allen Geräten in meinem Netz eine permanente Route setzen. Das ganze war z.B. nötig, um das IPMI Interface meines Servers zu erreichen. Dort kann man keine Permanenten Routen festlegen.
Diese Fehlermeldung kommt bei mir seltsamerweise nur ab und zu. Wenn ich mit dem Handy "wieistmeineip.de" öffne, geht der Speedtest über den Tunnel ohne Probleme. Kann es sein, dass irgendeine App auf dem Handy oder Galaxytab nicht mit der Default Route vom OpenVPN Server klarkommt. Wie schon gesagt, es funktioniert eigentlich alles. RDP, WEB, Email.
Ich rede hier jetzt natürlich nicht über die Web n Walk Handyflat. Damit geht nix. Aber über ein offenes Wlan oder Vodafone geht der Tunnel ja problemlos.
Bei der W n W Handyflat habe ich jetzt auch mal den UDP 1194 und andere Ports probiert. Das selbe Problem. Ich habe die Befürchtung, dass die verdammte Telekom da irgendwo rumschnüffelt und den Traffic unterbindet oder dermassen drosselt, dass es nutzlos ist. Naja, dann kann ich mit dem Handy wirklich nur langweiliges Surfen, ausser ich nutze meine Vodafone Karte im Handy.
Was mir bei UDP auffällt ist eben noch, dass ich den Tunnel nicht sauber trennen kann. Die Box bekommt es nicht mit und bringt kurz nachdem ich am Handy auf Disconnect gegangen bin, folgende Fehlermeldung. Dieses Problem habe ich generell bei UDP. Also per Wlan, Vodafone und W&W
Fri Jul 20 21:59:32 2012 us=875167 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Die Box will noch irgendwas an den Client schicken, obwohl der Tunnel schon beendet ist.
Diese Fehlermeldung ist eigentlich nicht das Problem. Sie kommt wegen der Trennung, die die Box nicht mitbekommt.
EDIT: Habe vergessen, zu schreiben, dass meine Fritzbox nur als OpenVPN Server und Wlan Acesspoint läuft. Die Box hängt hinter meinen Funkwerk R1200. Der ist mein Internet Gateway.
EDIT2: Das mit dem ccd File kann ich auch vergessen. Ich bin ja mal mit dem Handy Netz, und mit verschiedenen Wlans online. Da ändert sich die Adresse des Netzes in dem der Clinet ist ständig. Aber, hinter meinem Client ist eigenlich kein Netz, das es zu erreichen gilt. Eigentlich soll nur die OpenVPN IP des Clients erreichbar sein.
Bei meiner Server Config ist nur ein "route 192.168.11.0 255.255.255.0 192.168.11.1" nötig.
Weil sonst der Traffic vom OpenVPN Server direkt zum Zielrechner im LAN geht. Dieser muss seine Antwort über den Router schicken. Der wirft das Packet aber raus, weil die Anfrage nicht über den Router kam, sondern direkt vom OpenVPN Server.
Leider kann ich nicht bei allen Geräten in meinem Netz eine permanente Route setzen. Das ganze war z.B. nötig, um das IPMI Interface meines Servers zu erreichen. Dort kann man keine Permanenten Routen festlegen.
Diese Fehlermeldung kommt bei mir seltsamerweise nur ab und zu. Wenn ich mit dem Handy "wieistmeineip.de" öffne, geht der Speedtest über den Tunnel ohne Probleme. Kann es sein, dass irgendeine App auf dem Handy oder Galaxytab nicht mit der Default Route vom OpenVPN Server klarkommt. Wie schon gesagt, es funktioniert eigentlich alles. RDP, WEB, Email.
Ich rede hier jetzt natürlich nicht über die Web n Walk Handyflat. Damit geht nix. Aber über ein offenes Wlan oder Vodafone geht der Tunnel ja problemlos.
Bei der W n W Handyflat habe ich jetzt auch mal den UDP 1194 und andere Ports probiert. Das selbe Problem. Ich habe die Befürchtung, dass die verdammte Telekom da irgendwo rumschnüffelt und den Traffic unterbindet oder dermassen drosselt, dass es nutzlos ist. Naja, dann kann ich mit dem Handy wirklich nur langweiliges Surfen, ausser ich nutze meine Vodafone Karte im Handy.
Was mir bei UDP auffällt ist eben noch, dass ich den Tunnel nicht sauber trennen kann. Die Box bekommt es nicht mit und bringt kurz nachdem ich am Handy auf Disconnect gegangen bin, folgende Fehlermeldung. Dieses Problem habe ich generell bei UDP. Also per Wlan, Vodafone und W&W
Fri Jul 20 21:59:32 2012 us=875167 read UDPv4 [ECONNREFUSED]: Connection refused (code=146)
Die Box will noch irgendwas an den Client schicken, obwohl der Tunnel schon beendet ist.
Diese Fehlermeldung ist eigentlich nicht das Problem. Sie kommt wegen der Trennung, die die Box nicht mitbekommt.
EDIT: Habe vergessen, zu schreiben, dass meine Fritzbox nur als OpenVPN Server und Wlan Acesspoint läuft. Die Box hängt hinter meinen Funkwerk R1200. Der ist mein Internet Gateway.
EDIT2: Das mit dem ccd File kann ich auch vergessen. Ich bin ja mal mit dem Handy Netz, und mit verschiedenen Wlans online. Da ändert sich die Adresse des Netzes in dem der Clinet ist ständig. Aber, hinter meinem Client ist eigenlich kein Netz, das es zu erreichen gilt. Eigentlich soll nur die OpenVPN IP des Clients erreichbar sein.
Ein bischen eine sinnfreie Route oben. Die routet das .11er Netz auf eine eigene IP Adresse im 11er Netz.
Mit einer sinnvollen IP Route hat das nix zu tun. Generell wird sowas mit dem Push route Kommando im Server gemacht...aber egal !
Mit einer sinnvollen IP Route hat das nix zu tun. Generell wird sowas mit dem Push route Kommando im Server gemacht...aber egal !
Ich gebe Dir vollkommen recht, dass diese Route etwas unsinnig ist. Es geht aber leider nicht anders und ich habe durch diese Route auch Probleme, die Fritzbox per Telnet zu erreichen.
Vielleicht kannst Du mir sagen, wie ich die Routen setzen muss, damit das mal sauber läuft. Vielleicht verschwindet dann auch der Fehler mit dieser "Bad Source Address". Glaube Du bist hier der einzigste, der sich mit dem ganzen wirklich gut auskennt. Sonst antwortet hier eh keiner *RESPEKT*
Vergessen wir mal den Web n Walk Mist. Das gebe ich auf und werde den Telekomvertrag eh kündigen. Die sind mir zu teuer und Vodafone blockt z.B. nichts. Ich lasse das ganze auch erstmal auf TCP 443, weil die Tunnel Trennung über UDP nicht sauber abläuft.
Ich habe die Fritzbox als reinen OpenVPN Server hinter meinem R1200 der mein Internet Gateway ist.
Mein internes Lan hat die Adresse 192.168.11.0 und das OpenVPN Netz hat die 10.8.0.0 .
Meine server.ovpn sieht derzeit so aus:
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC^M
port 443
proto tcp
dev tun
dev-node /var/tmp/tun
mode server
tls-server
client-to-client
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
tun-mtu 1500
route 192.168.11.0 255.255.255.0 192.168.11.1
push "route 192.168.11.0 255.255.255.0"
push "redirect-gateway"
push "dhcp-option DNS 192.168.11.1"
persist-tun
nice 1
ping 10
ping-restart 60
comp-lzo
verb 4
daemon
Meine Client.ovpn sieht so aus:
client
ca ca.crt
cert client.crt
key client.key
auth SHA1
cipher AES-256-CBC
dev tun
proto udp
tun-mtu 1500
mssfix
nobind
tls-client
ns-cert-type server
pull
remote xxxxxxx.dyndns.org 443
comp-lzo
verb 4
route 192.168.11.0 255.255.255.0 10.8.0.1
persist-tun
persist-key
nice 1
ping 10
ping-restart 60
Am Internet Gateway habe ich diese Route gesetzt, damit der Router weis, wohin der die Antworten schicken muss.
10.8.0.0 255.255.255.0 192.168.11.2
Das Problem bei der ganzen Sache ist, wenn ich bei meinem R1200 Router die Option "Full Filtering" aktiviere. Dann wirft mir der Router die Antworten der Zielsysteme raus, die ich über den Tunnel angefordert habe. Der OpenVPN Server schickt die Anfrage vom Client am anderen Ende des Tunnels, direkt zum Zielsystem. Das Zielsystem sieht die z.B. IP 10.8.0.5 und muss über den Router antworten. Der hat aber niemals was von einer Anfrage gesehen und wirft die Antwort raus.
Wenn ich das Full Filtering abschalte, dann geht es. Aber, das ist ja auch unsauber, wenn man einfach ein Feature abschaltet, damit es funktioniert.
Deswegen habe ich die Route "192.168.11.0 255.255.255.0 192.168.11.1" in die Server.ovpn eingebaut. Jetzt kann ich Full Filtering an lassen, weil der Openvpn Server alle Anfragen über den R1200 schickt und die PCs auch brav über den Router antworten. Alles läuft eigentlich perfekt.
Aber jetzt macht mir das Fullfiltering wieder nen Strich durch die Rechnung, wenn ich die Fritzbox über ihre LAN IP erreichen will. Sei es das Webinterface, oder per Telnet. Ich komme nicht mehr auf die Box. Der Tunnel und das Wlan laufen aber Problemlos.
Das Problem hier ist wieder ähnlich. Ich gebe am PC die IP der Box ein (192.168.11.2). Der PC routet direkt zur Box. Die Box hat aber diese blöde unsaubere Route drin und antwortet über den Router. Der weis wiedermal von nix und wirft die Antwort der Box raus...*hmmmm*
Das ganze könnte ich mir sparen, wenn ich an den Rechnern im LAN einfach überall die Route 10.8.0.0 255.255.255.0 192.168.11.2" setzen würde/könnte. Leider geht das nicht bei allen Systemen in meinem LAN und irgendwie wäre das ja auch wieder unsauber gelöst.
Wäre echt Super, wenn Du mir auf die Sprünge helfen könntest. Kann sein, dass das alles keine riesen Sache ist, nur komme ich einfach nicht auf die richtige Lösung. Das ganze Routen Zeug ist eigentlich nur reine Logik, nur wenn man sich da in irgendwas verrennt, sieht man die Lösung einfach nicht
Ich habe es schon mit push "route 192.168.11.0 255.255.255.0 192.168.11.1" anstatt dem oben in der server.ovpn geschriebenen push "route 192.168.11.0 255.255.255.0" probiert. Aber das funktioniert auch nicht. Ist wohl eh totaler Quatsch und es muss ganz anders gelöst werden
EDIT: Dies nur als "kleine" Info am Rande. Das ist momentan nicht soooo wichtig, weil man da wohl nicht viel machen kann.
Mir ist bei der W&W Handyflat aufgefallen, dass ich, wenn ich bestimmte IPs von der T-Com bekomme, den Tunnel problemlos aufbauen kann und er auch Fullspeed hat. Also ca 360Kbit. Genau das was auch dieser Surftarif bietet. Der ist nicht schneller und reicht mir auch. Seltsam ist nur, dass ich es nur mit bestimmten IPs schaffe. Mit den meisten IPs, die ich zugewiesen bekomme, geht es nicht. Es ist am GalaxyS3 sehr einfach, die IP zu wechseln um irgendwann die richtige zu erwischen. Natürlich nichts auf Dauer, aber erstmal besser als nix. Ich schreibe mal meine IPs hier auf. Vielleicht kann jemand darin irgendeine Logik erkennen. Ich kann das nicht. Ich vermute langsam, dass die T-Com Ende Mai angefangen hat, die Mobil Subnetze zusammenzufassen. Das fällt mir auf, weil ich mit verschiedenen zugewiesenen IPs aus verschiedenen Netzen über das selbe Gateway rauskomme und an der Fritzbox ankomme. An den Gateways liegt es nicht, dass der Tunnel sich nicht aufbaut, es liegt definitiv an den zugewiesenen IPs, weil ich mal das selbe Gateway hatte, mit einer IP die funktionierte und mal eine mit der es nicht funktionierte. Es sind mir auch zwei sehr seltsame Gateway Adressen aufgefallen. Aber es kann natürlich sein, dass die nicht seltsam sind, sondern dass es an der Subnetzbildung der T-Com liegt.
Was auch auffällig ist, ist dass ja eigentlich der Pop3 Abruf über diese W&W Handyflat nicht funktioniert. Aber mit den IPs mit denen der Tunnel geht, geht auch POP3 OHNE Tunnel.
31.240.80.112 - 80.187.106.42 Tunnel geht, Pop3 geht auch ohne Tunnel
31.254.159.117 - 80.187.103.7 Kein Tunnel, kein Pop3
10.152.154.34 - 80.187.102.71 Kein Tunnel, kein Pop3
31.239.129.54 - 80.187.107.167 Tunnel geht, Pop3 geht auch ohne Tunnel
10.160.203.90 - 80.187.103.12 Tunnel geht, Pop3 geht auch ohne Tunnel
Die ersten IPs sind die, die ich von der Tcom zugewiesen bekomme. Diese habe ich mit ifconfig auf dem S3 ermittelt.
Die zweiten IPs 80.x.x.x sind die IPs, die ich im connectlog der Fritzbox sehe. Gehe eher davon aus, dass das Gateways (also so ähnlich wie bei jedem DSL Router zuhause) sind.
80.187.102.81
80.187.107.0 ???
80.187.106.236
80.187.107.92
80.187.102.93
80.187.102.0 ???
80.187.107.43
80.187.103.12
80.187.107.135
Diese IPs sind alles Gateways, da war ich mal zu faul, immer per ifconfig die zugewiesene IP zu ermitteln. Aber man sieht an der 80.187.103.12 dass es nicht an den Gateways liegt, warum sich der Tunnel nicht aufbaut. Die selbe IP taucht auch oben bei den Funktionierenden IPs auf.
Diese zwei Addressen mit den "???" machen mich einwenig stutzig. Dachte immer, dass die "0" eine Netzadresse ist und keine Hostadresse. Aber das kann wie gesagt an der Subnetzbildung liegen, mit der ich mich (noch) nicht wirklich auskenne. Ich arbeite nur mit /24er Netzen
Muss noch dazu sagen, dass der Tunnel wieder über TCP läuft. Über UDP hat er sich mit JEDER Ip aufgebaut und war aber unbrauchbar. Weil sich keine Seite aufgebaut hat und ich pings zu Google und meinem PC von über 1200 ms hatte. Möglicherweise geht es auch über UDP schneller, wenn ich so eine "funktionierende IP" erwische. Aber erstmal interessiert nur TCP
Lg
Chris
Vielleicht kannst Du mir sagen, wie ich die Routen setzen muss, damit das mal sauber läuft. Vielleicht verschwindet dann auch der Fehler mit dieser "Bad Source Address". Glaube Du bist hier der einzigste, der sich mit dem ganzen wirklich gut auskennt. Sonst antwortet hier eh keiner *RESPEKT*
Vergessen wir mal den Web n Walk Mist. Das gebe ich auf und werde den Telekomvertrag eh kündigen. Die sind mir zu teuer und Vodafone blockt z.B. nichts. Ich lasse das ganze auch erstmal auf TCP 443, weil die Tunnel Trennung über UDP nicht sauber abläuft.
Ich habe die Fritzbox als reinen OpenVPN Server hinter meinem R1200 der mein Internet Gateway ist.
Mein internes Lan hat die Adresse 192.168.11.0 und das OpenVPN Netz hat die 10.8.0.0 .
Meine server.ovpn sieht derzeit so aus:
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
auth SHA1
cipher AES-256-CBC^M
port 443
proto tcp
dev tun
dev-node /var/tmp/tun
mode server
tls-server
client-to-client
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
tun-mtu 1500
route 192.168.11.0 255.255.255.0 192.168.11.1
push "route 192.168.11.0 255.255.255.0"
push "redirect-gateway"
push "dhcp-option DNS 192.168.11.1"
persist-tun
nice 1
ping 10
ping-restart 60
comp-lzo
verb 4
daemon
Meine Client.ovpn sieht so aus:
client
ca ca.crt
cert client.crt
key client.key
auth SHA1
cipher AES-256-CBC
dev tun
proto udp
tun-mtu 1500
mssfix
nobind
tls-client
ns-cert-type server
pull
remote xxxxxxx.dyndns.org 443
comp-lzo
verb 4
route 192.168.11.0 255.255.255.0 10.8.0.1
persist-tun
persist-key
nice 1
ping 10
ping-restart 60
Am Internet Gateway habe ich diese Route gesetzt, damit der Router weis, wohin der die Antworten schicken muss.
10.8.0.0 255.255.255.0 192.168.11.2
Das Problem bei der ganzen Sache ist, wenn ich bei meinem R1200 Router die Option "Full Filtering" aktiviere. Dann wirft mir der Router die Antworten der Zielsysteme raus, die ich über den Tunnel angefordert habe. Der OpenVPN Server schickt die Anfrage vom Client am anderen Ende des Tunnels, direkt zum Zielsystem. Das Zielsystem sieht die z.B. IP 10.8.0.5 und muss über den Router antworten. Der hat aber niemals was von einer Anfrage gesehen und wirft die Antwort raus.
Wenn ich das Full Filtering abschalte, dann geht es. Aber, das ist ja auch unsauber, wenn man einfach ein Feature abschaltet, damit es funktioniert.
Deswegen habe ich die Route "192.168.11.0 255.255.255.0 192.168.11.1" in die Server.ovpn eingebaut. Jetzt kann ich Full Filtering an lassen, weil der Openvpn Server alle Anfragen über den R1200 schickt und die PCs auch brav über den Router antworten. Alles läuft eigentlich perfekt.
Aber jetzt macht mir das Fullfiltering wieder nen Strich durch die Rechnung, wenn ich die Fritzbox über ihre LAN IP erreichen will. Sei es das Webinterface, oder per Telnet. Ich komme nicht mehr auf die Box. Der Tunnel und das Wlan laufen aber Problemlos.
Das Problem hier ist wieder ähnlich. Ich gebe am PC die IP der Box ein (192.168.11.2). Der PC routet direkt zur Box. Die Box hat aber diese blöde unsaubere Route drin und antwortet über den Router. Der weis wiedermal von nix und wirft die Antwort der Box raus...*hmmmm*
Das ganze könnte ich mir sparen, wenn ich an den Rechnern im LAN einfach überall die Route 10.8.0.0 255.255.255.0 192.168.11.2" setzen würde/könnte. Leider geht das nicht bei allen Systemen in meinem LAN und irgendwie wäre das ja auch wieder unsauber gelöst.
Wäre echt Super, wenn Du mir auf die Sprünge helfen könntest. Kann sein, dass das alles keine riesen Sache ist, nur komme ich einfach nicht auf die richtige Lösung. Das ganze Routen Zeug ist eigentlich nur reine Logik, nur wenn man sich da in irgendwas verrennt, sieht man die Lösung einfach nicht
Ich habe es schon mit push "route 192.168.11.0 255.255.255.0 192.168.11.1" anstatt dem oben in der server.ovpn geschriebenen push "route 192.168.11.0 255.255.255.0" probiert. Aber das funktioniert auch nicht. Ist wohl eh totaler Quatsch und es muss ganz anders gelöst werden
EDIT: Dies nur als "kleine" Info am Rande. Das ist momentan nicht soooo wichtig, weil man da wohl nicht viel machen kann.
Mir ist bei der W&W Handyflat aufgefallen, dass ich, wenn ich bestimmte IPs von der T-Com bekomme, den Tunnel problemlos aufbauen kann und er auch Fullspeed hat. Also ca 360Kbit. Genau das was auch dieser Surftarif bietet. Der ist nicht schneller und reicht mir auch. Seltsam ist nur, dass ich es nur mit bestimmten IPs schaffe. Mit den meisten IPs, die ich zugewiesen bekomme, geht es nicht. Es ist am GalaxyS3 sehr einfach, die IP zu wechseln um irgendwann die richtige zu erwischen. Natürlich nichts auf Dauer, aber erstmal besser als nix. Ich schreibe mal meine IPs hier auf. Vielleicht kann jemand darin irgendeine Logik erkennen. Ich kann das nicht. Ich vermute langsam, dass die T-Com Ende Mai angefangen hat, die Mobil Subnetze zusammenzufassen. Das fällt mir auf, weil ich mit verschiedenen zugewiesenen IPs aus verschiedenen Netzen über das selbe Gateway rauskomme und an der Fritzbox ankomme. An den Gateways liegt es nicht, dass der Tunnel sich nicht aufbaut, es liegt definitiv an den zugewiesenen IPs, weil ich mal das selbe Gateway hatte, mit einer IP die funktionierte und mal eine mit der es nicht funktionierte. Es sind mir auch zwei sehr seltsame Gateway Adressen aufgefallen. Aber es kann natürlich sein, dass die nicht seltsam sind, sondern dass es an der Subnetzbildung der T-Com liegt.
Was auch auffällig ist, ist dass ja eigentlich der Pop3 Abruf über diese W&W Handyflat nicht funktioniert. Aber mit den IPs mit denen der Tunnel geht, geht auch POP3 OHNE Tunnel.
31.240.80.112 - 80.187.106.42 Tunnel geht, Pop3 geht auch ohne Tunnel
31.254.159.117 - 80.187.103.7 Kein Tunnel, kein Pop3
10.152.154.34 - 80.187.102.71 Kein Tunnel, kein Pop3
31.239.129.54 - 80.187.107.167 Tunnel geht, Pop3 geht auch ohne Tunnel
10.160.203.90 - 80.187.103.12 Tunnel geht, Pop3 geht auch ohne Tunnel
Die ersten IPs sind die, die ich von der Tcom zugewiesen bekomme. Diese habe ich mit ifconfig auf dem S3 ermittelt.
Die zweiten IPs 80.x.x.x sind die IPs, die ich im connectlog der Fritzbox sehe. Gehe eher davon aus, dass das Gateways (also so ähnlich wie bei jedem DSL Router zuhause) sind.
80.187.102.81
80.187.107.0 ???
80.187.106.236
80.187.107.92
80.187.102.93
80.187.102.0 ???
80.187.107.43
80.187.103.12
80.187.107.135
Diese IPs sind alles Gateways, da war ich mal zu faul, immer per ifconfig die zugewiesene IP zu ermitteln. Aber man sieht an der 80.187.103.12 dass es nicht an den Gateways liegt, warum sich der Tunnel nicht aufbaut. Die selbe IP taucht auch oben bei den Funktionierenden IPs auf.
Diese zwei Addressen mit den "???" machen mich einwenig stutzig. Dachte immer, dass die "0" eine Netzadresse ist und keine Hostadresse. Aber das kann wie gesagt an der Subnetzbildung liegen, mit der ich mich (noch) nicht wirklich auskenne. Ich arbeite nur mit /24er Netzen
Muss noch dazu sagen, dass der Tunnel wieder über TCP läuft. Über UDP hat er sich mit JEDER Ip aufgebaut und war aber unbrauchbar. Weil sich keine Seite aufgebaut hat und ich pings zu Google und meinem PC von über 1200 ms hatte. Möglicherweise geht es auch über UDP schneller, wenn ich so eine "funktionierende IP" erwische. Aber erstmal interessiert nur TCP
Lg
Chris
Die beiden statischen Routen "ip route ..." in der server.cfg und in der client.cfg sind unssinnig denn sie machen ja so oder so nix anderes als das 11er Netz in den Tunnel zu routen !!
Es reicht einzig und allein :
push "route 192.168.11.0 255.255.255.0"
in der Server Konfig. Die "ip route..." Routen solltest du dann komplett entfernen bei Server und Client.
Das 10.8.0er Netz ist das OVPN interne Netz auf dem VPN Tunnelinterface, da hast du so oder so immer ne Route hin, denn das ist ja immer lokal.
Wenn du dir dann mit route print bei aktivem VPN Client dir die Routing Tabelle ansiehst, dann siehst du das das Routing für das .11er Netz in den VPN Tunnel und damit den richtigen Weg nimmt.
Da du oben was von "Internet Gateway" schreibst, hast du vermutlich ein Routing Problem bzw. unsinnige Routen konfiguriert.
Wenn der OVPN Server NICHT gleichzeitig das Gateway ist und Clients im OVPN Server Netz also dem 11.0er Netz nicht den OVPN Server als Default Gateway haben, dann ist die obige Route 10.8.0.0 255.255.255.0 192.168.11.2 natürlich Pflicht wenn die .11.2 die lokale LAN IP des OVPN Servers ist !
Klar, denn sonst würden 10.8.0er Pakete ins Internet geroutet werden statt wie richtig an den OVPN Server.
Das OVPN_Tutorial hier zeigt dir eine wasserdicht laufende Konfig die ohne dein ip route... Gefrickel auskommt.
Das generell Problem bei Billigsurf Accounts im Mobilfunk Bereich ist das man dort RFC 1918 IP Adressen bekommt (private IPs) und die Provider dann dort ein zentrales NAT (Adress Translation) machen. Damit hat man dann dort dann generell Probleme mit VPN Protokollen die nicht über NAT Gateways kommen. Siehst du auch selber oben bei dir mit den 80er IPs und den 10er IPs !
Bei SSL Verbindungen wie OpenVPN ist das aber nicht der Fall, da die diese Probleme nicht haben.
Das Märchen von funktionierenden oder nicht funktionierenden IPs hat also nix mit dir und dem OVPN zu tun sondern ist rein Provider gemacht, denn diese drosseln oder filtern bzw. blocken bestimmte Traffic Ströme an solchen APNs weil sie bei billigen Consumer Surf Accounts auch nur Surf Traffic haben wollen und keinerlei VPN Traffic wie es z.B. nur bei den teureren Business Accounts verfügbar ist. Das ist knallharte Provider Politik mit der man dann leben muss !!
Es ist generell kontraproduktiv TCP als Encapsulierung zu benutzen. Deine Probleme die du hast sind MTU oder MSS basierend, da du vermutlich einen MTU Mismatch hast. Klar das dann einige Webseiten nicht richtig laufen. Da musst du in der server.cfg dann die MTU bzw. MSS Settings anpassen, dann kommt es zu solchen Problemen auch nicht.
Das OpenVPN Handbuch dokumentiert das auch sauber !
Das nur TCP funktioniert liegt dann vermutlich an deine nicht sauberen Konfiguration. Der Normalfall ist es wenigstens in der Praxis nicht wenn man alles richtig macht !
Es reicht einzig und allein :
push "route 192.168.11.0 255.255.255.0"
in der Server Konfig. Die "ip route..." Routen solltest du dann komplett entfernen bei Server und Client.
Das 10.8.0er Netz ist das OVPN interne Netz auf dem VPN Tunnelinterface, da hast du so oder so immer ne Route hin, denn das ist ja immer lokal.
Wenn du dir dann mit route print bei aktivem VPN Client dir die Routing Tabelle ansiehst, dann siehst du das das Routing für das .11er Netz in den VPN Tunnel und damit den richtigen Weg nimmt.
Da du oben was von "Internet Gateway" schreibst, hast du vermutlich ein Routing Problem bzw. unsinnige Routen konfiguriert.
Wenn der OVPN Server NICHT gleichzeitig das Gateway ist und Clients im OVPN Server Netz also dem 11.0er Netz nicht den OVPN Server als Default Gateway haben, dann ist die obige Route 10.8.0.0 255.255.255.0 192.168.11.2 natürlich Pflicht wenn die .11.2 die lokale LAN IP des OVPN Servers ist !
Klar, denn sonst würden 10.8.0er Pakete ins Internet geroutet werden statt wie richtig an den OVPN Server.
Das OVPN_Tutorial hier zeigt dir eine wasserdicht laufende Konfig die ohne dein ip route... Gefrickel auskommt.
Das generell Problem bei Billigsurf Accounts im Mobilfunk Bereich ist das man dort RFC 1918 IP Adressen bekommt (private IPs) und die Provider dann dort ein zentrales NAT (Adress Translation) machen. Damit hat man dann dort dann generell Probleme mit VPN Protokollen die nicht über NAT Gateways kommen. Siehst du auch selber oben bei dir mit den 80er IPs und den 10er IPs !
Bei SSL Verbindungen wie OpenVPN ist das aber nicht der Fall, da die diese Probleme nicht haben.
Das Märchen von funktionierenden oder nicht funktionierenden IPs hat also nix mit dir und dem OVPN zu tun sondern ist rein Provider gemacht, denn diese drosseln oder filtern bzw. blocken bestimmte Traffic Ströme an solchen APNs weil sie bei billigen Consumer Surf Accounts auch nur Surf Traffic haben wollen und keinerlei VPN Traffic wie es z.B. nur bei den teureren Business Accounts verfügbar ist. Das ist knallharte Provider Politik mit der man dann leben muss !!
Es ist generell kontraproduktiv TCP als Encapsulierung zu benutzen. Deine Probleme die du hast sind MTU oder MSS basierend, da du vermutlich einen MTU Mismatch hast. Klar das dann einige Webseiten nicht richtig laufen. Da musst du in der server.cfg dann die MTU bzw. MSS Settings anpassen, dann kommt es zu solchen Problemen auch nicht.
Das OpenVPN Handbuch dokumentiert das auch sauber !
Das nur TCP funktioniert liegt dann vermutlich an deine nicht sauberen Konfiguration. Der Normalfall ist es wenigstens in der Praxis nicht wenn man alles richtig macht !
Leider funktioniert ja bei mir die standardmässige Konfig nicht. Weil mein Router diese FULL FILTERING bietet. Ich muss dieses Feature abschalten, damit ich mit der Standard Konfig, also nur push "route 192.168.11.0 255.255.255.0" weiterkomme. Weil mir der Router ja die die Antworten der Zielsysteme rauswirft. Er bekommt von der Anfrage ja nix mit, weil die direkt vom OpenVPN Server zum Zielsystem gehen.
Werde wohl mit der "unsauberen Route" leben müssen, oder das Fullfiltering einfach abschalten.
Das mit den IPs ist nicht wirklich ein Märchen. Ich habe es ja selber erlebt. Das hat natürlich nichts mit mir oder OpenVPN zu tun. Der Provider filtert wohl auf manchen Subnetzen und auf manchen nicht. Warum das so ist, weis wohl keiner. Evtl liegt auch "nur" ein technisches Problem vor, dass es nicht geht. Davon bekommt keiner was mit, weil sich kein Schwein für OpenVPN über die Handyflat interessiert und alle lieber diese unsinnigen überteuerten 300 MB Tarife buchen. Da wird ja viel weniger geblockt und POP3 geht damit auch.
Mein Freund hat auch so einen Schrott Tarif, mit dem kann ich auch den Tunnel Problemlos aufbauen. Aber die IPs die ich über seinen Tarif bekomme, sind ganz andere Subnetze als die, die ich mit der Handyflat bekomme.
Mit TUN-MTU und mmsfix habe ich schon zahllose Kombinationen probiert. Leider kein Erfolg.
Aber, wenn ich mal eine IP bekomme, mit der ich den Tunnel Online bekomme, dann funktioniert es mit TCP und UDP problemlos.
Das hat mit sicherheit nichts mit meiner Konfig zu tun, sondern ist eine Provider Sache. Kann man erstmal nichts machen und ich wechsle eben so lange die IP, bis ich eine bekomme, mit der es funktioniert.
Werde wohl mit der "unsauberen Route" leben müssen, oder das Fullfiltering einfach abschalten.
Das mit den IPs ist nicht wirklich ein Märchen. Ich habe es ja selber erlebt. Das hat natürlich nichts mit mir oder OpenVPN zu tun. Der Provider filtert wohl auf manchen Subnetzen und auf manchen nicht. Warum das so ist, weis wohl keiner. Evtl liegt auch "nur" ein technisches Problem vor, dass es nicht geht. Davon bekommt keiner was mit, weil sich kein Schwein für OpenVPN über die Handyflat interessiert und alle lieber diese unsinnigen überteuerten 300 MB Tarife buchen. Da wird ja viel weniger geblockt und POP3 geht damit auch.
Mein Freund hat auch so einen Schrott Tarif, mit dem kann ich auch den Tunnel Problemlos aufbauen. Aber die IPs die ich über seinen Tarif bekomme, sind ganz andere Subnetze als die, die ich mit der Handyflat bekomme.
Mit TUN-MTU und mmsfix habe ich schon zahllose Kombinationen probiert. Leider kein Erfolg.
Aber, wenn ich mal eine IP bekomme, mit der ich den Tunnel Online bekomme, dann funktioniert es mit TCP und UDP problemlos.
Das hat mit sicherheit nichts mit meiner Konfig zu tun, sondern ist eine Provider Sache. Kann man erstmal nichts machen und ich wechsle eben so lange die IP, bis ich eine bekomme, mit der es funktioniert.
