Thread Info
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

Sophos Connect Clients randomly getting dropped off VPN

IT American Rock Salt

we have remote users using Sophos Connect Client connecting to a FW on 18.0.4 Mr-4 that are randomly disconnecting 

looking at the logs on the FW, we are seeing these messages

VPN-1 - IKE message retransmission timed out (Remote: 152.193.5.218)  and IKE_SA timed out before it could be established then maybe 30 seconds later the affected user's VPN session reestablishes and is connected again for some time

if i look at the logs from the andvanced shell

2021-02-11 15:20:30 24[CFG] <VPN-1|69> handling HA CHILD_SA VPN-1{190} 192.168.10.21/32 === 10.10.10.23/32 (segment in: 1*, out: 1*)
2021-02-11 15:20:30 24[IKE] <VPN-1|69> CHILD_SA VPN-1{190} established with SPIs c79cebe4_i ecdea2ac_o and TS 192.168.10.21/32 === 10.10.10.23/32
2021-02-11 15:20:30 24[IKE] <VPN-1|69> ### destroy: 0x7f23d40033b0
2021-02-11 15:20:31 15[NET] <VPN-1|174> received packet: from 68.238.193.46[54510] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:31 15[ENC] <VPN-1|174> parsed INFORMATIONAL_V1 request 354000927 [ HASH N(DPD) ]
2021-02-11 15:20:31 15[ENC] <VPN-1|174> generating INFORMATIONAL_V1 request 1474428525 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:31 15[NET] <VPN-1|174> sending packet: from 50.75.29.189[4500] to 68.238.193.46[54510] (108 bytes)
2021-02-11 15:20:36 15[IKE] <VPN-1|8> sending DPD request
2021-02-11 15:20:36 15[ENC] <VPN-1|8> generating INFORMATIONAL_V1 request 4032723093 [ HASH N(DPD) ]
2021-02-11 15:20:36 15[NET] <VPN-1|8> sending packet: from 50.75.29.189[4500] to 65.185.119.197[51583] (108 bytes)
2021-02-11 15:20:36 17[NET] <VPN-1|8> received packet: from 65.185.119.197[51583] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:36 17[ENC] <VPN-1|8> parsed INFORMATIONAL_V1 request 4144008415 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:39 23[NET] <VPN-1|5> received packet: from 75.149.20.190[58325] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:39 23[ENC] <VPN-1|5> parsed INFORMATIONAL_V1 request 3357301504 [ HASH N(DPD) ]
2021-02-11 15:20:39 23[ENC] <VPN-1|5> generating INFORMATIONAL_V1 request 2812308089 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:39 23[NET] <VPN-1|5> sending packet: from 50.75.29.189[4500] to 75.149.20.190[58325] (108 bytes)
2021-02-11 15:20:40 31[NET] <VPN-1|26> received packet: from 174.208.8.52[23927] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:40 31[ENC] <VPN-1|26> parsed INFORMATIONAL_V1 request 2301313461 [ HASH N(DPD) ]
2021-02-11 15:20:40 31[ENC] <VPN-1|26> generating INFORMATIONAL_V1 request 1470736063 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:40 31[NET] <VPN-1|26> sending packet: from 50.75.29.189[4500] to 174.208.8.52[23927] (108 bytes)
2021-02-11 15:20:42 18[IKE] <VPN-1|19> sending DPD request
2021-02-11 15:20:42 18[ENC] <VPN-1|19> generating INFORMATIONAL_V1 request 1126644735 [ HASH N(DPD) ]
2021-02-11 15:20:42 18[NET] <VPN-1|19> sending packet: from 50.75.29.189[4500] to 162.218.145.6[59018] (108 bytes)
2021-02-11 15:20:42 32[NET] <VPN-1|19> received packet: from 162.218.145.6[59018] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:42 32[ENC] <VPN-1|19> parsed INFORMATIONAL_V1 request 555344424 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:43 28[IKE] <Plainfield_New-1|33> sending DPD request
2021-02-11 15:20:43 28[ENC] <Plainfield_New-1|33> generating INFORMATIONAL_V1 request 2205122232 [ HASH N(DPD) ]
2021-02-11 15:20:43 28[NET] <Plainfield_New-1|33> sending packet: from 50.75.29.189[500] to 159.250.0.169[500] (108 bytes)
2021-02-11 15:20:43 14[NET] <Plainfield_New-1|33> received packet: from 159.250.0.169[500] to 50.75.29.189[500] (108 bytes)
2021-02-11 15:20:43 14[ENC] <Plainfield_New-1|33> parsed INFORMATIONAL_V1 request 178163176 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:45 24[IKE] <VPN-1|11> sending DPD request
2021-02-11 15:20:45 24[ENC] <VPN-1|11> generating INFORMATIONAL_V1 request 3982438688 [ HASH N(DPD) ]
2021-02-11 15:20:45 24[NET] <VPN-1|11> sending packet: from 50.75.29.189[4500] to 71.240.122.49[58339] (108 bytes)
2021-02-11 15:20:45 12[NET] <VPN-1|11> received packet: from 71.240.122.49[58339] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:45 12[ENC] <VPN-1|11> parsed INFORMATIONAL_V1 request 3174936446 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:45 27[NET] <VPN-1|69> received packet: from 50.244.234.193[61678] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:45 27[ENC] <VPN-1|69> parsed INFORMATIONAL_V1 request 1966289005 [ HASH N(DPD) ]
2021-02-11 15:20:45 27[ENC] <VPN-1|69> generating INFORMATIONAL_V1 request 1986081584 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:45 27[NET] <VPN-1|69> sending packet: from 50.75.29.189[4500] to 50.244.234.193[61678] (108 bytes)
2021-02-11 15:20:46 05[NET] <VPN-1|174> received packet: from 68.238.193.46[54510] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:46 05[ENC] <VPN-1|174> parsed INFORMATIONAL_V1 request 123858907 [ HASH N(DPD) ]
2021-02-11 15:20:46 05[ENC] <VPN-1|174> generating INFORMATIONAL_V1 request 3312036097 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:46 05[NET] <VPN-1|174> sending packet: from 50.75.29.189[4500] to 68.238.193.46[54510] (108 bytes)
2021-02-11 15:20:54 13[NET] <VPN-1|5> received packet: from 75.149.20.190[58325] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:54 13[ENC] <VPN-1|5> parsed INFORMATIONAL_V1 request 1036310299 [ HASH N(DPD) ]
2021-02-11 15:20:54 13[ENC] <VPN-1|5> generating INFORMATIONAL_V1 request 1595646099 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:54 13[NET] <VPN-1|5> sending packet: from 50.75.29.189[4500] to 75.149.20.190[58325] (108 bytes)
2021-02-11 15:20:55 31[NET] <VPN-1|26> received packet: from 174.208.8.52[23927] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:55 31[ENC] <VPN-1|26> parsed INFORMATIONAL_V1 request 926039491 [ HASH N(DPD) ]
2021-02-11 15:20:55 31[ENC] <VPN-1|26> generating INFORMATIONAL_V1 request 2104519849 [ HASH N(DPD_ACK) ]
2021-02-11 15:20:55 31[NET] <VPN-1|26> sending packet: from 50.75.29.189[4500] to 174.208.8.52[23927] (108 bytes)
2021-02-11 15:20:55 05[IKE] <VPN-1|23> sending DPD request
2021-02-11 15:20:55 05[ENC] <VPN-1|23> generating INFORMATIONAL_V1 request 1483352352 [ HASH N(DPD) ]
2021-02-11 15:20:55 05[NET] <VPN-1|23> sending packet: from 50.75.29.189[4500] to 164.52.230.194[50517] (108 bytes)
2021-02-11 15:20:55 09[NET] <VPN-1|23> received packet: from 164.52.230.194[50517] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:20:55 09[ENC] <VPN-1|23> parsed INFORMATIONAL_V1 request 1971663142 [ HASH N(DPD_ACK) ]
2021-02-11 15:21:00 31[NET] <VPN-1|69> received packet: from 50.244.234.193[61678] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:21:00 31[ENC] <VPN-1|69> parsed INFORMATIONAL_V1 request 3461046038 [ HASH N(DPD) ]
2021-02-11 15:21:00 31[ENC] <VPN-1|69> generating INFORMATIONAL_V1 request 3064966082 [ HASH N(DPD_ACK) ]
2021-02-11 15:21:00 31[NET] <VPN-1|69> sending packet: from 50.75.29.189[4500] to 50.244.234.193[61678] (108 bytes)
2021-02-11 15:21:01 05[NET] <VPN-1|174> received packet: from 68.238.193.46[54510] to 50.75.29.189[4500] (108 bytes)
2021-02-11 15:21:01 05[ENC] <VPN-1|174> parsed INFORMATIONAL_V1 request 1478452648 [ HASH N(DPD) ]
2021-02-11 15:21:01 05[ENC] <VPN-1|174> generating INFORMATIONAL_V1 request 1744343798 [ HASH N(DPD_ACK) ]
2021-02-11 15:21:01 05[NET] <VPN-1|174> sending packet: from 50.75.29.189[4500] to 68.238.193.46[54510] (108 bytes)

it appears that its sending DPD checks every 30 seconds 

my question is what IPSEC policy does Sophos Connect clients use on the FW under VPN when the clients connect? any insight into how we can resolve these random disconnects



This thread was automatically locked due to age.
  • 0

    Hello there,

    Thank you for contacting the Sophos Community!

    Sophos Connect used the Default Remote Access policy, the IKE for this is 4-5 hours. Since this is IKEv1 it won't recreate a key to connect unlike with IKEv2 (this is to be fixed in a future release) in any case if the disconnections happen after this 4-5 hours, then it would be possible to increase the Key Life time.

    Do you happen to know if this reconnection happens after 4-5 hours?

    Do you also have any site-to-site IPsec tunnel? If so try running this command from the console of the XG (5>4) 

    console> set vpn conn-remove-tunnel-up disable

    Regards.

     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
    • 0 in reply to emmosophos

      not sure if the reconnect is happening every 4-5 hours. we believe it was happening more frequently than that for some users it may happen as often as every 30 mins or so. The weird thing is I don't think the user even sees that Sophos connect has dropped or is reconnecting as it shows the green check mark over the icon the whole time I believe. 

      looking at the Default Remote Access IPsec Policy the default values I believe are selected and we did not change anything with this policy

      the phase 1 key life is 18000 seconds of 5 hours, in phase 2 the key life is 3600 seconds or 1 hour, dead peer detection is set to check every min wait for 4 mins and if no response then disconnect. 

      the user connections should be sending some data over the tunnel at all times to ensure that DPD isn't kicking in but without seeing a running packet capture its hard to say.

      I don't know if there are some IPSsec bugs in V18.0.4 -MR4 we recently upgraded from 17.5.12 were we didn't see these issues, my assumption that any and all settings we had in the previous build would carry over but i don't know if the changes in 18 under the hood would cause these sporadic issues

      we do have a site to site running between another location and our main datacenter

      will running that console command drop existing tunnel connections?

      • 0 in reply to emmosophos

        Are you telling here that the tunnel needs to be reauthenticated after the key expires?Could the reason for interrupting the connection be the 2 factor Authentication then?

        wiki.strongswan.org/.../ExpiryRekey
        In comparison to IKEv1, which only supports reauthentication (see below), IKEv2 provides proper inline rekeying of IKE SAs by use of CREATE_CHILD_SA exchanges. This means that new keys may be established without any interruption of the existing IKE and IPsec SAs.

        We are seeing such kinds of issues on SSL-VPN and V18 MR-4 as well.

        There is definitely a need for unlimited VPN connections without interruption and as far as I understand extending the key lifetime is always a security risk.

        Is this a matter off week implementation (in case of SSL-VPN and Sophos Connect or a technical issue with 2 factor authentication.

        • 0 in reply to BeEf

          we do not use 2FA for this VPN tunnel. we do for other Sophos connect tunnels

          what appears to be happening is users are losing their remote desktop sessions or printing from within the session stops working

          the connect client appears that it doesn't lose connection as the icon has the green check mark the whole time I believe. 

          in the FW system logs we see errors like these 

          VPN-1 - IKE message retransmission timed out (Remote: 72.35.228.189)

          VPN-1 - IPSec Connection VPN-1 between 72.35.228.189 and 50.75.29.189 for Child VPN-1 terminated. (Remote: 72.35.228.189)

          we have a support case open and am awaiting a tech to look at this but my question is in the meantime will running this command

          console> set vpn conn-remove-tunnel-up disable drop existing connections

          • 0 in reply to IT American Rock Salt

            Is it possible to use IKE2? Then I'd give it a try (see my quote above).

            • 0 in reply to BeEf

              certainly, however I assume if we change the policy to use IKE2 in real time it will require all users to reconnect or does that change only affect new sessions 

              • 0 in reply to BeEf

                IKEv2 is not available for XG Firewall. There are roadmap items to implement this into the future release. 

                There are plans to workaround this whole issue about MFA. Simply by rekey and not forcing to renewal the OTP. 

                Another workaround would be to change the IKE lifetime. There are theoretical security issues but 4-8 hours seems fine to me. 

                BTW: Sophos is working on the future of those scenarios. ZTNA will likely be a challenger to VPN. 

                https://partnernews.sophos.com/en-us/2020/12/products/sophos-zero-trust-network-access-ztna-is-coming-soon-your-faq/

                __________________________________________________________________________________________________________________

                • 0 in reply to LuCar Toni

                  Hello Sir,

                  can you tell me whether or not I can change the rekey times in the DefaultRemoteAccess Policy or do I have to change something on my Clients?

                  We use MFA aswell and all our Remote Worker get disconnected every 4-5 hours. Our reseller told us that it would be necessary to change something on cli level.

                  If not, is there an ETA for a workaround?

                  Greetings and a nice Weekend!

                  • 0 in reply to D Goese

                    Sophos Support can adjust this timeout, as far as i know. Its not a config change on the GUI level yet. So you cannot change it.

                    After the change, you need to reapply all policies to your users. 

                    __________________________________________________________________________________________________________________

                    • 0 in reply to LuCar Toni

                      if IKEV2 is not available on Sophos XG then why does it show up as an option in the VPN policies for Key exchange?

                  Unfiltered HTML