unable to re-create CHILD_SA when it goes down due to inactivity #2199
-
Hello all! I've encountered an issue with phase 2 re-establishment. System server side :
System client side :
The issue I made no changes to configuration files between tests with different versions. The problem occurs with the following simple configuration, used as the server side:
When I start the tunnel from scratch:
Due to inactivity, CHILD_SA will close normally:
However, if I force down and up the complete connection, I encounter no problem. I've checked all configuration default values changed in versions' change logs, but I couldn't find what might be causing this problem. Thank by advance to your helps |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 4 replies
-
Any error messages before that? This doesn't really tell us what failed in the kernel (try increasing the log level for knl) or possibly during the key derivation (log level for chd could be increased to see more about that). |
Beta Was this translation helpful? Give feedback.
-
Hi, First establishment
At this point all is warking deleting CHILD_SA dur to inactivity :
new request for phase 2 :
I can't see more reason of unestablishement ... |
Beta Was this translation helpful? Give feedback.
-
I am now able to resolve the issue. To achieve this, I removed the 'NLM_F_DUMP' from the 'nlmsg_flags' flag in the netlink communication between libcharon and the kernel. I removed line 1865 in 'src/libcharon/plugins/kernel_netlink/kernel_netlink_net.c' (hdr->nlmsg_flags |= NLM_F_DUMP;). I believe this issue may be related to my specific routing configuration, which includes numerous routing policy rules, a default route not located in the main routing table, and the use of conntrack mark. Could someone please explain clearly what occurred?" |
Beta Was this translation helpful? Give feedback.
-
It could be the key derivation that fails due to an OpenSSL issue with modp8192 that was discussed in #1255. Thanks @tobiasbrunner !! |
Beta Was this translation helpful? Give feedback.
It could be the key derivation that fails due to an OpenSSL issue with modp8192 that was discussed in #1255.