Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 10 replies
  • Subscribers 0 subscribers
  • Views 5482 views
  • Users 0 members are here
Options
Suggested

[9.195] No Remote Access via SSL VPN

TheExpert
Hello together,

for testing purposes with SSL VPN I'm using a Sophos UTM 9.2 Beta (9.195-6). Since a few days I can't get a connection via SSL VPN. I'm using the Sophos OpenVPN client. Here are the log messages with detailed log level:

2014:02:20-18:15:33 SophosUTM openvpn[8356]: MULTI: multi_create_instance called 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Re-using SSL/TLS context 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 LZO compression initialized 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ] 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ] 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server' 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client' 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Local Options hash (VER=V4): 'a8f55717' 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 Expected Remote Options hash (VER=V4): '22188c5b' 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 TLS: Initial packet from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1), sid=3179f9b4 a6ac239d 
2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [26] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0 
2014:02:20-18:15:35 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [14] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:35 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:35 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [22] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_ACK_V1 kid=0 [ 0 ] 
2014:02:20-18:15:39 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [14] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:40 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:40 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [22] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_ACK_V1 kid=0 [ 0 ] 
2014:02:20-18:15:47 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [14] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:48 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:15:48 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [22] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_ACK_V1 kid=0 [ 0 ] 
2014:02:20-18:16:03 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [14] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:16:04 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0 
2014:02:20-18:16:04 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 WRITE [22] to [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_ACK_V1 kid=0 [ 0 ] 
2014:02:20-18:16:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) 
2014:02:20-18:16:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 TLS Error: TLS handshake failed 
2014:02:20-18:16:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 SIGUSR1[soft,tls-error] received, client-instance restarting 


It's a bit tricky infrastructure because the Sophos UTM is running as virtual machine in a DMZ behind a Checkpoint Firewall. The two Interfaces of the Sophos UTM are connected to the DMZ which is separated into smaller VLANs. This worked fine on the second half of december and on january until the beginning of february.

I have updated the Sophos UTM and I renewed the CA certificate for SSL VPN to be sure that there are no issues with the certificates. But the problem still persists.

Are there any ideas?

Thank you

TheExpert
  • 0
    Could you please also check the client log. The server receives a reset from it right after the TLS negotiation started:

    2014:02:20-18:15:33 SophosUTM openvpn[8356]: 172.29.254.218:52407 UDPv4 READ [14] from [AF_INET]172.29.254.218:52407 (via [AF_INET]172.29.250.69%eth1): P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
  • 0 in reply to d12fk
    Hello together,

    here is the client log: 

    Fri Feb 21 11:50:48 2014 OpenVPN 2.3.0 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Aug 23 2013

    Fri Feb 21 11:50:48 2014 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340

    Fri Feb 21 11:50:48 2014 Need hold release from management interface, waiting...

    Fri Feb 21 11:50:48 2014 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340

    Fri Feb 21 11:50:48 2014 MANAGEMENT: CMD 'state on'

    Fri Feb 21 11:50:48 2014 MANAGEMENT: CMD 'log all on'

    Fri Feb 21 11:50:48 2014 MANAGEMENT: CMD 'hold off'

    Fri Feb 21 11:50:48 2014 MANAGEMENT: CMD 'hold release'

    Fri Feb 21 11:50:59 2014 MANAGEMENT: CMD 'username "Auth" "[...]"'

    Fri Feb 21 11:50:59 2014 MANAGEMENT: CMD 'password [...]'

    Fri Feb 21 11:50:59 2014 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).

    Fri Feb 21 11:50:59 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

    Fri Feb 21 11:50:59 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]

    Fri Feb 21 11:50:59 2014 MANAGEMENT: >STATE:1392979859,RESOLVE,,,

    Fri Feb 21 11:50:59 2014 UDPv4 link local: [undef]

    Fri Feb 21 11:50:59 2014 UDPv4 link remote: [AF_INET]*.*.*.*:1194

    Fri Feb 21 11:50:59 2014 MANAGEMENT: >STATE:1392979859,WAIT,,,

    Fri Feb 21 11:51:59 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

    Fri Feb 21 11:51:59 2014 TLS Error: TLS handshake failed

    Fri Feb 21 11:51:59 2014 SIGUSR1[soft,tls-error] received, process restarting

    Fri Feb 21 11:51:59 2014 MANAGEMENT: >STATE:1392979919,RECONNECTING,tls-error,,

    Fri Feb 21 11:51:59 2014 Restart pause, 2 second(s)

    Fri Feb 21 11:52:01 2014 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).

    Fri Feb 21 11:52:01 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

    Fri Feb 21 11:52:01 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]

    Fri Feb 21 11:52:01 2014 MANAGEMENT: >STATE:1392979921,RESOLVE,,,

    Fri Feb 21 11:52:01 2014 UDPv4 link local: [undef]

    Fri Feb 21 11:52:01 2014 UDPv4 link remote: [AF_INET]*.*.*.*:1194

    Fri Feb 21 11:52:01 2014 MANAGEMENT: >STATE:1392979921,WAIT,,,

    Fri Feb 21 11:53:01 2014 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

    Fri Feb 21 11:53:01 2014 TLS Error: TLS handshake failed

    Fri Feb 21 11:53:01 2014 SIGUSR1[soft,tls-error] received, process restarting

    Fri Feb 21 11:53:01 2014 MANAGEMENT: >STATE:1392979981,RECONNECTING,tls-error,,

    Fri Feb 21 11:53:01 2014 Restart pause, 2 second(s)

    Fri Feb 21 11:53:03 2014 WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).

    Fri Feb 21 11:53:03 2014 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

    Fri Feb 21 11:53:03 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]

    Fri Feb 21 11:53:03 2014 MANAGEMENT: >STATE:1392979983,RESOLVE,,,

    Fri Feb 21 11:53:03 2014 UDPv4 link local: [undef]

    Fri Feb 21 11:53:03 2014 UDPv4 link remote: [AF_INET]*.*.*.*:1194

    Fri Feb 21 11:53:03 2014 MANAGEMENT: >STATE:1392979983,WAIT,,,


    Hope this helps.

    Kind Regards

    TheExpert

    Kind Regards

    TheExpert

  • 0
    Hm, nothing to see here. Looks like the packets don't reach the peers.

    Could you fire up a Networkanalyzer tool like tcpdump or wireshark. Check if UDP/1194 is received and transmitted on both machines after you start the connection. That way you can see in which direction the packet are lost if they are.
  • 0 in reply to d12fk
    Hello d12fk,

    I can use wireshark on the client system, but how can I track the data packets on the Sophos UTM?

    There are no answer packets from the Sophos UTM on the client system.

    Kind Regards

    TheExpert

    Kind Regards

    TheExpert

  • 0
    Hello d12fk,

    it seems that the policy based routing isn't working anymore as it worked before. I had configured the ipv4 default gateway to the internal interface. And so I set up a policy based routing which routes all external traffic through the external gateway. This worked for a while but since the update of the beginning of february there must be change of the behavior of policy based routing.

    Now I set the default gateway to the external Interface and a standard static route to the internal networks with the internal gateway. This workaround solved the issue.

    Kind Regards

    TheExpert

    Kind Regards

    TheExpert

  • 0
    Our policy routing guy will look into this on Monday.
  • 0 in reply to d12fk
    Hello d12fk,

    are there any news for policy based routing?

    I solved the issue by moving the default gateway to the external interface and setting a static route for the internal networks behind the checkpoint firewall.

    But it would be very interesting what changed with policy based routing.

    Thank you

    TheExpert

    Kind Regards

    TheExpert

  • 0 in reply to TheExpert
    Hello d12fk,

    are there any news regarding policy based routing?

    Thank you

    TheExpert

    Kind Regards

    TheExpert

  • 0 in reply to d12fk
    Hello d12fk,

    are there now any news regarding policy based routing?

    Thank you

    TheExpert

    Kind Regards

    TheExpert

Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?