Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 27 subscribers
  • Views 15743 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

XG16 - SSL VPN remote access won't connect

JeffThompson

Hi folks,

I'm stumped by the SSL VPN (remote access, not site-to-site) on my XG16 firewall. I've set it up, I think correctly, but the clients on both PC and Android stall just after verifying the certificate and fail to connect.  There's absolutely nil in the XG logs, in spite of the VPN settings having "debug mode" turned on!

Anyone have any ideas?

 

Typical client log reads like this:

Resolve address - ok (gets the public IP of the XG box)

Contacting via UDP

Wait

Connecting via UDPv4

Tunnel options V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES256-CBC,auth SHA512,keysize 256,key-method 2,tls-client

Creds: Username/Password

Peer info: <version info etc of client>

Verify OK: depth=1

<certificate details for the root cert>

Verify OK: depth=0

<certificate details for my GeoTrust-issued cert on the XG box>

... 30 seconds or so go by...

EVENT: CONNECTION_TIMEOUT

EVENT: DISCONNECTED

----OpenVPN Stop----

 

The Android client is OpenVPN Connect with the OVPN file downloaded from XG's user portal; the Windows client is downloaded entirely from the user portal.

As I said, el zippo in the XG logs - no sign of firewall blocking anything, no IPS squeaks, nothing in the system log about VPN.

 

User config:

 

VPN config:

Device access:

 

I haven't posted the firewall rules, as I don't think we're getting that far.  There is one allowing traffic from the VPN subnet to some of the LAN subnets.

 

Any ideas appreciated!

Thanks,


Jeff



This thread was automatically locked due to age.
  • 0

    Jess,

    did you try to use the XG appliance certificate? Did you try to restart the VPN Service from console?

    Thanks

  • 0 in reply to lferrara

    I've been trying this over a period of weeks, so I've not only restarted the service but updated and rebooted the whole firewall along the way.  Problem's the same.

    The appliance certificate?  Interesting, that one - it's not available on the VPN's cert list.  When I look it up in the certificate admin page, it's marked with a cross to say it has no chain of authority!  I guess that's another problem I need to look at now :-(  Not that I really ought to need it...

    Why would I use a self-signed Sophos cert rather than the properly-certified certificate that I have for the domain?  Seems counter-intuitive and weaker security!  If you're saying Sophos can't work the VPN with imported certs then that's got to be a bug.  I can't believe big users wouldn't have already made a load of noise about that.

     

    Jeff

  • 0 in reply to JeffThompson

    Ok, so I gave it a try... regenerated the appliance CA and certificate and now I can choose it for the VPN.  Doesn't work, though!

    Here's the Windows client log file:

    Fri Jun 09 20:43:17 2017 OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Dec  9 2016
    Fri Jun 09 20:43:17 2017 library versions: OpenSSL 1.0.1u  22 Sep 2016, LZO 2.09
    Fri Jun 09 20:43:17 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
    Fri Jun 09 20:43:17 2017 Need hold release from management interface, waiting...
    Fri Jun 09 20:43:17 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
    Fri Jun 09 20:43:17 2017 MANAGEMENT: CMD 'state on'
    Fri Jun 09 20:43:17 2017 MANAGEMENT: CMD 'log all on'
    Fri Jun 09 20:43:17 2017 MANAGEMENT: CMD 'hold off'
    Fri Jun 09 20:43:17 2017 MANAGEMENT: CMD 'hold release'
    Fri Jun 09 20:43:27 2017 MANAGEMENT: CMD 'username "Auth" "jeff"'
    Fri Jun 09 20:43:27 2017 MANAGEMENT: CMD 'password [...]'
    Fri Jun 09 20:43:28 2017 Socket Buffers: R=[65536->65536] S=[65536->65536]
    Fri Jun 09 20:43:28 2017 MANAGEMENT: >STATE:1497037408,RESOLVE,,,,,,
    Fri Jun 09 20:43:28 2017 UDPv4 link local: [undef]
    Fri Jun 09 20:43:28 2017 UDPv4 link remote: [AF_INET]80.229.138.223:8443
    Fri Jun 09 20:43:28 2017 MANAGEMENT: >STATE:1497037408,WAIT,,,,,,
    Fri Jun 09 20:43:28 2017 MANAGEMENT: >STATE:1497037408,AUTH,,,,,,
    Fri Jun 09 20:43:28 2017 TLS: Initial packet from [AF_INET]80.229.***.***:8443, sid=d304c184 3229e2a2
    Fri Jun 09 20:43:28 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
    Fri Jun 09 20:43:28 2017 VERIFY OK: depth=1, C=GB, ST=Oxfordshire, L=Abingdon, O=Sophos, OU=OU, CN=Sophos_CA, emailAddress=support@sophos.com
    Fri Jun 09 20:43:28 2017 VERIFY X509NAME OK: C=GB, ST=NA, L=NA, O=---, OU=OU, CN=SophosApplianceCertificate_C01001TMP3DVR03, emailAddress=jeff@****
    Fri Jun 09 20:43:28 2017 VERIFY OK: depth=0, C=GB, ST=NA, L=NA, O=---, OU=OU, CN=SophosApplianceCertificate_C01001TMP3DVR03, emailAddress=jeff@****

    Fri Jun 09 20:45:30 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    Fri Jun 09 20:45:30 2017 TLS Error: TLS handshake failed
    Fri Jun 09 20:45:30 2017 SIGUSR1[soft,tls-error] received, process restarting

    Same as with my real cert, gets stuck after checking the certificate.  What would stop it making the TLS connection?  That's basic comms stuff.

  • +2 in reply to JeffThompson

    Looking at the XG advanced logs, the problem was Default CA. Changing one CA field and regenerating the Appliance certificate did the trick.

  • 0 in reply to lferrara

    Grazie mille, Luk!  Really appreciate your help there, it had me stumped.  Now I know where to find the real logs too, which is way more useful than the log viewer in the GUI :-)

     

    A couple of interesting notes - (1) I'd regenerated that Sophos CA cert earlier in the evening, but without changing any of the fields, so it was you changing a field that made the difference; and (2) I just changed the VPN settings back to use my domain certificate to see what happened... and it's working beautifully!  Now that is strange. Maybe the issue wasn't only the cert but also something else that was fixed by the process of you changing the cert...