SSL-VPN kein Daten austausch möglich

Bene · Beitrag von **Bene** » Di 26.06.2018, 15:28

Hallo zusammen,

ich habe das Problem das ich über eine SSL-VPN Verbindung keine Daten schicken kann.
Der SSL-VPN Client Verbindet sich ein Ping oder eine RDP-Verbindung ist nicht möglich.
Hab mich bei der Einrichtung an den Wiki-Artikel gehalten.

Die UTM v11.7 ist hinter einem Telekom Router (DigiBox mit Firewall). In der Firewall der DigiBox ist der Port 443 für das User Portal und der Port 1001 für den SSL-VPN frei gegeben.

Ich habe die Impliziten Regeln gesetzt sowie eine Portfielder Regel erstellt die RDP und SSL-VPN zulässt. Habe auch unter den Diensten den Standart Port auf 1001 abgeändert.
Bei den Benutzer und Gruppen Einstellungen habe ich dem User die Berechtigungen für das Userinterface und den SSL-VPN zugewiesen. Außerdem habe ich den User zu einer Gruppe zugewiesen und dieser wiederum den SSL-VPN zugewiesen.

Das LOG des VPN Client
Try to start OpenVPN connection FWK_ XXXXXX_local_ XXXXXX _Test C:/Users/User/AppData/Roaming/Securepoint SSL VPN/config/FWK_XXXXXX_local_ XXXXXX _Test
Tue Jun 26 14:52:10 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Tue Jun 26 14:52:10 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jun 26 14:52:10 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10

Tue Jun 26 14:52:31 2018 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Tue Jun 26 14:52:31 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]80.151.74.134:1001
Tue Jun 26 14:52:31 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Jun 26 14:52:31 2018 UDP link local: (not bound)
Tue Jun 26 14:52:31 2018 UDP link remote: [AF_INET] XXXXXX:1001
Tue Jun 26 14:52:31 2018 TLS: Initial packet from [AF_INET] XXXXXX:1001, sid=XXXXXX
Tue Jun 26 14:52:31 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Jun 26 14:52:31 2018 VERIFY OK: depth=1, C=DE, ST=NRW, L=Koeln, O= XXXXXX, OU=IT, CN=CA-VPN- XXXXXX, emailAddress= XXXXXX
Tue Jun 26 14:52:31 2018 VERIFY OK: depth=0, CN=Ser-Zer-FW, C=DE, ST=NRW, L=Koeln, O= XXXXXX, OU=IT, emailAddress= XXXXXX
Tue Jun 26 14:52:32 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jun 26 14:52:32 2018 [Ser-Zer-FW] Peer Connection Initiated with [AF_INET]80.151.74.134:1001
Tue Jun 26 14:52:33 2018 SENT CONTROL [Ser-Zer-FW]: 'PUSH_REQUEST' (status=1)
Tue Jun 26 14:52:33 2018 PUSH: Received control message: 'PUSH_REPLY,route 192.168.158.0 255.255.255.0,route-gateway 192.168.70.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.70.2 255.255.255.0'
Tue Jun 26 14:52:33 2018 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jun 26 14:52:33 2018 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jun 26 14:52:33 2018 OPTIONS IMPORT: route options modified
Tue Jun 26 14:52:33 2018 OPTIONS IMPORT: route-related options modified
Tue Jun 26 14:52:33 2018 ROUTE_GATEWAY 192.168.2.254/255.255.255.0 I=16 HWADDR= XXXXXX
Tue Jun 26 14:52:33 2018 open_tun
Tue Jun 26 14:52:33 2018 TAP-WIN32 device [sophos vpn] opened: \\.\Global\{4BED8DF7-58C7-4CAD-8C35-E0ADDE33AA8E}.tap
Tue Jun 26 14:52:33 2018 TAP-Windows Driver Version 9.21
Tue Jun 26 14:52:33 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 192.168.70.0/192.168.70.2/255.255.255.0 [SUCCEEDED]
Tue Jun 26 14:52:33 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.70.2/255.255.255.0 on interface {4BED8DF7-58C7-4CAD-8C35-E0ADDE33AA8E} [DHCP-serv: 192.168.70.254, lease-time: 31536000]
Tue Jun 26 14:52:33 2018 Successful ARP Flush on interface [6] {4BED8DF7-58C7-4CAD-8C35-E0ADDE33AA8E}
Tue Jun 26 14:52:33 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Jun 26 14:52:35 2018 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Tue Jun 26 14:52:35 2018 C:\WINDOWS\system32\route.exe ADD 192.168.158.0 MASK 255.255.255.0 192.168.70.1
Tue Jun 26 14:52:35 2018 env_block: add PATH=C:\WINDOWS\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Jun 26 14:52:35 2018 Initialization Sequence Completed
Tue Jun 26 14:52:33 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.70.2/255.255.255.0 on interface {4BED8DF7-58C7-4CAD-8C35-E0ADDE33AA8E} [DHCP-serv: 192.168.70.254, lease-time: 31536000]

Im Log der Firewall bekomme ich folgenden Eintrag.
26.06.2018 11:22:49 | Kernel | DROP: (DEFAULT DROP) 192.168.70.2:62168 -> tun0 ->bridge0 -> 192.168.158.223:161

Bin ein wenig ratlos

kennethj · Beitrag von **kennethj** » Di 26.06.2018, 15:35

Moin,

ich vermute mal das entweder die Regel oder ein eines der Netzwerkobjekte in der Regel nicht stimmen. Alternativ können es noch Zonen Probleme auf den Schnittstellen sein

Gruß

Bene · Beitrag von **Bene** » Di 26.06.2018, 16:04

Ja das war auch mein Gedanke hab auch schon so einiges ausprobiert aber ohne Erfolg.

kennethj · Beitrag von **kennethj** » Di 26.06.2018, 16:25

Können Sie mal die Regel(n) und die Objekte hier niederschreiben? (Quelle/Ziel/Dienst sowie beim Objekt IP/Zone

Bene · Beitrag von **Bene** » Do 28.06.2018, 14:14

Danke erst mal für die Hilfe !!!
Die Links sind Bilder von den einstellungen

Portfilter Regeln
sslVPN-Network ->internal-network | openvpn-udp |Accept
sslVPN-Network ->Server | ms-rdp |Accept
https://www.dropbox.com/s/t9eppwue3kv5ceg/Regeln.PNG?dl=0

Dienste
openvpn-udp: Port 1001, Protokoll udp

Netzwerkobjekte
sslVPN-Network: Adresse 192.168.70.0/24, Zone vpn-openvpn-XXXXX
Server (Netzwerkgruppe): beinhalten 3 Host mit den IPs der Server, Zone intern
https://www.dropbox.com/s/z8rhn6u5kdfhbtv/vpn-Network.PNG?dl=0

Netzwerkkonfiguration
Eth0 ist an die DigiBox angeschlossen.
Bridge0 besteht aus dem wlan-0 und eth1

Zonen
https://www.dropbox.com/s/abrhbpwy5tpwwq7/Zonen.PNG?dl=0

Beitrag von **Christian E.** » Do 28.06.2018, 15:30

Hallo Bene,

in deinem ersten Screenshot sieht man, dass du den openvpn-udp Dienst in das interne Netz freigegeben hast. Mit diesem möchtest du aber gar nicht zugreifen. Mit diesem Dienst/Port baust du den SSL Tunnel zur Firewall auf.

26.06.2018 11:22:49 | Kernel | DROP: (DEFAULT DROP) 192.168.70.2:62168 -> tun0 ->bridge0 -> 192.168.158.223:161

Im Log sieht man, dass der Server mit dem Port 161 (SNMP) angesprochen wird, das ist laut Portfilter aber nicht freigegeben und wird daher gedropt. Es müsste der Dienst in der Regel angepasst werden. Je nachdem mit welchem Dienst durch den Tunnel auf das interne Netz/Server zugegriffen werden soll.
Die zweite Regel wäre für RDP korrekt. Eventuell antworten aber die Server nicht auf Anfragen aus dem Transfernetz (192.168.70.0/24), da sie dieses nicht kennen bzw. die Windows Firewall den Zugriff blockiert. Das kann man mit einem NAT in der Regel umgehen: HIDENAT - Schnittstelle: internal-interface.
So kommen dann die Anfragen bei den Servern mit der IP Adresse der Firewall an.

Beste Grüße
Christian

Bene · Beitrag von **Bene** » Do 28.06.2018, 16:05

Ooohh man manchmal hat man echt ein Brett vor dem Kopf.
Danke für den Hinweis. Klappt jetzt alles.

Immer diese dummen Sophos User

Danke an alle die mir geholfen haben.

Gruß Bene