Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 10 subscribers
  • Views 2635 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 sophos utm sophos xgs

piddae

Wir haben/hatten folgendes Problem:

2023:07:03-09:56:28 login-sp pluto[7264]: "S_Speyer-SPBZ-Koblenz"[4] xxx.xxx.xxx.xxx:4500 #203026: ignoring informational payload, type PAYLOAD_MALFORMED

bei IPSEC zwischen Sophos UTM und XGS. Diese Meldungen kamen xfach. Auf den XGSen  und den UTMS habe ich auf der Firewall pmtu ein-ausgehend erlaubt. Kein Erfolg. Erst als ich die MTU Option bein den IPSEC Gateways (UTM) angehackt habe, ist das erheblich besser geworden. Bei der XGS habe ich keine korrespndierende Einstellung gefunden. Zwei Geräte zicken nach wie vor rum mit endlosen Versuchen. Hat noch jemand eine Idee?

with IPSEC between Sophos UTM and XGS. These messages came x-fold. On the XGS and the UTMS I have allowed pmtu inbound and outbound
on the firewall. No success. Only when I ticked the MTU option for the IPSEC gateways (UTM) did it get significantly better.
I couldn't find a corresponding setting on the XGS. Two devices are still bitching around with endless attempts. Does anyone else
have an idea?

Greetings Pidae


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

    is your log flooded with PAYLOAD_MALFORMED log?

    I had it years ago between XG and UTM IPSEC with PSK.


    there came millions of log lines

    when I changed the tunnel config for the IPSEC to the XG106 when the issue began the first time, the log is totally flooded with this:


    2020:10:15-18:01:59 fw-320-1 pluto[8732]: packet from 217.xxx.xxx.126:4500: sending notification PAYLOAD_MALFORMED to 217.xxx.xxx.126:4500
    2020:10:15-18:01:59 fw-320-1 pluto[8732]: packet from 217.xxx.xxx.126:4500: length of ISAKMP Message is smaller than minimum
    2020:10:15-18:01:59 fw-320-1 pluto[8732]: packet from 217.xxx.xxx.126:4500: sending notification PAYLOAD_MALFORMED to 217.xxx.xxx.126:4500

  • 0 in reply to LHerzog

    Yes so it is. The more sorrowing is that the number of rekeying attempts grew and grew. Now after turning on mtu option at UTM it looks much better. " But 2 Aplliances still have the problem. Strange.

  • 0 in reply to piddae

    can you please show who is initiator and who is responder and also share screenshots of your policies.

    Also: as you're in Germany: what's the ISP?

    I want to compare with our settings. the issue is no longer happening here.

    the only  thing that happens rarely is the connection established but "down".

  • 0 in reply to LHerzog

    found my old thread:  IPSec Tunnel: length of ISAKMP Message is smaller than minimum

    no solution though, but you mach check if youre in the same situation

  • 0 in reply to LHerzog

    The utm is connected directly to the internet. The xgses are kabel connected Deutsche Telekom. I suggest, that the maschines are not able to handle the correct mtu settings. On UTM  side the mtu-discover feature is enabled. The UTM is Initiator the xgses are in responder mode.

  • 0 in reply to piddae

    Finally I succeeded. All malformats have vanished. I enbaled mtu.-discovery on the remote-gateways (utm) The algorithm on both sides

    IKE:

    AES 128 SHA2 256 DH-group 15

    IPSEC:

    AES 128 GCM DH-group 15

    Not strict

    No kompression

    On xgs Side the same and no 96bit Option

    Greetings

  • 0 in reply to piddae

    fine! in addition I'd suggest to let the UTM be receiver and XGS be the initiator.

Reply Children
  • 0 in reply to LHerzog

    The xgses are behind a telekom Box (NAT) they cannot initiate a ipsec Connection. I`ve been serching for about one year for a solution. One is to use a preshared secret instead of an rsa-Key. This works I know. Next year the utm is changed to an xgs, we will see if this works better..

    Thanks for your hints.

    Greetings Piddae

Unfiltered HTML