Hi,
I have one question:
a SG 430 9.705-3 is connected to multiple other SGs via IPSec.
Today I just put in a new Network in the tunnel config of lets say HQ to Site A
The tunnel came up again but was extremely unstable - high packet loss - in fact unuseable.
On the HQ SG I looked in IPSec log for Site A and found nothing suspicious.
Then I noticed massive log flooding for site B and from the beginning of the change of site A over 900.000 - nearly a million (!) of log events like this were logged within 25 minutes:
Logs HQ to site B:
2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum 2020:11:13-17:36:45 HQ-SG-1 pluto[8732]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500
The problem is, that this logs belong to VPN HQ to site B, not HQ to site A where I made the changes.
Then on HQ SG I disabled the tunnel HQ to site B and site A came back to life again.
Then I reactivated site B and it came back online fine and A and B remained OK and the logs entries did not come back.
Logs site B to HQ:
2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: sending notification INVALID_MAJOR_VERSION to HQ-SG-gateway-IP:500 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: sending notification INVALID_MAJOR_VERSION to HQ-SG-gateway-IP:500 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: sending notification INVALID_MAJOR_VERSION to HQ-SG-gateway-IP:500 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: sending notification INVALID_MAJOR_VERSION to HQ-SG-gateway-IP:500 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: sending notification INVALID_MAJOR_VERSION to HQ-SG-gateway-IP:500 2020:11:13-17:36:45 site-b-1 pluto[7109]: packet from HQ-SG-gateway-IP:500: ISAKMP version of ISAKMP Message has an unknown value: 0
I've noticed it now for the second time.
What does this logs mean?
ISAKMP version of ISAKMP Message has an unknown value
sending notification INVALID_MAJOR_VERSION
length of ISAKMP Message is smaller than minimum
sending notification PAYLOAD_MALFORMED
Hello LHerzog,
Thank you for contacting the Sophos Community! Try setting both sides to 1420.
For the Site A the length might be an issue with MTU.
Which would take you to the errors on Site B.
Regards,
Based on Emmanuel's answer, I wonder if you have selected 'Support path MTU discovery' in the Remote Gateway definitions.
Cheers - Bob
Hello LHerzog,
AFAIK remote side should initiate the connection.
You should follow Bob's advice to check "Support path MTU discovery" on all connections.
Alternatively, you could test for maximum MTU size of your connection and the define an adequate MTU for that particular interface.
Mit freundlichem Gruß, best regards from Germany,
Philipp Rusch
New Vision GmbH, Germany
Sophos Silver-Partner
If a post solves your question please use the 'Verify Answer' button.
All three answers pointed me to the right directon:
Besides wrong setting of initiate connection on both sides also MTU setting on the remote sides was also wrong with 1500. Correct value here was 1492 -> fixed
Reconnection was fine.
Then I also enabled path MTU detection. Will have to add something to a tunnel config after working hours to test the initially noticed behavior is gone.
Thanks for posting the result to help others!
In fact, IPsec tunnels can establish when both sides have '"Initiate connection" selected.
Cheers - Bob
issue happened again after modifiying, disabling and enabling the tunnel. massive ipsec log flood with these entries:
2021:01:27-23:52:43 fw-320-2 pluto[9352]: packet from site-B-gateway-IP:4500: sending notification PAYLOAD_MALFORMED to site-B-gateway-IP:4500
2021:01:27-23:52:43 fw-320-2 pluto[9352]: packet from site-B-gateway-IP:4500: length of ISAKMP Message is smaller than minimum
It were about 160k log lines between 23:52:43 and 23:55:30. So about 53k per minute.
I still have the settings enabled as written above.
I wrote on Nov. 16.:
Besides wrong setting of initiate connection on both sides also MTU setting on the remote sides was also wrong with 1500. Correct value here was 1492 -> fixed
Reconnection was fine.
Then I also enabled path MTU detection. Will have to add something to a tunnel config after working hours to test the initially noticed behavior is gone.
Ath that time a reconnection was fine. Now after some weeks running I added a new network object to the tunel and this caused the massive log flood and unstable tunnel. not only the log size explodes but performance goes down on the UTM.
I'd like to know what is causing the UTM to create all those messages - what do they mean and do they make sense?
PAYLOAD_MALFORMED
length of ISAKMP Message is smaller than minimum