Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 3093 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

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.
Parents
  • 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.

  • 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!

Reply
  • 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!

Children