Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 11 replies
  • Answers 4 answers
  • Subscribers 5 subscribers
  • Views 9172 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

IPSec Tunnel: length of ISAKMP Message is smaller than minimum

LHerzog

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




This thread was automatically locked due to age.
Parents
  • 0

    Based on Emmanuel's answer, I wonder if you have selected 'Support path MTU discovery' in the Remote Gateway definitions.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks for your answers!

    While checking your answers with the GW config I found out that at least the setting of the Gateway Types was created wrong: both sides of the tunnel are set to "initiate connection"

    Network WAN scheme:

  • 0 in reply to LHerzog

    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.

  • 0 in reply to PhilippRusch

    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.

  • 0 in reply to LHerzog

    Thanks for posting the result to help others!

    In fact, IPsec tunnels can establish when both sides have '"Initiate connection" selected.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to LHerzog

    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.

  • 0 in reply to LHerzog

    "issue happened again after modifiying"

    "still have the settings enabled as written above"

    ???

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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

  • 0 in reply to LHerzog

    What happens if you remove the new network object from the tunnel?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply Children
  • 0 in reply to BAlfson

    Will try that at a good time. The issue is usually resolved by stopping and restarting the tunnel again.

    But If you don't have this in mind when you change something of a tunnel, it currently looks to me as if this state of log-flooding  may happening infinite.

Unfiltered HTML