OpenVPN in öffentlichen Netzen

[C# Beginner (Gast)]

Hallo,
ich habe im ICE (wifi-on-ICE) einen openvpn Tunnel benutzt und wollte 
surfen.
Ergebnis, ping geht, browsen nicht.

Ein Versuch mit wget:

[u@1005P ~]$ wget www.gmx.de
--2017-04-24 01:05:27--  http://www.gmx.de/
Resolving www.gmx.de (www.gmx.de)... 82.165.230.36
Connecting to www.gmx.de (www.gmx.de)|82.165.230.36|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.gmx.net/ [following]
--2017-04-24 01:05:40--  https://www.gmx.net/
Resolving www.gmx.net (www.gmx.net)... 82.165.230.18
Connecting to www.gmx.net (www.gmx.net)|82.165.230.18|:443... connected.
Unable to establish SSL connection.

Dann habe ich mich an dem Hotspot meines Smartphones gehängt, und wieder 
den VPN-Tunnel geöffnet.

Es ging:

[u@1005P ~]$ wget www.gmx.de
--2017-04-24 01:08:55--  http://www.gmx.de/
Resolving www.gmx.de (www.gmx.de)... 82.165.x.x
Connecting to www.gmx.de (www.gmx.de)|82.165.x.x|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.gmx.net/ [following]
--2017-04-24 01:08:56--  https://www.gmx.net/
Resolving www.gmx.net (www.gmx.net)... 82.165.x.x
Connecting to www.gmx.net (www.gmx.net)|82.165.x.x|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’

index.html              [     <=>            ] 197.79K  99.0KB/s    in 2.0s    

2017-04-24 01:08:59 (99.0 KB/s) - ‘index.html’ saved [202540]

Frage: Verhindern öffentliche Netze die Benutzung von VPN?

[Peter II (Gast)]

C# Beginner schrieb:
> Ergebnis, ping geht, browsen nicht.

C# Beginner schrieb:
> Frage: Verhindern öffentliche Netze die Benutzung von VPN?

entweder steht der Tunnel oder nicht, mehr sieht das öffentliche Netzt 
nicht. Dieser Effekt ist nicht zu erklären.

Eventuell geht Browser oder Ping nicht durch den Tunnel.

[Thorsten (Gast)]

Das hört sich stark nach (P)MTU Problemen bzw. geblockten ICMP 
fragmentation Paketen an.

[Hans (Gast)]

WifiOnIce funktioniert sowieso erst richtig, wenn man einen Deauth 
Angriff startet

[C# Beginner (Gast)]

Hier ist jemand mit ähnlichem Problem:

https://forums.openvpn.net/viewtopic.php?t=22602

Ihm wurde diese Lösung empfohlen

https://openvpn.net/index.php/open-source/documentation/howto.html#redirect

[Der kein Bock mehr A. (Gast)]

Split Tunneling ?

[C# Beginner (Gast)]

Ich habe die Standard-Einstellungen benutzt, d.h. UDP port 1194.
Manche schreiben, dass man auch TCP nehmen kann und andere ports.

Vllt hilft das schon weiter?

[Stephan (Gast)]

Jörg B. schrieb:
> Split Tunneling ?

ja auf sowas würde ich auch tippen....

[Stephan (Gast)]

wäre interessant wo sein Gateway hinzeigt oder Route 0.
Wenn Sein VPN nicht weiter routet ist eben nach der DNS Anfage Schluss.
GMX liegt ja außerhalb seines VPN

[C# Beginner (Gast)]

> wäre interessant wo sein Gateway hinzeigt

stellt man das damit fest?

pi@raspberrypi ~ $ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fritz.box       0.0.0.0         UG    0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0
192.168.178.0   *               255.255.255.0   U     0      0        0 eth0

[C# Beginner (Gast)]

Ansonsten sind alle Setups nach der Anleitung gemacht:

http://readwrite.com/2014/04/10/raspberry-pi-vpn-tutorial-server-secure-web-browsing/
also z.B.

/etc/openvpn/server.conf

local 192.168.2.0 # SWAP THIS NUMBER WITH YOUR RASPBERRY PI IP ADDRESS
dev tun 
proto udp #Some people prefer to use tcp. Don't change it if you don't know.
port 1194 
ca /etc/openvpn/easy-rsa/keys/ca.crt 
cert /etc/openvpn/easy-rsa/keys/Server.crt # SWAP WITH YOUR CRT NAME
key /etc/openvpn/easy-rsa/keys/Server.key # SWAP WITH YOUR KEY NAME
dh /etc/openvpn/easy-rsa/keys/dh1024.pem # If you changed to 2048, change that here!
server 10.8.0.0 255.255.255.0 
# server and remote endpoints 
ifconfig 10.8.0.1 10.8.0.2 
# Add route to Client routing table for the OpenVPN Server 
push "route 10.8.0.1 255.255.255.255" 
# Add route to Client routing table for the OpenVPN Subnet 
push "route 10.8.0.0 255.255.255.0" 
# your local subnet 
push "route 192.168.2.0 255.255.255.0" # SWAP THE IP NUMBER WITH YOUR RASPBERRY PI IP ADDRESS
# Set primary domain name server address to the SOHO Router 
# If your router does not do DNS, you can use Google DNS 8.8.8.8 
push "dhcp-option DNS 192.168.2.1" # This should already match your router address and not need to be changed.
# Override the Client default gateway by using 0.0.0.0/1 and 
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of 
# overriding but not wiping out the original default gateway. 
push "redirect-gateway def1" 
client-to-client 
duplicate-cn 
keepalive 10 120 
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 
cipher AES-128-CBC 
comp-lzo 
user nobody 
group nogroup 
persist-key 
persist-tun 
status /var/log/openvpn-status.log 20 
log /var/log/openvpn.log 
verb 1

/etc/firewall-openvpn-rules.sh

#!/bin/sh 
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 192.168.XX.X

[Nö (Gast)]

Wird kein Routing-Problem sein, wenn ping auf das gleiche Ziel 
funktioniert.

Dem wget-Log zufolge wird eine Verbindung (TCP) zum Ziel aufgebaut, nur 
eine SSL-Verbindung scheitert:

"Connecting to www.gmx.net (www.gmx.net)|82.165.230.18|:443... 
connected.
Unable to establish SSL connection."

Das bedeutet m. E., dass der VPN-Tunnel - wenn kein split tunnel 
verwendet wird - aufgebaut ist, anderenfalls würde das TCP handshake zum 
Ziel schon scheitern.

[Klaus Patenstedt (Gast)]

...
local 192.168.2.0
...
server 10.8.0.0 255.255.255.0
...

Wie soll das bitte aus dem ICE funktionieren?

[C# Beginner (Gast)]

Es funktionert ja auch mit dem mobilen (Android-Smartphone) Hotspot (aus 
dem ICE). (Tethering)

Wo unterscheiden sich wifionice-Hotspot und Android-Smartphone-Hotspot?

[fpga (Gast)]

ip-adresse?

[kaeseschnitzel (Gast)]

Bekanntes Problem. An einer Lösung wird in den nächsten Releases 
gearbeitet.

Quote aus dem Bahn-Forum:

"
Hallo zusammen,
wir möchten euch ein Update zum aktuellen Stand geben:
Der Fachbereich hat eine Lösung erfolgreich getestet und will diese mit 
dem nächsten Patch ausspielen. Die Paketgröße für VPN wird dann auf 1440 
Byte erhöht, das ist das maximal mögliche.
Es wurde mit mi Open VPN getestet (OpenVPN hat leider nur einen feste 
Paketgröße). Damit konnte der Großteil der VPN-Probleme gelöst werden. 
Weiterhin kann es aber sein, dass bei VPNs die Paketgröße größer als 
1440 Byte eingestellt ist. Da hilft dann nur die manuelle Anpassung 
(ggf. durch den System-Admin) oder es könnten von manchen VPNs selten 
genutzte Ports genutzt werden.
Hier bitten wir Sie - unsere Fahrgäste - wenn Sie uns in diesen Fällen 
mitteilen können, welchen VPN-Client, welche Ports, Paketgröße etc. Sie 
nutzen.

Hintergrund zur Paketgröße: Mobilfunk lässt aktuell maximal 
1500-Byte-Pakete durch. Da noch ein kleiner Puffer für die gesicherte 
Verbindung Zug-Land vorgehalten werden muss, bleiben für Sie 1440 Byte. 
/ti
"

[kaeseschnitzel (Gast)]

Auch wird ein Wechsel auf TCP empfohlen, da  Wifi-Kisten im Zug 
verschiedene Netzanbieter nutzen. Das gibt ganz schräge Effekte mit UDP.