Remote Access IPSec VPN disconnects

Hi

I'm not sure if it helps, however we saw similar behaviour for some of our users who connect to our UTM's for Remote Access via IPSEC. In our case, we tracked the issue down to a mismatch between the SA lifetimes configured on the UTM vs the lifetimes configured within the Sophos IPSEC client. Our UTM used the default values of 7800/3600s whereas our clients were configured to use 1 day/8 hours (aka 86400/28800s).

Once we adjusted these values to be the same number, the disconnect problem went away.

Cheers
Steve

We downloaded the configs from the User Portal soon after the VPN was set up so the configs matched.  We then imported the configs into the IPSec client. Also verified these settings matched as well.  One thing that I did notice is that when we start up our client machines, the very first time that we try to connect to the VPN it always fails.  All others connection attempts afterward succeed.  When the client machine is rebooted, the same thing happens – the first connection try fails and then all after succeed. 

When the first connection fails the Sophos UTM IPSec log shows an error:

hostname pluto[30292]: ERROR: asynchronous network error report on eth0 for message to 36.X.X.X port 10954, complainant 192.168.250.1: Message too long [errno 90, origin ICMP type 3 code 4 (not authenticated)]

So if I try to connect again it works, but what I noticed is that the same message error also shows again right before the VPN disconnects at the end of the IKE SA lifetime:

hostname pluto[30292]: ERROR: asynchronous network error report on eth0 for message to 36.X.X.X port 10954, complainant 192.168.250.1: Message too long [errno 90, origin ICMP type 3 code 4 (not authenticated)]

I wonder if this is the issue.

I'm not a networking expert, however that sounds to me like you've got an issue with your MTU settings on your network. If this is the case, i'm not quite sure why the second connection would work where the first did not, however the "Message too long" error is usually symptomatic of a packet that exceeds the network's allowed packet size.

I'll try a WAG - does the client have DPD enabled?  If that wasn't the problem, please disable the IPsec Remote Access rule and power cycle the client.  When the client is ready to connect, start the IPsec Live Log and then have the client try to connect after the Live Log shows a few lines.  Show us the lines up to and including the ERROR above.

Cheers - Bob

I apologize for just getting back to this.

Stephen, our Sophos UTM is an instance within AWS and the IP on the interface is dynamic.  The MTU that populates with the dynamic IP is 9001.  If I try to change it to 1500, for example, it will just change itself back to 9001.

BAlfson, I also thought that DPD might be causing the issue.  Yes it is enabled on the UTM and also on the client, but I made some changes elsewhere that really seem to improve the VPN uptime.

I tested uptime using the below setting and the VPN, and the client machine connected RDP sessions, stayed up for 18+ hours.  I then manually disconnected the VPN because I really only need the VPN to stay up for a max of about 12-14 hours.  I know that I set the IKE SA lifetime a to 1 day, but at least it is staying up vs. disconnecting after 7800 seconds.  I have read a lot and many say that that the best practice setting for the IKE SA lifetime is 86400 in reference to site-to-site IPsec VPNs, but I really haven't seen anything different in terms of best practice for remote access IPSec VPN.

Policy:
IKE SA lifetime - 86400 (this was originally 7800)
IPsec SA lifetime - 3600 (no change)
PFS - off/not used (this was originally enabled)
Strict policy - checked
Compression - checked (this was originally unchecked)

Hi BAlfson, I should have posted the log.  The connection attempt always fails on the first try.

2017:10:12-22:33:13 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10952 #1: responding to Main Mode from unknown peer 34.X.X.X:10952
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10952 #1: NAT-Traversal: Result using RFC 3947: both are NATed
2017:10:12-22:33:14 hostname pluto[9428]: | NAT-T: new mapping 34.X.X.X:10952/10954)
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: Peer ID is ID_USER_FQDN: '[email address]'
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: crl not found
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: certificate status unknown
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: deleting connection "D_IPSEC-VPN-4"[1] instance with peer 34.X.X.X {isakmp=#0/ipsec=#0}
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: we have a cert and are sending it
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: Dead Peer Detection (RFC 3706) enabled
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: sent MR3, ISAKMP SA established
2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: sending XAUTH request
2017:10:12-22:33:14 hostname pluto[9428]: ERROR: asynchronous network error report on eth0 for message to 34.X.X.X port 10954, complainant 10.63.20.1: Message too long [errno 90, origin ICMP type 3 code 4 (not authenticated)]
2017:10:12-22:33:23 hostname pluto[9428]: packet from 34.X.X.X:10954: Main Mode message is part of an unknown exchange
2017:10:12-22:33:27 hostname pluto[9428]: packet from 34.X.X.X:10954: Main Mode message is part of an unknown exchange
2017:10:12-22:33:31 hostname pluto[9428]: packet from 34.X.X.X:10954: Main Mode message is part of an unknown exchange
2017:10:12-22:33:35 hostname pluto[9428]: packet from 34.X.X.X:10954: Informational Exchange is for an unknown (expired?) SA
2017:10:12-22:34:24 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954 #1: max number of retransmissions (2) reached STATE_XAUTH_R1
2017:10:12-22:34:24 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10954: deleting connection "D_IPSEC-VPN-4"[1] instance with peer 34.X.X.X {isakmp=#0/ipsec=#0}

Isn't this a different issue than before?  Then, the client connected, but did not reconnect after the IKE SA Lifetime expired.  Here, there's no initial connection.  The only thing that jumps out at me is:

2017:10:12-22:33:14 hostname pluto[9428]: "D_IPSEC-VPN-4"[1] 34.X.X.X:10952 #1: NAT-Traversal: Result using RFC 3947: both are NATed

Is the UTM is behind a NAT?  If so, you will have challenges with IPsec.  The only way this might work is with a preshared key.  On the 'Advanced' tab, select 'Enable probing of preshared keys', 'VPN ID type: IP address' and put the public IP in 'VPN ID' instead of letting the IPsec server "sign" packets by default with the private IP of "External (Address)'.  Did that work for you?

Cheers - Bob

BAlfson,

There were two issues, but the main one being that the VPN disconnects after the IKE lifetime expired.  The other issue was that the first connection attempt would fail, but the one after would succeed.

As for the VPN disconnecting after the IKE lifetime expired – I think I may have solved this by using compression and changing the IKE SA lifetime from 7800 to 86400 for the remote access VPN.

This part of it was about the first connection attempt failing.

Yes, the Sophos UTM is in an AWS VPC and the clients are behind a NAT.  It looks like you are right about the NAT issue and certificates + XAUTH.  I set up a test IPSec VPN using PSK, XAUTH, and the settings you mentioned on the Advanced tab.  I also put the public IP in the Sophos IPSec client (Identities – Local Identity (IKE) Type: IP Address and ID: the public IP address) and it connects on the first try and I can connect to the servers.

I set up another test, just to see, of setting up a VPN that required the certificate only (XAUTH unchecked) and updated the client configuration and it connects on the first try.  I then put a check in the XAUTH checkbox and then updated the client configuration and it started to fail on the first connection attempt, but then would connect on the second try.

I do have 2 more questions for you:

I would rather use certificates instead of PSK, but certificates + XAUTH seem to be causing the first connection attempt to fail.  I read one of your other posts at https://community.sophos.com/products/unified-threat-management/f/network-protection-firewall-nat-qos-ips/41016/determine-pre-shared-key , but it has more to do with a site-to-site VPN (see your last post on that page).  Do you have the same security thoughts about using certificates + XAUTH instead of PSK + XAUTH for remote access VPNs?

When using IPSec with certificates + XAUTH, the only issues seem to be that the VPN connection disconnects after the IKE lifetime expired and the first connection attempt fails, but do you think that the NAT issue could be the reason that the VPN connection disconnects after the IKE lifetime expired?

I always prefer certs, so with AWS, I prefer SSL VPN Remote Access.  For an X509 site-to-site IPsec tunnel between an instance in AWS and a UTM with a public IP, configure the AWS instance with an "Initiate connection" and the UTM with a "Respond only" Remote Gateway.

Cheers - Bob

BAlfson,

Thank you.