OpenVPN nur TCP kein UDP

Centro

Centro

Der mit dem roten Hut!
Hallo,

ich verzweifle gerade bei nem kleinen VPN Server Umzug.

Ich habe eine virtuelle OpenVZ Büchse als VPN Server laufen und möchte diese Konfig auf einen V-Server bei 1Blu umziehen.

Habe dort auch wieder openvpn aus den Repos installiert und meine Server.conf und natürlich alle Certs rüber geholt. Wenn ich nun von meinen Clients versuche eine Verbindung dahin auf zu bauen funktioniert das mit UDP garnicht. Hier kommt als Abschließende Zeile nur
Code: 
read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Ich kann mir echt keinen Reim drauf machen.
Wenn ich alles auf TCP umstelle funktionierts soweit, aber halt dementsprechend träge. Ich möchte schon gern wieder udp nutzen da hier auch noch ein Proxy dahinter stehen soll.

Ich habe folgendes versucht:
  • Tun auf Tap geändert
  • MTU von 1492 (mein Wert) auf 1400 1450 1458 1468 usw. angepasst
  • Port zum VPN Server auf 1723 geändert

:D ja auf beiden Seiten gleichzeitig :D

Bedanke mich schon jetzt mal für eure Ideen.
 
TAP mit TCP funktioniert soweit ja. Es geht mir hauptsächlich um TAP mit UDP und das wirft oben genannten Fehler aus.:confused:

/dev/tap erstellt und öffnet sich soweit ich weis erst nach erfolgreicher Anbindung. Es kann natürlich durchaus sein das es hier irgendwie fehlt. - Mal den Provider fragen ob man dazu noch was nachladen muss. modprobe tun und tap wirft mal nix vernünftiges aus.

Aber nur her mit den Ideen, denn die Fehlermeldung schießt wahrscheinlich auf nen ganz anderen Fehler als udpv4
 
Last edited by a moderator:
Update hierzu noch: :(

tap0 scheint up zu sein. - Ich kann mich auch selbst auf der Maschine pingen, jedoch von Aussen nicht.

Code: 
tap0      Link encap:Ethernet  Hardware Adresse 9E:80:BD:77:31:3C
          inet Adresse:10.10.10.1  Bcast:10.10.10.255  Maske:255.255.255.0
          inet6 Adresse: fe80::9c80:bdff:fe77:313c/64 Gültigkeitsbereich:Verbindung
 
ich würde es noch mit
fragment 1400
versuchen.
das ist meiner Meinung nach eher ein Fehler, der durch die Paketgröße verursacht wird.
Logs wären wie immer hilfreich
 
Last edited by a moderator:
Code: 
Mon Jan 21 23:48:47 2013 MULTI: multi_create_instance called
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Re-using SSL/TLS context
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 LZO compression initialized
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Control Channel MTU parms [ L:1478 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Data Channel MTU parms [ L:1478 D:1300 EF:46 EB:135 ET:32 EL:0 AF:3/1 ]
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Fragmentation MTU parms [ L:1478 D:1300 EF:45 EB:135 ET:33 EL:0 AF:3/1 ]
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Local Options hash (VER=V4): '4b752ca2'
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 Expected Remote Options hash (VER=V4): 'd68365bf'
Mon Jan 21 23:48:47 2013 87.168.64.248:1948 TLS: Initial packet from 87.168.64.248:1948, sid=f91ca422 0a40da1d
Mon Jan 21 23:48:47 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Mon Jan 21 23:48:49 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Mon Jan 21 23:48:53 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
Mon Jan 21 23:49:01 2013 read UDPv4 [EHOSTUNREACH]: No route to host (code=113)

... mehr logs gibts da aktuell ned, läuft eh schon auf Debugging.

Aber um zurück zu kommen, auch mit fragment 1300 und mtg 1400 gibt es nur obige Ausgabe. Das Client interface kommt auch garnicht erst hoch.

Ich werde die Tage die Certs nochmal komplett neu generieren, nur um diese TLS Geschichte noch absolut aus zu schließen.
 
"no route to host" ist doch relativ eindeutig? Wie man da auf tun/tap oder Certs kommt, dürft Ihr mir später mal erläutern...

Code: 
netstat -rn
cat /etc/resolv.conf
cat /etc/hosts
iptables -n -L -v
 
"no route to host" ist doch relativ eindeutig?
Click to expand...

in dem Fall leider nicht. Es ist eine OpenVPN Fehlermeldung, welche bei mehreren Fehler angezeigt wird. Manchaml hilft es die MTU korrekt zu setzen, manchmal ist es auch die route, manchmal muss ein Fragment her...usw.

Route scheidet ohnehin aus, sonst würde es per TCP ja nicht problemlos gehen.

poste mal die openvpn config vom client und server.
welche network settings hast du auf dem system gesetzt?
iptables aktiv?
selinux aktiv?
 
Hallo,

vielen Dank erstmal für eure rege beteiligung. Vorab nochmal. Gleiches System läuft mit gleicher Konfig exact so auf einem anderen host ohne Fehler. :cool:

server.conf
Code: 
# Port
port 1194

# TCP oder UDP?
#proto tcp-server
proto udp
mode server
tls-server

# tun oder tap?
# Das tun Device erstellt einen IP Tunnel,
# während das tap Device einen Ethernet Tunnel erstellt.
#tun or tap device
#tun is an IP tunnel,
#tap an ethernet tunnel
dev tap

#Our Server IP
ifconfig 10.10.10.1 255.255.255.0

#dynamic clients from 10.10.10.2-10.10.10.254
ifconfig-pool 10.10.10.2 10.10.10.254

#Die pakete werden auf dieser gröÃe gekapselt
tun-mtu 1492
#fragment 1300
mssfix

#Paths to the certs
#ca /etc/openvpn/certs/vpn-ca.pem
#cert /etc/openvpn/certs/servercert.pem
#key /etc/openvpn/certs/serverkey.pem

#Pfade zu den Zertifikaten
ca /etc/openvpn/easy-rsa/ca.crt
cert /etc/openvpn/easy-rsa/server.crt
key /etc/openvpn/easy-rsa/server.key

#Clients können miteinander kommunizieren
#client-to-client

#Diffie-Hellmann Parameters
#dh /etc/openvpn/certs/dh1024.pem

#Diffie-Hellmann Parameters
dh /etc/openvpn/easy-rsa/dh1024.pem

#Same Ip in the next session
ifconfig-pool-persist ipp.txt

#Routes the packages to the intern network, you should use iptables instead of this
#push "route 192.168.0.0 255.255.255.0"

#Tests the connection with a ping like paket. (wait=120sec)
keepalive 10 120

#Authenication
auth SHA1

#Our encryption algorithm
#cipher aes-256-ecb
#openvpn --show-ciphers for testing

#comp
comp-lzo

#Sets new rights after the connection
user nobody
#group nogroup

#We need this because of user nobody/group nobody.
persist-key
persist-tun

#Logging 0, (testing:5)
verb 3

Client CONF

Code: 
client
float
dev tap

#MTU
tun-mtu 1492
#fragment 1300
mssfix
script-security 2

#device name, unter linux nicht mehr auskommentieren (# löschen)
#dev-node vsn-device

#tcp oder udp
proto udp

#Server IP
remote MEINE-DNS 1194

#force authentication
#WICHTIG: hier den COMMON Name vom Server Zertifikat nehmen!
tls-remote server

ca ca.crt
cert otto-buero.crt
key otto-buero.key

auth SHA1
#cipher aes-256-cbc
nobind
comp-lzo
persist-key
persist-tun
verb 0

# Nach dem Verbindungsaufbau wird eine Route zum lokalen Netz vom Server aus aufgebaut
# AUSKOMMENTIERT
# Beispiel: Subnetz 192.168.2.0/24
#route 192.168.178.0 255.255.255.0

# Default route ueber VPN
# AUSKOMMENTIERT
#route remote_host 255.255.255.255 net_gateway
#route 0.0.0.0 0.0.0.0 vpn_gateway


SELinux ist off und auch sonst ist von Parallels die FW aus.

Wie geschrieben gehts mit TCP und TAP, nur massiv träge versteht sich.

Wie ich auf die Certs komme? - Beim Beenden des Serverdienstes von OVPN wenn ich es manuell im Debug gestartet hatte kommt eine Fehlermeldung das TLS Handshake nicht funktioniert hatte. Joa, klar, wenn ich den Server abschiesse gehts nimma. Aber muss ned an den Certs liegen. Wenn man schon Tage dran rumschraubt wird man irgendwann so wahnsinnig das man auf alles tippt :D
 
Da Parallels ja nun nicht alleinig deine FW bedient, poste doch mal die Ausgaben von
Code: 
iptables -L -n -v; iptables -L -n -v -t nat; ifconfig -a
 
Sorry für die späte Rückmeldung.

Hier die Ausgaben. tap0 ist lokal Pingbar. Nur sobald sich clients connecten "No route to host ...blablablbalabl"

Code: 
Chain INPUT (policy ACCEPT 79 packets, 5726 bytes)
 pkts bytes target     prot opt in     out     source               destination
  572 40840 VZ_INPUT   all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 VZ_FORWARD  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 60 packets, 4956 bytes)
 pkts bytes target     prot opt in     out     source               destination
  694  135K VZ_OUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain VZ_FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain VZ_INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
  251 18492 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:110
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:32768:65535
    2   205 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:32768:65535
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8880
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8443
    0     0 ACCEPT     tcp  --  *      *       127.0.0.1            127.0.0.1
    0     0 ACCEPT     udp  --  *      *       127.0.0.1            127.0.0.1

Chain VZ_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:80
  200 79127 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:22
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:25
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:110
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:53
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
   12   670 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:8880
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:8443
    0     0 ACCEPT     tcp  --  *      *       127.0.0.1            127.0.0.1
    0     0 ACCEPT     udp  --  *      *       127.0.0.1            127.0.0.1

Code: 
Chain PREROUTING (policy ACCEPT 8 packets, 364 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 3 packets, 200 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 3 packets, 200 bytes)
 pkts bytes target     prot opt in     out     source               destination

Code: 
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:54 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4536 (4.5 KB)  TX bytes:4536 (4.5 KB)

tap0      Link encap:Ethernet  HWaddr 72:5f:8f:2b:12:75
          inet addr:10.10.10.1  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::705f:8fff:fe2b:1275/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1492  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:398 (398.0 B)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          inet6 addr: ::2/128 Scope:Compat
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:706 errors:0 dropped:0 overruns:0 frame:0
          TX packets:672 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:49486 (49.4 KB)  TX bytes:139956 (139.9 KB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:178.254.EXT.IP2  P-t-P:178.254.EXT.IP2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:178.254.EXT.IP1  P-t-P:178.254.EXT.IP1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
 
Last edited by a moderator:
[SOLVED]

Es ist ein Bug in OVPN2.2 der das Ganze hier vorgaukelt. Man muss einen Symlink für openssl unter /etc/openssl/easyrsa/ legen dann läufts grundsätzlich mal.
Dann hab ich noch unter Centos vergessen das ich unter sysctl das ipv4 forwarding nicht auf 1 hatte.

Nun tuts.
Danke an alle die sich hier mit den Kopf zerbrochen haben.

Achja und Firewall wars mal überhaupt ned. ;)
 
Schön, dass du es gelöst hast. Eine Anmerkung:
Wenn ipv4 forwarding nicht aktiv war, dann hat es mit der config und tcp Einstellung (anstatt udp) auch nicht funktioniert. Alles andere ist schlicht unmöglich.
 
BruceLee said:
Eine Anmerkung:
Wenn ipv4 forwarding nicht aktiv war, dann hat es mit der config und tcp Einstellung (anstatt udp) auch nicht funktioniert. Alles andere ist schlicht unmöglich.
Click to expand...

Leider ist es doch möglich gewesen. - zwar hier nur zum Ping auf den VPN Server (interne IP) aber immerhin. - Zum Proxy kam ich da auch nicht, das ist korrekt.


Greetz Centro
 
You must log in or register to reply here.
Back
Top