IPSec error "querying policy 0.0.0.0/0|/0... ... in failed, not found"

[drkrieger]

Hello Folks!

I've got a strange issue that I'm not sure if it could be causing us issues or not. We get this strange error in our IPSec logs:

Oct 2 07:50:32 	charon 		13[KNL] <con10000|3109> querying policy 0.0.0.0/0|/0 === 0.0.0.0/0|/0 in failed, not found
Oct 2 07:50:32 	charon 		13[KNL] querying policy 0.0.0.0/0|/0 === 0.0.0.0/0|/0 in failed, not found 

When it starts to happen this will go on endlessly until our GUI log limit is hit (2000 lines), which becomes a pain as I can't view any other IPSec log information.

The main reason I'm focusing on this issue is that we are running SAP as our ERP system, and it's constantly disconnecting users at the remote branches during the day. Every time it disconnects, the user looses all work on an order or quote they were working on if it wasn't saved yet. It doesn't seem to be caused by anything specific, I've run 10k ping tests without any drops between several of the branches. Our SAP is so sensitive to disconnects that we can't operate it on WiFi in most use cases.

I'd like to find the root cause of this error so I can eliminate the problem and view the logs at the time users report an SAP disconnect.

We are currently running our main datacenter on a 2Gb fiber connection, 200Mb backup fiber. Our IPSec configurations consist of using VTI configuration, IKEv2, and I've disabled 'ReAuth' (only ReKey) on the majority of the problem connections for testing - no changes in stability. We are also experimenting with 'Asynchronous Cryptography' and more efficient Encryption Algorithms to improve tunnel overhead and throughput, but these changes don't seem to have any effect on the problem.

We first noticed these error messages when we converted our tunnels to use VTI. We use VTI as it's much easier to update network routes on the fly without having to restart the tunnels (causes immediate SAP disconnect). It's also significantly easier to manage using static tunnels instead of individual P2 child entries, much less configuration data required.

Has anyone found a root cause of these error messages, and how can we go about fixing the issue or suppressing them if they mean nothing?

Edit: I should mention that I've run 10k ping tests (1 ping/second) to the problem branches, but no pings are dropped.

Thanks in advance!

[Derelict]

That is always logged for a VTI tunnel.

[drkrieger]

@Derelict please don't take this the wrong way, but that answer is in no way helpful. Saying that it is always logged doesn't tell me that there is no way to turn off/suppress the message, or if there's a way to reduce verbosity on this log type.

I feel this is a bug as these lines are logged over 1000 times during a 30 second window and completely wipes out any valuable log information.

P.S. - Should I be increasing my GUI log entries to beyond 2000? This feels almost a little extreme to me.

[Derelict]

If there was I would have suggested it. Consider it log spam.

Something is causing it to log that often, however. What else is logged?

I would back off the VTI configuration and re-do it following the documentation closely.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html

[ddbnj]

@drkrieger
Even though this is an old post I'm getting the same error when trying to use policy based routing with VTI.

If I delete the rules pointing to the ipsec gateway (VTI interface) and recreate a static route, these errors go away, but defeats the purpose of policy based routing.

Were you able to find a solution?

Thanks,

Devan

[jimp]

It's not a fatal error, just annoying log spam. No way to suppress it currently.