Site-to-Site (SSL-VPN) mit Debian als Server/Gegenstelle

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
andydld
Beiträge: 71
Registriert: Mi 26.09.2012, 10:10
Wohnort: Haibach
Kontaktdaten:

Site-to-Site (SSL-VPN) mit Debian als Server/Gegenstelle

Beitrag von andydld »

Hallo Zusammen,

ich versuche aktuell folgende Kombi zum Laufen zu bekommen:

Securepoint UTM (NFR) als Site-to-Site Client mit SSL-VPN zu einem Debian 10 Buster als OpenVPN-Server.

Grundsätzlich scheint die SSL-VPN-Verbindung i.O. zu sein, da sie erfolgreich aufgebaut wird und auch bestehen bleibt.
Netzwerk-Objekte und FIrewall-Regeln sind ebenfalls angelegt.

So weit wie ich es aktuell überschauen kann, stimmt irgendetwas mit dem Routing nicht,
denn ein Ping im Transfer-Netz zu beiden Enden (10.8.0.1 und 10.8.0.2) klappt sowohl auf der UTM als auch auf dem Debian.
Aber ein Ping ins andere Netz, z.B. auf 192.168.1.10, klappt nicht.

Laut tcpdump auf der UTM kommt nichts an.
tcpdump auf dem Debian gibt folgendes aus, wenn man versucht vom Debian aus die 192.168.1.10 zu pingen:

Code: Alles auswählen

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:52:18.467273 IP 10.8.0.1 > 192.168.1.10: ICMP echo request, id 906, seq 1, length 64
Die Routen auf der UTM:

Code: Alles auswählen

root@firewall:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
10.8.0.0        *               255.255.255.0   U     0      0        0 tun2
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
Und hier vom Debian:

Code: Alles auswählen

root@debian:/home/user# /sbin/route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    0      0        0 enp0s3
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
192.168.1.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0
Das Ganze ist ein Test-Aufbau bei uns in der Werkstatt, daher stellt das Internet/WAN das Netz "192.168.0.0/24" dar.
Ferner hat die Debian-Maschine nur eine NIC und es gibt im Moment kein Netz dahinter.
Dennoch sollte ja der Ping zu 192.168.1.10 möglich sein.

Die Grundkonfiguration habe ich aus einer pfSense, die als OpenVPN-Server für diese UTM eingerichtet war, abgeschaut und mit dieser klappte alles inkl. Routing, Ping, etc..
Anbei die OpenVPN-Server-Konfig. des Debian:

Code: Alles auswählen

port 1195

proto udp

dev tun

tls-server
ca ca.crt
cert OpenVPN-Server.crt
key OpenVPN-Server.key

dh dh2048.pem

topology subnet

server 10.8.0.0 255.255.255.0

ifconfig 10.8.0.1 10.8.0.2

keepalive 10 120

cipher BF-CBC

comp-noadapt

persist-key
persist-tun

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

log         /var/log/openvpn/openvpn.log

verb 3

explicit-exit-notify 1

auth SHA1

route 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/csc
Inhalt der CSC:

Code: Alles auswählen

push "route 192.168.2.0 255.255.255.0"
iroute 192.168.1.0 255.255.255.0
Laut UTM-Log wird der Inhalt der CSC auch an die UTM übermittelt, warum das dann allerdings nicht in den Routen zu sehen ist versteh ich gerade ebenfalls nicht.

Code: Alles auswählen

24.06.2020 08:41:01openvpn-pfSense-clientPUSH: Received control message: 'PUSH_REPLY,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 60,route 192.168.2.0 255.255.255.0,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-128-GCM'24.06.2020 08:41:01openvpn-pfSense-client/sbin/ip route add 192.168.2.0/24 via 10.8.0.124.06.2020 09:33:04openvpn-pfSense-client/sbin/ip route del 192.168.2.0/24
Soweit der Stand. Evtl. hat ja jemand so eine Kombi schonmal gehabt oder die zündende Idee woran es hängt.

Vielen Dank vorab schonmal.

Gruß

Andy

andydld
Beiträge: 71
Registriert: Mi 26.09.2012, 10:10
Wohnort: Haibach
Kontaktdaten:

Beitrag von andydld »

Ich hab jetzt mal eine OpenVPN-Server-Konfig. gebaut die in etwa der eines UTM Site-to-Site-Servers entspricht:

Code: Alles auswählen

# UTM: /etc/openvpn/openvpn.conf:

# iproute "/sbin/ip"
# plugin  "/usr/lib/openvpn/plugins/openvpn-session.so"
# persist-tun
# persist-key
# verb 4
# dev-type tun
# tls-version-min 1.0
# tls-version-max 1.2
# tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:
# TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:
# TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256:TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256:
# TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA:TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-128-GCM-SHA256:
# TLS-RSA-WITH-AES-256-CBC-SHA256:TLS-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-128-CBC-SHA256:TLS-RSA-WITH-AES-128-CBC-SHA:TLS-RSA-WITH-3DES-EDE-CBC-SHA
# dh /rootdisk/config/dhparams2048.pem

# UTM: SSL-VPN/OpenVPN Site-to-Site Server via ps aux | grep "openvpn":

# --dev tun1 --mode server --tls-server --proto udp --tun-mtu 1500 --ca /etc/openvpn/OpenVPN-S2S-server.ca --cert /etc/openvpn/OpenVPN-S2S-server.cert --key /etc/openvpn/OpenVPN-S2S-server.cert --syslog openvpn-OpenVPN-S2S-server
# --server 10.8.1.0 255.255.255.0 --multihome --topology subnet --client-config-dir /var/openvpn/OpenVPN-S2S-server --lport 1195 --reneg-sec 3600 --keepalive 10 120

# Ab hier die neue Debian-Konfig.:

dev tun

mode server

tls-server

proto udp

tun-mtu 1500

ca ca.crt
cert OpenVPN-Server.crt
key OpenVPN-Server.key

server 10.8.0.0 255.255.255.0

topology subnet

port 1195

dh dh2048.pem

keepalive 10 120

# cipher BF-CBC
cipher AES-256-CBC

comp-noadapt

persist-key
persist-tun

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

log         /var/log/openvpn/openvpn.log

verb 4

explicit-exit-notify 1

auth SHA256

route 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/csc/server

# Inhalt der OpenVPN-Client:

# iroute 192.168.2.0 255.255.255.0
# push "route 192.168.1.0 255.255.255.0"
# ifconfig-push 10.8.1.2 255.255.255.0
Danke an jan aus dem Support für die Hilfe.

Die Verbindung wird nach wie vor erfolgreich aufgebaut, die Endpunkte (10.8.0.1, 10.8.0.2) sind ebenfalls nach wie vor pingbar, aber das Problem das man z.B. 192.168.1.10 nicht anpingen kann bleibt. In der Zwischenzeit wurde auf der Debian-Maschine OpenVPN auf die aktuelle Stable (2.4.9) aktualisiert, auch das half nichts.
Was mir jetzt im Log der UTM auffällt ist, das offenbar die csc nicht erfolgreich verarbeitet wird:

Code: Alles auswählen

25.06.2020 16:08:01    openvpn-OpenVPN-client    TUN/TAP device tun0 opened
25.06.2020 16:08:01    openvpn-OpenVPN-client    TUN/TAP TX queue length set to 100
25.06.2020 16:08:01    openvpn-OpenVPN-client    do_ifconfig,tt->did_ifconfig_ipv6_setup=0
25.06.2020 16:08:01    openvpn-OpenVPN-client    /sbin/ip link set dev tun0 up mtu 1500
25.06.2020 16:08:01    openvpn-OpenVPN-client    /sbin/ip addr add dev tun0 10.8.0.2/24 broadcast 10.8.0.255
25.06.2020 16:08:01    openvpn-OpenVPN-client    /sbin/ip route add 192.168.1.0/24 via 10.8.0.1
25.06.2020 16:08:01    openvpn-OpenVPN-client    ERROR: Linux route add command failed: external program exited with error status: 2
Bei den Routen sowie der tcpdump-Ausgabe hat sich nichts geändert. Mit einem höheren Log-Level des OpenVPN-Servers bin ich leider nicht weitergekommen, allerdings verstehe ich das Log dann auch nicht wirklich.

andydld
Beiträge: 71
Registriert: Mi 26.09.2012, 10:10
Wohnort: Haibach
Kontaktdaten:

Beitrag von andydld »

Ich mach dann mal als Alleinunterhalter weiter ;-)

Lange Rede, kurzer Sinn: Letztlich konnte das Ganze gelöst werden. Woran es ursprünglich alles gescheitert ist kann ich nicht sagen. Nachdem Adaptieren einer UTM-Site-to-Site-Konfiguration und dem Ausbügeln eigener Fehler (in der csc sind die Netzte vertauscht) scheint es nun mit folgender Konfiguration auf der Debian-Seite zu Laufen:

/etc/openvpn/server.conf:

Code: Alles auswählen

dev tun

mode server

tls-server

proto udp

tun-mtu 1500

ca ca.crt
cert OpenVPN-Server.crt
key OpenVPN-Server.key

server 10.8.0.0 255.255.255.0

topology subnet

port 1195

dh dh2048.pem

keepalive 10 120

cipher AES-256-CBC

comp-noadapt

persist-key
persist-tun

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

log /var/log/openvpn/openvpn.log

verb 3

explicit-exit-notify 1

auth SHA256

route 192.168.1.0 255.255.255.0

client-config-dir /etc/openvpn/csc/server
/etc/openvpn/csc/server/OpenVPN-Client:

Code: Alles auswählen

iroute 192.168.1.0 255.255.255.0
push "route 192.168.2.0 255.255.255.0"
ifconfig-push 10.8.0.2 255.255.255.0
Das Ganze Thema ist nun auch in zwei Blog-Beiträgen verarbeitet:

https://www.andysblog.de/securepoint-utm-site-to-site-ssl-vpn-mit-debian-als-server-gegenstelle
https://www.andysblog.de/oeffentliche-ipv4-adresse-an-cgn-ds-lite-anschluss-mittels-vserver-und-securepoint-utm

Antworten