[solved] Log flooded with INVALID_MESSAGE_ID errors

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.

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

Hi Ranx,

very nice. Have nice day.

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.

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.

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

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.

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.

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

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.

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.