We'd love to hear about it! Click here to go to the product suggestion community
We have various Sophos UTM SG models (230, 210, 125) across multiple sites with IPsec VPN tunnels back to our headquarters (SG230) and we randomly have issues where a VPN tunnel will drop and the only way to renegotiate the tunnel is the reboot UTM at the remote site, disabling/enabling the connection on either or both sides does not resolve the issue. We've been fortunate that we've been able to resolve the issue by rebooting the remote site and not our HQ UTM, but I'm dreading that day if/when that happens.
All sites are running the latest firmware, version 9.605-1, and the tunnels are configured "AES-256 PFS" policy, and the remote gateways are of type "initiate connection", with a VPN ID type of "IP Address" with no optional VPN ID set.
When this occurs the logs are not very helpful, here's the basic snippet that repeats over and over.
2019:09:04-10:35:00 connect-1 pluto: "S_REF_IpsSite_0" #163028: sending encrypted notification PAYLOAD_MALFORMED to xxx.xxx.xxx.xxx:500
2019:09:04-10:35:03 connect-1 pluto: "S_REF_IpsSite_0" #163028: next payload type of ISAKMP Identification Payload has an unknown value: 189
2019:09:04-10:35:03 connect-1 pluto: "S_REF_IpsSite_0" #163028: malformed payload in packet. Probable authentication failure (mismatch of preshared secrets?)
I figured I'd ask here before I open a case with support. Has anyone seen this behavior before?
Are these errors consistent every time?
Do you have different PSKs for your different IPSec tunnels at Headquarters? If so, please enable the option Enable probing of preshared keys in Site-to-site VPN > IPsec > Advanced | Preshared Key Settings.
Also carefully check the Policies on both sides.
Hi Darin and welcome back to the UTM Community!
Do you have DPD and NAT-T selected on the 'Advanced' tab everywhere? This feels more like you need to select 'Support path MTU discovery' in all Remote Gateway definitions - any better luck with that?
Cheers - Bob