Securepoint Security Solutions Support Forum

Moderator: Securepoint

 
tlietz
Themen-Autor
Beiträge: 10
Registriert: Mi 12.06.2019, 08:53

SSL-VPN mit 2-FA und UTM 11.8.3.2: AUTH_FAILED

Mi 12.06.2019, 09:28

Hallo zusammen,

wir nutzen das SSL-VPN einer Terra Black Dwarf UTM mit der FW 11.8.3.2 und wollten die 2-Faktorauthentifizierung mit den Hardware Token Feitian c200 in Betrieb nehmen.
Die OTP-Token sind entsprechend eingetragen und der Code lässt sich validieren. Sofern ich jedoch die OTP-Funktionalität für SSL-VPN aktiviere scheint es Probleme in Verbindung mit dem Securepoint SSL-VPN Client 2.0.25 zu geben.

Ich persönliche nutze MacOS und mit Tunnelblick als OpenVPN Software funktioniert alles reibungslos, ich gebe meinen Benutzernamen und Kennwort ein und erhalte sofort die Nachfrage nach dem OTP-Token und bin anschließend verbunden.

Unsere Mitarbeiter nutzen jedoch Windows-System mit dem Securepoint SSL-VPN Client damit können wir uns jedoch nicht anmelden. Die Nachfrage nach Benutzername und Kennwort erscheint und werden korrekt eingegeben. Es folgt jedoch keine Nachfrage nach dem OTP-Token und der Client beendet direkt den Verbindungsaufbau und es erscheint ein rotes Ausrufezeichen. Nach dem studieren des Client-Log und etwas googeln habe ich in einem Forum ein Eintrag gefunden den ich in der client.conf ergänzt habe: pull-filter ignore "auth-token", der zumindest auf einem Rechner Abhilfe schaffte und die Verbindung lies sich aufbauen - zumindest im 2. Anlauf. Die Abfrage nach Benutzername und Kennwort erscheint, es folgt das rote Ausrufezeichen und dann nach einigen Sekunden kam dann der OTP-Dialog und die Verbindung lies sich aufbauen. Leider half dies nicht bei allen Rechnern und scheint mir auch keine "wirkliche" Lösung zu sein.

Der Windows-Client meldet folgendes:


Try to start OpenVPN connection praxis_fw01_mkk_int_vpn_tunnel C:/Users/Detlef/AppData/Roaming/Securepoint SSL VPN/config/praxis_fw01_mkk_int_vpn_tunnel
Mon Jun 10 19:38:37 2019 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Mon Jun 10 19:38:37 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Mon Jun 10 19:38:37 2019 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Mon Jun 10 19:39:11 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1195
Mon Jun 10 19:39:11 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Mon Jun 10 19:39:11 2019 UDP link local: (not bound)
Mon Jun 10 19:39:11 2019 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1195
Mon Jun 10 19:39:11 2019 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1195, sid=3f4b0421 424db954
Mon Jun 10 19:39:11 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Jun 10 19:39:12 2019 VERIFY OK: depth=1, DC=int, DC=mkk, CN=MKK-ROOT-CA
Mon Jun 10 19:39:12 2019 Validating certificate extended key usage
Mon Jun 10 19:39:12 2019 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Mon Jun 10 19:39:12 2019 [praxis-fw01.mkk.int] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:1195
Mon Jun 10 19:39:13 2019 SENT CONTROL [praxis-fw01.mkk.int]: 'PUSH_REQUEST' (status=1)
ERROR: Received AUTH_FAILED control message
Mon Jun 10 19:39:13 2019 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:XXXXXXXX/fNx8lt8WujxPGGXXXXXXXXgXy5yPQ=:ZGtvZW5pZw==:Please enter token PIN
Mon Jun 10 19:39:13 2019 SIGTERM received, sending exit notification to peer
ERROR: Application Exiting!
Mon Jun 10 19:39:14 2019 SIGTERM[soft,exit-with-notification] received, process exiting


So wie es scheint kann der Client mit dem Challenge Response der von der UTM kommt nichts anfangen und hält es für eine Statusmessage o.ä.

Bei MacOS unter Tunnelblick sieht das ganze so aus:

2019-06-12 09:17:02.193805 *Tunnelblick: macOS 10.14.5; Tunnelblick 3.7.9 (build 5320); prior version 3.7.7 (build 5150)
2019-06-12 09:17:02.653850 *Tunnelblick: Attempting connection with praxis-fw01-tun1.mkk.int using shadow copy; Set nameserver = 769; monitoring connection
2019-06-12 09:17:02.654606 *Tunnelblick: openvpnstart start praxis-fw01-tun1.mkk.int.tblk 61344 769 0 1 0 1065264 -ptADGNWradsgnw 2.4.7-openssl-1.0.2r
2019-06-12 09:17:02.683821 *Tunnelblick: openvpnstart starting OpenVPN
2019-06-12 09:17:02.904585 OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May 22 2019
2019-06-12 09:17:02.904832 library versions: OpenSSL 1.0.2r  26 Feb 2019, LZO 2.10
2019-06-12 09:17:02.909584 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:61344
2019-06-12 09:17:02.909662 Need hold release from management interface, waiting...
2019-06-12 09:17:03.296836 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:61344
2019-06-12 09:17:03.319001 MANAGEMENT: CMD 'pid'
2019-06-12 09:17:03.319070 MANAGEMENT: CMD 'auth-retry interact'
2019-06-12 09:17:03.319109 MANAGEMENT: CMD 'state on'
2019-06-12 09:17:03.319144 MANAGEMENT: CMD 'state'
2019-06-12 09:17:03.319203 MANAGEMENT: CMD 'bytecount 1'
2019-06-12 09:17:03.325502 *Tunnelblick: Established communication with OpenVPN
2019-06-12 09:17:03.327978 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2019-06-12 09:17:03.333209 MANAGEMENT: CMD 'hold release'
2019-06-12 09:17:07.145033 MANAGEMENT: CMD 'username "Auth" "tlietz"'
2019-06-12 09:17:07.145130 MANAGEMENT: CMD 'password [...]'
2019-06-12 09:17:07.146455 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2019-06-12 09:17:07.230822 MANAGEMENT: >STATE:1560323827,RESOLVE,,,,,,
2019-06-12 09:17:07.281979 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:07.282087 Socket Buffers: R=[786896->786896] S=[9216->9216]
2019-06-12 09:17:07.282116 UDP link local: (not bound)
2019-06-12 09:17:07.282142 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:07.282199 MANAGEMENT: >STATE:1560323827,WAIT,,,,,,
2019-06-12 09:17:07.312261 MANAGEMENT: >STATE:1560323827,AUTH,,,,,,
2019-06-12 09:17:07.312340 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1195, sid=77b69d0b d7b5ccef
2019-06-12 09:17:07.327378 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2019-06-12 09:17:08.009648 VERIFY OK: depth=1, DC=int, DC=mkk, CN=MKK-ROOT-CA
2019-06-12 09:17:08.012432 Validating certificate extended key usage
2019-06-12 09:17:08.012571 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2019-06-12 09:17:08.012618 VERIFY EKU OK
2019-06-12 09:17:08.012656 VERIFY OK: depth=0, CN=praxis-fw01.mkk.int, C=DE, ST=XXX, L=XXX, O=XXX, OU=XXX, emailAddress=XXX
2019-06-12 09:17:08.135426 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
2019-06-12 09:17:08.135541 [praxis-fw01.mkk.int] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:09.469979 MANAGEMENT: >STATE:1560323829,GET_CONFIG,,,,,,
2019-06-12 09:17:09.470137 SENT CONTROL [praxis-fw01.mkk.int]: 'PUSH_REQUEST' (status=1)
2019-06-12 09:17:09.489742 AUTH: Received control message: AUTH_FAILED,CRV1:R,E:XXXXXXXX/unDohyRGqPEh6T1O1XXXXXXXXnBG2GCC76o=:dGxpZXR6:Please enter token PIN
2019-06-12 09:17:09.531487 SIGUSR1[soft,auth-failure] received, process restarting
2019-06-12 09:17:09.531591 MANAGEMENT: >STATE:1560323829,RECONNECTING,auth-failure,,,,,
2019-06-12 09:17:09.534112 *Tunnelblick: Saved dynamic challenge info for user tlietz with flags 'R,E', state 'XXXXXXXX/unDohyRGqPEh6T1O1XXXXXXXXnBG2GCC76o=', and prompt 'Please enter token PIN'
2019-06-12 09:17:09.692340 *Tunnelblick: No 'reconnecting.sh' script to execute
2019-06-12 09:17:09.699165 MANAGEMENT: CMD 'hold release'
2019-06-12 09:17:09.699938 MANAGEMENT: CMD 'hold release'
2019-06-12 09:17:15.532102 *Tunnelblick: User responded to dynamic challenge
2019-06-12 09:17:15.533127 MANAGEMENT: CMD 'username "Auth" "tlietz"'
2019-06-12 09:17:15.533216 MANAGEMENT: CMD 'password [...]'
2019-06-12 09:17:15.533826 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2019-06-12 09:17:15.534620 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:15.534694 Socket Buffers: R=[786896->786896] S=[9216->9216]
2019-06-12 09:17:15.534719 UDP link local: (not bound)
2019-06-12 09:17:15.534743 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:15.534783 MANAGEMENT: >STATE:1560323835,WAIT,,,,,,
2019-06-12 09:17:15.560478 MANAGEMENT: >STATE:1560323835,AUTH,,,,,,
2019-06-12 09:17:15.560541 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:1195, sid=4080f86f 611bd6d7
2019-06-12 09:17:16.201362 VERIFY OK: depth=1, DC=int, DC=mkk, CN=MKK-ROOT-CA
2019-06-12 09:17:16.208600 Validating certificate extended key usage
2019-06-12 09:17:16.208684 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2019-06-12 09:17:16.208730 VERIFY EKU OK
2019-06-12 09:17:16.208798 VERIFY OK: depth=0, CN=praxis-fw01.mkk.int, C=DE, ST=XXX, L=XXX, O=XXX, OU=XXX, emailAddress=XXX
2019-06-12 09:17:16.398330 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
2019-06-12 09:17:16.398505 [praxis-fw01.mkk.int] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:1195
2019-06-12 09:17:17.538679 MANAGEMENT: >STATE:1560323837,GET_CONFIG,,,,,,
2019-06-12 09:17:17.548761 SENT CONTROL [praxis-fw01.mkk.int]: 'PUSH_REQUEST' (status=1)
2019-06-12 09:17:17.593229 PUSH: Received control message: 'PUSH_REPLY,route 192.168.31.0 255.255.255.0,route 192.168.28.0 255.255.254.0,dhcp-option DNS 192.168.29.1,dhcp-option DOMAIN mkk.int,route-gateway 192.168.40.1,topology subnet,ping 10,ping-restart 120,ifconfig 192.168.40.3 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2019-06-12 09:17:17.593479 OPTIONS IMPORT: timers and/or timeouts modified
2019-06-12 09:17:17.593520 OPTIONS IMPORT: --ifconfig/up options modified
2019-06-12 09:17:17.593555 OPTIONS IMPORT: route options modified
2019-06-12 09:17:17.593585 OPTIONS IMPORT: route-related options modified
2019-06-12 09:17:17.593620 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2019-06-12 09:17:17.593652 OPTIONS IMPORT: peer-id set
2019-06-12 09:17:17.593687 OPTIONS IMPORT: adjusting link_mtu to 1624
2019-06-12 09:17:17.593911 OPTIONS IMPORT: data channel crypto options modified
2019-06-12 09:17:17.594112 Data Channel: using negotiated cipher 'AES-256-GCM'
2019-06-12 09:17:17.595579 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2019-06-12 09:17:17.596014 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2019-06-12 09:17:17.596606 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2019-06-12 09:17:17.596668 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2019-06-12 09:17:17.596708 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2019-06-12 09:17:17.597093 Opened utun device utun3
2019-06-12 09:17:17.599944 MANAGEMENT: >STATE:1560323837,ASSIGN_IP,,192.168.40.3,,,,
2019-06-12 09:17:17.600053 /sbin/ifconfig utun3 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2019-06-12 09:17:17.626591 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2019-06-12 09:17:17.626723 /sbin/ifconfig utun3 192.168.40.3 192.168.40.3 netmask 255.255.255.0 mtu 1500 up
2019-06-12 09:17:17.631186 /sbin/route add -net 192.168.40.0 192.168.40.3 255.255.255.0
                           add net 192.168.40.0: gateway 192.168.40.3
2019-06-12 09:17:25.724980 MANAGEMENT: >STATE:1560323845,ADD_ROUTES,,,,,,
2019-06-12 09:17:25.725258 /sbin/route add -net 192.168.31.0 192.168.40.1 255.255.255.0
                           add net 192.168.31.0: gateway 192.168.40.1
2019-06-12 09:17:25.735961 /sbin/route add -net 192.168.28.0 192.168.40.1 255.255.254.0
                           add net 192.168.28.0: gateway 192.168.40.1
2019-06-12 09:17:25.746834 Initialization Sequence Completed
2019-06-12 09:17:25.746949 MANAGEMENT: >STATE:1560323845,CONNECTED,SUCCESS,192.168.40.3,XXX.XXX.XXX.XXX,1195,,
2019-06-12 09:17:25.898010 *Tunnelblick: No 'connected.sh' script to execute
2019-06-12 09:17:25.968173 *Tunnelblick: DNS address 192.168.29.1 is being routed through the VPN
2019-06-12 09:17:28.153149 *Tunnelblick: process-network-changes: A system configuration change was ignored


Auch hier erscheint ein AUTH_FAIL aber er weiß mit dem CR umzugehen und fragt nach dem Token.

Die generiere Konfiguration aus der UTM für den Benutzer sieht wie folgt aus:
client
remote-cert-eku "TLS Web Server Authentication"
dev tun
tun-mtu 1500
# fragment 1300
mssfix
proto udp
float
remote XXX.XXX.XXX.XXX 1195
nobind
persist-key
persist-tun
ca praxis_fw01_mkk_int_vpn_tunnel-ca.pem
cert praxis_fw01_mkk_int_vpn_tunnel-cert.pem
key praxis_fw01_mkk_int_vpn_tunnel-cert.key
verb 3
mute 20
#auth-nocache
auth-user-pass
route-method exe
route-delay 2
#http-proxy server_IP port
#http-proxy-retry
reneg-sec 0
#comp-lzo yes
#redirect-gateway
explicit-exit-notify
cipher AES-256-CBC
auth SHA256

Hat jemand ein Idee wo das Problem liegen könnte?
Vielen Dank & Viele Grüße
 
Bjoern
Securepoint
Beiträge: 443
Registriert: Mi 03.07.2013, 10:06

Re: SSL-VPN mit 2-FA und UTM 11.8.3.2: AUTH_FAILED

Do 13.06.2019, 07:54

Hallo,

versuchen Sie einmal im Client den Token direkt hinter dem Kennwort einzugeben. 


Gruß Björn
 
tlietz
Themen-Autor
Beiträge: 10
Registriert: Mi 12.06.2019, 08:53

Re: SSL-VPN mit 2-FA und UTM 11.8.3.2: AUTH_FAILED

Mo 17.06.2019, 09:46

Hallo, 

das funktioniert leider auch nicht. 

Zumal ja eigentlich in den Release Notes angekündigt wurde, dass es jetzt ein separates Eingabefeld für den OTP-Token geben soll und nicht mehr dem Kennwort hintenangestellt werden muss.

Ein anderer Benutzer meldete hier im Forum das selbe Problem.

Viele Grüße
 
SimonK
Beiträge: 1
Registriert: Di 06.08.2019, 09:08

Re: SSL-VPN mit 2-FA und UTM 11.8.3.2: AUTH_FAILED

Di 06.08.2019, 09:14

Ich muss hier leider mal einen alten Beitrag wiederbeleben und mit nutzen...

Wir haben aktuell das "Problem", dass wir eine VPN Verbindung zu einem Kunden bzw. Dienstleister aufbauen müssen. Dabei wollen wir entweder vom Mac aus Tunnelblick benutzen oder und via OpenVPN (Ubuntu 18.04 Server) verbinden.

Die Verbindung ist via Zertifikaten und Benutzer und Passwort sowie OTP geschützt. Bis zu einem Firmware Update konnten wir uns anmelden, indem wir einfach den OTP ans Passwort angehangen haben - jedoch ist das aktuell nicht mehr möglich, der OTP wird aber auch nicht abgefragt. Ich habe daher in die OpenVPN Config "static-challenge" hinzugefügt (inkl. eines Textes wie OTP und 0, damit kein PW angezeigt wird).

Jedoch wird die Verbindung nach einem Aufbau immer wieder resettet.

Tue Aug  6 06:52:15 2019 Initialization Sequence Completed
Tue Aug  6 06:52:18 2019 Connection reset, restarting [0]
Tue Aug  6 06:52:18 2019 SIGUSR1[soft,connection-reset] received, process restarting


Muss man bei der Konfiguration des static-challenge im conf file noch etwas beachten? Muss eventuell die Gegenseite noch etwas anpassen?

Danke und Grüße
Simon
 
Bjoern
Securepoint
Beiträge: 443
Registriert: Mi 03.07.2013, 10:06

Re: SSL-VPN mit 2-FA und UTM 11.8.3.2: AUTH_FAILED

Fr 09.08.2019, 09:30

Hallo tlietz,

es wurde noch etwas mit der Version 11.8.4 bzgl. SSL-VPN und OTP gefixt. Probieren Sie es mit der aktuellen Version noch einmal.

Gruß Björn

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste