OpenVPN in öffentlichen Netzen

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.

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

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

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

Split Tunneling ?

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?

Jörg B. schrieb:
> Split Tunneling ?

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

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

> wäre interessant wo sein Gateway hinzeigt

stellt man das damit fest?

1

pi@raspberrypi ~ $ route

2

Kernel IP routing table

3

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

4

default         fritz.box       0.0.0.0         UG    0      0        0 eth0

5

10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0

6

10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0

7

192.168.178.0   *               255.255.255.0   U     0      0        0 eth0

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

1

local 192.168.2.0 # SWAP THIS NUMBER WITH YOUR RASPBERRY PI IP ADDRESS

2

dev tun 

3

proto udp #Some people prefer to use tcp. Don't change it if you don't know.

4

port 1194 

5

ca /etc/openvpn/easy-rsa/keys/ca.crt 

6

cert /etc/openvpn/easy-rsa/keys/Server.crt # SWAP WITH YOUR CRT NAME

7

key /etc/openvpn/easy-rsa/keys/Server.key # SWAP WITH YOUR KEY NAME

8

dh /etc/openvpn/easy-rsa/keys/dh1024.pem # If you changed to 2048, change that here!

9

server 10.8.0.0 255.255.255.0 

10

# server and remote endpoints 

11

ifconfig 10.8.0.1 10.8.0.2 

12

# Add route to Client routing table for the OpenVPN Server 

13

push "route 10.8.0.1 255.255.255.255" 

14

# Add route to Client routing table for the OpenVPN Subnet 

15

push "route 10.8.0.0 255.255.255.0" 

16

# your local subnet 

17

push "route 192.168.2.0 255.255.255.0" # SWAP THE IP NUMBER WITH YOUR RASPBERRY PI IP ADDRESS

18

# Set primary domain name server address to the SOHO Router 

19

# If your router does not do DNS, you can use Google DNS 8.8.8.8 

20

push "dhcp-option DNS 192.168.2.1" # This should already match your router address and not need to be changed.

21

# Override the Client default gateway by using 0.0.0.0/1 and 

22

# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of 

23

# overriding but not wiping out the original default gateway. 

24

push "redirect-gateway def1" 

25

client-to-client 

26

duplicate-cn 

27

keepalive 10 120 

28

tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0 

29

cipher AES-128-CBC 

30

comp-lzo 

31

user nobody 

32

group nogroup 

33

persist-key 

34

persist-tun 

35

status /var/log/openvpn-status.log 20 

36

log /var/log/openvpn.log 

37

verb 1

/etc/firewall-openvpn-rules.sh

1

#!/bin/sh 

2

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

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.

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

Wie soll das bitte aus dem ICE funktionieren?

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

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

ip-adresse?

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
"

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