OpenVPN unter FreeBSD 10

Sickboy · 7 Juni 2016

Hallo,

unter FreeBSD 10 habe ich einen OpenVPN-Server aufgesetzt, die entsprechenden Zertifikate erstellt und den Client konfiguriert. Leider klappt es nicht mit dem Verbindungsaufbau. Die Clients sollen per TUN eingebunden werden. In der openvpn.log heißt es:

Code:

RTue Jun  7 21:13:25 2016 us=94242 A.B.C.D:61454 TLS: Initial packet from [AF_INET]A.B.C.D:61454, sid=88644059 f3f55e3b
WRRWRWWWRRWWTue Jun  7 21:13:26 2016 us=191840 A.B.C.D:37951 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jun  7 21:13:26 2016 us=192008 A.B.C.D:37951 TLS Error: TLS handshake failed
Tue Jun  7 21:13:26 2016 us=192196 A.B.C.D:37951 SIGUSR1[soft,tls-error] received, client-instance restarting
WqWWTue Jun  7 21:13:27 2016 us=237447 MULTI: multi_create_instance called
Tue Jun  7 21:13:27 2016 us=237647 A.B.C.D:51240 Re-using SSL/TLS context
Tue Jun  7 21:13:27 2016 us=237743 A.B.C.D:51240 LZO compression initialized
Tue Jun  7 21:13:27 2016 us=238052 A.B.C.D:51240 Control Channel MTU parms [ L:1542 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Tue Jun  7 21:13:27 2016 us=238188 A.B.C.D:51240 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:143 ET:0 EL:3 AF:3/1 ]
Tue Jun  7 21:13:27 2016 us=238338 A.B.C.D:51240 Local Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Tue Jun  7 21:13:27 2016 us=238438 A.B.C.D:51240 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Tue Jun  7 21:13:27 2016 us=238581 A.B.C.D:51240 Local Options hash (VER=V4): '530fdded'
Tue Jun  7 21:13:27 2016 us=238952 A.B.C.D:51240 Expected Remote Options hash (VER=V4): '41690919'

(A.B.C.D ist die IP des Clients.)

Der Client hat sowohl das CA des Servers als auch die Client-Zertifikate als PKCS#12. Hat jemand von euch einen Hinweis?

Edit: /etc/rc.conf:

Code:

gateway_enable="YES"

openvpn_enable="YES"
openvpn_configfile="/usr/local/etc/openvpn/server.conf"
openvpn_if="tun"

server.conf (Auszug):

Code:

local E.F.G.H # Public IP des VPS
proto udp
dev tun

ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/issued/rmk-openvpn-server.crt
key /usr/local/etc/openvpn/keys/private/rmk-openvpn-server.key
dh /usr/local/etc/openvpn/keys/dh.pem

server 10.8.0.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"

keepalive 10 120
cipher BF-CBC
comp-lzo
max-clients 50

user nobody
group nobody

persist-key
persist-tun

ifconfig:

Code:

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::acd0:f18f:58d4:2c86%tun0 prefixlen 64 scopeid 0x3 
        inet 10.8.0.1 --> 10.8.0.2 netmask 0xffffffff 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 76225

peterle · 7 Juni 2016

Ja läuft denn der Server überhaupt und wie sieht die config des Clients aus?

Columbo0815 · 8 Juni 2016

Moin,
ich würde folgende Anpassungen vornehmen (teilweise auf den Fehler bezogen, teilweise Offtopic):
- Nimm tun0 anstatt tun (könnte schon der Grund sein)
- Kopiere alle erforderlichen Keys nach /usr/local/etc/openvpn. Damit kannst du den Pfad in der Config weglassen (das ist aber nur schöner zu lesen, imho).
- Verwende noch tls-auth ta.key 0 (Beim Server. Beim Client "tls-auth ta.key 1")
- erhöhe temporär das Loglevel: "verb 9". Damit wird mehr protokolliert, was bei der Fehlersuche helfen kann.
- Vielleicht willst du dein Netzwerk beim Server einen anderen IP-Adressenbereich verpassen. Was wenn der Client auch ein 192.168.0-Netz hat? Das ist doch sehr gängig...

Hast du die Keys mit easyrsa erstellt? Hast du die danach auch mit "easyrsa sign client foobar" unterzeichnet (vermutlich schon, sonst hättest du den Client-Key nicht).

peterle · 8 Juni 2016

Columbo0815 schrieb:
Hast du die Keys mit easyrsa erstellt?

Mal als kleine Zwischenfrage - ist es denn schon jemandem gelungen dieses easyrsa unter FreeBSD zu benutzen?

Columbo0815 · 8 Juni 2016

Ja, ich nutze es

Sickboy · 8 Juni 2016

peterle schrieb:
Ja läuft denn der Server überhaupt und wie sieht die config des Clients aus?

Ja, der Server läuft.

Die Config des Clients habe ich als Bild angehangen.

Nimm tun0 anstatt tun (könnte schon der Grund sein)

"tun" ist der Name des Kernelmoduls, nicht des Interfaces.

Vielleicht willst du dein Netzwerk beim Server einen anderen IP-Adressenbereich verpassen. Was wenn der Client auch ein 192.168.0-Netz hat? Das ist doch sehr gängig...

Habe ich mal auf 10.16.0.0 geändert.

erhöhe temporär das Loglevel: "verb 9". Damit wird mehr protokolliert, was bei der Fehlersuche helfen kann.

Hilft leider nicht. Brauchbare Infos gibt es da auch nicht.

Mal als kleine Zwischenfrage - ist es denn schon jemandem gelungen dieses easyrsa unter FreeBSD zu benutzen?

Ja:

Code:

# PKI-Ordner erzeugen:
./easyrsa.real init-pki

# CA-Schlüsselpaar/Zertifikat erzeugen:
./easyrsa.real build-ca

# Schlüsselpaar für den Server
./easyrsa.real gen-req <server-name> nopass

# Dito Client:
./easyrsa.real gen-req <client-name>

# Client signieren:
./easyrsa.real sign client <client-name>

# Server signieren:
./easyrsa.real sign server <server-name>

# DH erzeugen:
./easyrsa.real gen-dh

# PKCS#12:
openssl pkcs12 -export -in ./issued/openvpn-client.crt -inkey ./private/openvpn-client.key -certfile ca.crt -out vpn.p12

Columbo0815 · 8 Juni 2016

"tun" ist der Name des Kernelmoduls, nicht des Interfaces.

Aus der offiziellen Beispielskonfiguration:

# On non-Windows systems, you can give
# an explicit unit number, such as tun0.

Das mag (doch) nicht der Grund sein, weshalb es nicht läuft, wollte ich aber der Vollständigkeit wegen ergänzen.

Habe ich mal auf 10.16.0.0 geändert.

Das war tatsächlich nur ein Hinweis. Es war klar, dass das nicht helfen kann. Da du aber ggfls. nicht immer sagen kannst, von wo sich die Clients einwählen, ist ein "ungängiges" Netzwerk ganz nett.

Hast du die richtigen Zertifikate zum erstellen der vpn.p12 verwendet? Insbesondere bei -certfile ca.crt hab ich schon das ein oder andere mal die falsche Datei genommen (auf dem Client)

Illuminatus · 8 Juni 2016

Code:

openssl verify -verbose -CAfile /usr/local/etc/openvpn/keys/ca.crt /usr/local/etc/openvpn/keys/issued/rmk-openvpn-server.crt

Die Ausgabe wird sicherlich auch für das Client-Cert OK sein. Aber ich gehe stark davon aus dass es wirklich ein Firewall/Netz Problem ist, wie die Fehlermeldung andeutet. Hast du mal auf dem Server als ein Benutzer einen openvpn-client Prozess mit der gleichen config testweise gestartet?

Wie lang sind eigentlich deine Keys? Verwende doch mal kürzere...

Sickboy · 8 Juni 2016

Columbo0815 schrieb:
Hast du die richtigen Zertifikate zum erstellen der vpn.p12 verwendet? Insbesondere bei -certfile ca.crt hab ich schon das ein oder andere mal die falsche Datei genommen (auf dem Client)

Ich habe die vpn.p12 auf dem Server erstellt und daher auch das CA des Servers benutzt. Auf den Client habe ich das selbe CA kopiert.

Alles i.O.:

Code:

/usr/local/etc/openvpn/issued/rmk-openvpn-server.crt: OK

Hast du mal auf dem Server als ein Benutzer einen openvpn-client Prozess mit der gleichen config testweise gestartet?

Nein, noch nicht.

Wie lang sind eigentlich deine Keys? Verwende doch mal kürzere...

2048er Schlüssel. Ist doch okay, oder?

Illuminatus · 8 Juni 2016

Sickboy schrieb:
2048er Schlüssel. Ist doch okay, oder?

Prinzipiell ja. Hatte selber mal in einigen Setups längere Keys, aber diverse NAT Gerätschaften hatten mit der MTU sich nicht kompatibel verhalten.

Zeigt der Screenshot eigentlich schon die Advanced Ansicht oder gibt es da mehr?

Sickboy · 8 Juni 2016

Illuminatus schrieb:
Prinzipiell ja. Hatte selber mal in einigen Setups längere Keys, aber diverse NAT Gerätschaften hatten mit der MTU sich nicht kompatibel verhalten.

Kann ich mir bei meinem Setup nicht vorstellen.

Zeigt der Screenshot eigentlich schon die Advanced Ansicht oder gibt es da mehr?

Nein, siehe Anhang.

Illuminatus · 8 Juni 2016

jetzt könnte ein tcpdump interessant werden + das was ich mit dem lokalen client-prozess meinte

foxit · 8 Juni 2016

Ist der Client/Server virtuell (z.B. VMware ESXi)? Wenn ja promiscuous mode mal bitte auf dem vSwitch einschalten.

Columbo0815 · 8 Juni 2016

Was kannst du bei "Connection NAT" einstellen?

Sickboy · 8 Juni 2016

foxit schrieb:
Ist der Client/Server virtuell (z.B. VMware ESXi)? Wenn ja promiscuous mode mal bitte auf dem vSwitch einschalten.

Ja, der Server ist virtuell und läuft AFAIK mit VMware. Ich kann den promiscuous mode nicht aktivieren, da muss ich beim Support anfragen.

Edit: promiscuous mode ist laut Support bereits aktiviert.

Was kannst du bei "Connection NAT" einstellen?

- Local 1:1 NAT
- Local Masquerading
- Remote Masquerading
- Port Forwarding
- Host Forwarding

Sickboy · 8 Juni 2016

Vielleicht sollte ich noch erwähnen, dass sich der Client per Mobilfunk (4G) einwählt.

Illuminatus · 8 Juni 2016

Das riecht nach Carrier-grade-NAT. Kannst du testweise auf TCP umstellen und sicher stellen dass ICMP Pakete erlaubt sind?

Sickboy · 8 Juni 2016

Ich habe mal OpenVPN auf einem virtuellen Windows XP installiert. Der Windows-Client wirft den gleichen Fehler: TLS Handshake Error. Es liegt also nicht umbedingt an der Mobilfunkverbindung des ersten Clients. Im Log des Servers steht wieder:

Code:

Wed Jun  8 14:08:05 2016 A.B.C.D:13617 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jun  8 14:08:05 2016 A.B.C.D:13617 TLS Error: TLS handshake failed
Wed Jun  8 14:08:05 2016 A.B.C.D:13617 SIGUSR1[soft,tls-error] received, client-instance restarting

Columbo0815 · 8 Juni 2016

Kannst du mal die komplette Config des Windowsclients zeigen?

Sickboy · 8 Juni 2016

Ich bin mir mittlerweile ziemlich sicher, dass es an den Keys liegt. Ich erzeuge gerade neue und teste alles noch einmal.

Edit: Mit den neuen Schlüsseln klappt es leider auch nicht. Die Client-Config von OpenVPN unter Windows:

Code:

client

;dev tap
dev tun

;dev-node MyTap

;proto tcp
proto udp

remote E.F.G.H 1194 # E.F.G.H ist die Server-IP
;remote my-server-2 1194

;remote-random

resolv-retry infinite

nobind

;user nobody
;group nobody

persist-key
persist-tun

;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

;mute-replay-warnings

ca ca.crt
cert client.crt
key client.key

remote-cert-tls server

;tls-auth ta.key 1

cipher BF-CBC
comp-lzo

verb 3
;mute 20

Sickboy · 8 Juni 2016

Mit TCP funktioniert es jetzt zumindest mit dem 4G-Client. Unter Windows XP wird die Verbindung aber abgebrochen. Leider funktioniert DNS noch nicht.

OpenVPN unter FreeBSD 10

Müßiggänger

Forenkasper

Kaffeemann

Forenkasper

Kaffeemann

Müßiggänger

Anhänge

Kaffeemann

in geheimer Mission

Müßiggänger

in geheimer Mission

Müßiggänger

Anhänge

in geheimer Mission

Well-Known Member

Kaffeemann

Müßiggänger

Müßiggänger

in geheimer Mission

Müßiggänger

Kaffeemann

Müßiggänger

Müßiggänger

Wir schützen deine Privatsphäre