Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 20 replies
  • Subscribers 7 subscribers
  • Views 37086 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

[solved] Log flooded with INVALID_MESSAGE_ID errors

RanX
Hi to all !
 
As I got no idea, why I see this error and how to resolve it, I hope somebody from the board can help me.
I've got several IPSec site-to-site Tunnels
One throws me the following errors every 2 seconds
 
2017:08:21-11:09:25 vpn pluto[23586]: "S_XXXXXX_VPN_IPsec" #53: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x276091ae (perhaps this is a duplicated packet)
2017:08:21-11:09:25 vpn pluto[23586]: "S_XXXXXX_VPN_IPsec" #53: sending encrypted notification INVALID_MESSAGE_ID to EXTERNAL_IP_OF_REMOTEGW:500

I got two SAs over this tunnel, both work, so I wonder, what this error is about and how I could get rid of it.

Best Regards

Ranx



This thread was automatically locked due to age.
Parents
  • +1

    Hello Ranx,

    i had a smiliar Problem, could be solved by updating all UTMs that take part in the VPN to the most current firmware 9.602-3.

    Regards

    Jason

    Sophos Certified Architect - UTM

  • 0 in reply to Jason Klein

    Hello Jason,
    to be true, I did not really believe, this would fix the issue ...
    ... but yes, you're right !
    After updating to the latest firmware, the errors are gone.
    Thanks a lot for this valuable hint !
    Best Regards
    ranX

  • 0 in reply to RanX

    Hi Ranx,

    very nice. Have nice day.

    Regards

    Jason

    Sophos Certified Architect - UTM

  • 0 in reply to Jason Klein

    Hi all,

    many thanks for your answers, you are giving me a hope.

    I'll try to update to the lastest available firmware 9.602-3.

    I let you know when done.

    Kind regards.

    Max.

  • 0 in reply to MassimoDalla Giustina

    Hi all,

    unfortunately installing updates (upgraded to 9.603-1) don't solve the problem. :-(

    INVALID_MESSAGE_ID errors still persist and the tunnel goes down periodically.

    Any other idea?

    Kind regards.

     

    Max.

     

  • 0 in reply to MassimoDalla Giustina

    Re check all Parameters of the vpn to be the same om both UTMs

    Regards

    Jason

    Sophos Certified Architect - UTM

  • 0 in reply to Jason Klein

    Hi Jason,

     

    unfortunatelly we don't have control at the remote side.

    The only thing we know is that the other party has a Checkpoint firewall and on UTM log I found several message like this:

    cannot respond to IPsec SA request because no connection is known for <local net>===<local pub IP>...<remote pub IP>===10.0.0.0/8

    10.0.0.0/8 is out of the scope of the agreed policy and they don't want to change because it could break other tunnels at their side.

    It seems our tunnel be part of a common configuration on their firewall.

    Probably they will be able to move our tunnel on a separate configuration and so change the private network range to the same value used by our side.

     

    I let you know.

    Regards.

     

    Max.

  • 0 in reply to MassimoDalla Giustina

    Ciao Max,

    Your conflict can likely be solved with a combination of 1:1 Source and Destination NATs.  What are your internal subnets in 10.0.0.0/8 and do you need to reach the same subnet(s) on the other site? 

    Just a comment about using 10/8 - it's ridiculous for a single location to use the entire /8.  Very large companies should use subnets in 10/8, but never the entire /8.  Subnets in 192.168.0.0/16 should be reserved for homes and public hotspots.  Almost every other organization, regardless of size, should use subnets in 172.16/12.

    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

    Hi Bob,

     

    the 10.0.0.0/8 is the network coming from the remote side despite I had agreed with the remote party to use a specific subnet.

    I discovered this looking on the ipsec.log file because the tunnel goes down almost every day.

    Unfortunately (what I was able to know) the remote party configured our VPN tunnel on the same checkpoint profile used for other parties with 10.0.0.0/8 network.

    Changing this configuration in order to have a dedicated VPN profile will be disruptive and must be planned but I guess it will solve the problem.

    I let you know if the story will have a good ending.

    Max.

     

     

  • 0 in reply to MassimoDalla Giustina

    Hi folk, I'm very happy because the remote party has changed the VPN profile with the correct networks and the problem disappeared!

    Many thanks for your suggestions.

     

    Max.

     

Reply Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?