Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 19 replies
  • Subscribers 31 subscribers
  • Views 37026 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN Stopped Working - SFOS 16.05.1 MR-1

ShawnGilronan

I recently updated my Sophos XG Firewall to the latest firmware SFOS 16.05.1 MR-1 from v15.  After updating, I noticed my SSL VPN stopped working.  After trying everything I could read to get it to work, I started from scratch, and recreated the SSL VPN, following the guide published here:  https://community.sophos.com/products/xg-firewall/f/vpn/86979/i-need-instructions-step-by-step-setting-up-xg-105-ssl-vpn-remote-access

 

After having everything setup as per the guide, each time I try and connect, I get the same error: 

tls error: tls key negotiation failed to occur within 60 seconds.

 

I have tried both the Sophos SSL client, as well as SecurePoint SSL, and receive the same issue when trying to connect over UDP.

I'm not sure what to try next.

Thanks,

Shawn



This thread was automatically locked due to age.
  • 0 in reply to ShawnGilronan

    What rules do you have? For mine to work, I have the following;

    Rule #1

    Source: VPN

    Any Service

    Dest: LAN

    Enable MASQ

     

     

    Rule #2

    Source: LAN

    Any Service

    Dest: VPN

     

     

    Also, in the remote access config, for permitted resources I had to manually make a definition for the LAN, rather than just use "port1"

  • 0 in reply to MattColford

    My rules appear to match yours exactly.

     

    Rule #1:

     

    Rule #2

  • 0 in reply to ShawnGilronan

    Try disabling "match known users". Also does your SSL VPN profile have the network as a definition or just the port/bridge?

  • 0 in reply to MattColford

    I'll try disabling known users.  I have created a profile for #Port1, that I called Main_lan.

  • 0 in reply to ShawnGilronan

    Update,

    Still not working.  However, if I try to connect to my VPN from inside my network, i get the same failed error message of a TLS timeout on UDP when it tries to connect to my external IP.

    However, if I try and have it join internally to my 192.168.1.1:8443 address, it connects no problem.  

    Somehow, my external IP is blocking the connection???

  • 0 in reply to ShawnGilronan

    From the advanced shell you can issue the drppkt command to see if the firewall is blocking something.

    for example:

    "drppkt host 192.168.203.2" will filter on the host

    "drppkt 192.168.203.2 and port 389" will filter on the host and port.

    FWIW I cannot get SSL VPN working on UDP.  Tech support is throwing back to development.  TCP ports (most of the time).

  • 0 in reply to MattLinzbach

    I'm convinced either Time Warner (spectrum) is blocking the default VPN SSL port, or something else is causing the packets to not get through to my Sophos XG router.

    I'm going to download Wireshark and see if I can trace the packets that way.

  • 0
    Hi,
     
    You recreated the certificate after the firmware update?
     
    I had a similar issue and solved with the following actions:
     
    - Delete all user certificates;
    - Regenerate the XG certificate;
    - On the console, run the command "show vpn IPSec-logs" (it gives a certificate loading error the first time) twice; This helped ;-)
    - Create a new certificate for users through the portal.
     
    Hope this helps
     
     
     
  • 0 in reply to ShawnGilronan

    Hi all,

     

    I am experiencing a similar problem but slightly different. I am able to start the VPN on both windows10 (used windows vpn, sophos client, and openvpn client) and on TunnelBlick on a MAC and iot produces the error on both. The process seems to go all the way to authentication on the AD side (even local on the Sophos XG) and the VPN services authenticates and when it sends back the data to the client to connect the client then suddenly terminates the connection and restarts then process over again. Happens with any client/system. results same.

     

    Here is some log detail:

    The IP is made up to protect the names of the innocent......

     

    As you can see it looks like it just goes into a loop. Watching the interfaces on both the Sopgos XG and my end user (via a dump) I can see the VPN server is sending back an authentication response but client still resets and re-loops.

    This was working before and I even regressed the Sophos firmware thinking the last upgrade was an issue but it didn't matter. I am using the latest version of firmware.

     


    2019-04-25 20:06:35.759297 *Tunnelblick: macOS 10.14.4; Tunnelblick 3.7.9beta06 (build 5250); prior version 3.7.9beta05 (build 5240)
    2019-04-25 20:06:36.084795 *Tunnelblick: Attempting connection with cpettit@encase.com__ssl_vpn_config; Set nameserver = 769; monitoring connection
    2019-04-25 20:06:36.085537 *Tunnelblick: openvpnstart start cpettit@encase.com__ssl_vpn_config.tblk 64586 769 0 3 0 1065264 -ptADGNWradsgnw 2.4.7-openssl-1.0.2r
    2019-04-25 20:06:36.153168 *Tunnelblick: openvpnstart starting OpenVPN
    2019-04-25 20:06:36.315986 OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Apr 25 2019
    2019-04-25 20:06:36.316075 library versions: OpenSSL 1.0.2r 26 Feb 2019, LZO 2.10
    2019-04-25 20:06:36.317770 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:64586
    2019-04-25 20:06:36.317820 Need hold release from management interface, waiting...
    2019-04-25 20:06:36.708512 *Tunnelblick: openvpnstart log:
    OpenVPN started successfully.
    Command used to start OpenVPN (one argument per displayed line):
    /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.7-openssl-1.0.2r/openvpn
    --daemon
    --log /Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Scpettit@encase.com__ssl_vpn_config.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_0_1065264.64586.openvpn.log
    --cd /Library/Application Support/Tunnelblick/Shared/cpettit@encase.com__ssl_vpn_config.tblk/Contents/Resources
    --machine-readable-output
    --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5250 3.7.9beta06 (build 5250)"
    --verb 3
    --config /Library/Application Support/Tunnelblick/Shared/cpettit@encase.com__ssl_vpn_config.tblk/Contents/Resources/config.ovpn
    --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Shared/cpettit@encase.com__ssl_vpn_config.tblk/Contents/Resources
    --verb 3
    --cd /Library/Application Support/Tunnelblick/Shared/cpettit@encase.com__ssl_vpn_config.tblk/Contents/Resources
    --management 127.0.0.1 64586 /Library/Application Support/Tunnelblick/iopflaoeeabphfjhhfdgnghdhfagcchpnbadmchd.mip
    --management-query-passwords
    --management-hold
    --script-security 2
    --up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
    --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
    2019-04-25 20:06:36.722088 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:64586
    2019-04-25 20:06:36.768073 MANAGEMENT: CMD 'pid'
    2019-04-25 20:06:36.768181 MANAGEMENT: CMD 'auth-retry interact'
    2019-04-25 20:06:36.768222 MANAGEMENT: CMD 'state on'
    2019-04-25 20:06:36.768293 MANAGEMENT: CMD 'state'
    2019-04-25 20:06:36.768360 MANAGEMENT: CMD 'bytecount 1'
    2019-04-25 20:06:36.776395 *Tunnelblick: Established communication with OpenVPN
    2019-04-25 20:06:36.790933 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
    2019-04-25 20:06:36.792439 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:46.272877 MANAGEMENT: CMD 'username "Auth" "cpettit"'
    2019-04-25 20:06:46.272963 MANAGEMENT: CMD 'password [...]'
    2019-04-25 20:06:46.275574 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    2019-04-25 20:06:46.290287 TCP/UDP: Preserving recently used remote address: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:46.290372 Socket Buffers: R=[131072->131072] S=[131072->131072]
    2019-04-25 20:06:46.290390 Attempting to establish TCP connection with [AF_INET]204.204.204.204:8443 [nonblock]
    2019-04-25 20:06:46.290404 MANAGEMENT: >STATE:1556237206,TCP_CONNECT,,,,,,
    2019-04-25 20:06:47.362357 TCP connection established with [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:47.362409 TCP_CLIENT link local: (not bound)
    2019-04-25 20:06:47.362427 TCP_CLIENT link remote: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:47.362506 MANAGEMENT: >STATE:1556237207,WAIT,,,,,,
    2019-04-25 20:06:47.422094 MANAGEMENT: >STATE:1556237207,AUTH,,,,,,
    2019-04-25 20:06:47.422223 TLS: Initial packet from [AF_INET]204.204.204.204:8443, sid=dc325532 ac63c5f0
    2019-04-25 20:06:47.422997 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    2019-04-25 20:06:47.465073 Connection reset, restarting [-1]
    2019-04-25 20:06:47.465281 SIGUSR1[soft,connection-reset] received, process restarting
    2019-04-25 20:06:47.465327 MANAGEMENT: >STATE:1556237207,RECONNECTING,connection-reset,,,,,
    2019-04-25 20:06:47.469489 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:47.469547 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    2019-04-25 20:06:47.469707 TCP/UDP: Preserving recently used remote address: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:47.469762 Socket Buffers: R=[131072->131072] S=[131072->131072]
    2019-04-25 20:06:47.469791 Attempting to establish TCP connection with [AF_INET]204.204.204.204:8443 [nonblock]
    2019-04-25 20:06:47.469824 MANAGEMENT: >STATE:1556237207,TCP_CONNECT,,,,,,
    2019-04-25 20:06:47.469987 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:48.539963 TCP connection established with [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:48.540023 TCP_CLIENT link local: (not bound)
    2019-04-25 20:06:48.540094 TCP_CLIENT link remote: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:48.540164 MANAGEMENT: >STATE:1556237208,WAIT,,,,,,
    2019-04-25 20:06:48.585177 MANAGEMENT: >STATE:1556237208,AUTH,,,,,,
    2019-04-25 20:06:48.585297 TLS: Initial packet from [AF_INET]204.204.204.204:8443, sid=c76c4729 a6bb9548
    2019-04-25 20:06:48.635125 Connection reset, restarting [-1]
    2019-04-25 20:06:48.635287 SIGUSR1[soft,connection-reset] received, process restarting
    2019-04-25 20:06:48.635340 MANAGEMENT: >STATE:1556237208,RECONNECTING,connection-reset,,,,,
    2019-04-25 20:06:48.639089 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:48.639146 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    2019-04-25 20:06:48.639339 TCP/UDP: Preserving recently used remote address: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:48.639399 Socket Buffers: R=[131072->131072] S=[131072->131072]
    2019-04-25 20:06:48.639415 Attempting to establish TCP connection with [AF_INET]204.204.204.204:8443 [nonblock]
    2019-04-25 20:06:48.639430 MANAGEMENT: >STATE:1556237208,TCP_CONNECT,,,,,,
    2019-04-25 20:06:48.639596 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:49.708492 TCP connection established with [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:49.708986 TCP_CLIENT link local: (not bound)
    2019-04-25 20:06:49.709055 TCP_CLIENT link remote: [AF_INET]204.204.204.204:8443
    2019-04-25 20:06:49.709102 MANAGEMENT: >STATE:1556237209,WAIT,,,,,,
    2019-04-25 20:06:49.763140 MANAGEMENT: >STATE:1556237209,AUTH,,,,,,
    2019-04-25 20:06:49.763286 TLS: Initial packet from [AF_INET]204.204.204.204:8443, sid=1d7e2ea3 088e14d6
    2019-04-25 20:06:49.805421 Connection reset, restarting [-1]
    2019-04-25 20:06:49.805721 SIGUSR1[soft,connection-reset] received, process restarting
    2019-04-25 20:06:49.805748 MANAGEMENT: >STATE:1556237209,RECONNECTING,connection-reset,,,,,
    2019-04-25 20:06:49.809596 MANAGEMENT: CMD 'hold release'
    2019-04-25 20:06:49.809655 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

     

    I am sure someone has probably experienced this but this thread looks close to my issue.

     

    Thanks.

     

    Christopher Pettit

    XOR Security, LLC