Project

General

Profile

Feature #2307

Permit installation of trap policy for CHILD_SA configurations with unset local_addrs

Added by Noel Kuntze over 3 years ago. Updated over 3 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
vici
Target version:
-
Start date:
Due date:
Estimated time:
Resolution:

Description

Configurations that follow the style of the trap-any test scenario (IPs from remote_ts are used to directly figure out the other peer's IP address and local_addrs is unset) don't allow the installation of the trap policy using swanctl -i --child CHILD_SA_CONFIG when start_action = none. Having the ability to do that would be nice, because it allows programmatic changes without having to edit and reload the conns.

History

#1 Updated by Tobias Brunner over 3 years ago

  • Category set to vici
  • Status changed from New to Feedback

Why not? What exactly is the error/problem? Config? Log?

Having the ability to do that would be nice, because it allows programmatic changes without having to edit and reload the conns.

What do you mean with that? Example?

#2 Updated by Noel Kuntze over 3 years ago

  • Tracker changed from Issue to Feature

Duh. Nevermind.

swanctl -i <<>> swanctl -u. Sorry for the heckmeck.

The actual problem is initiating the connection. I can install and uninstall the policies just fine.
Having a way to do that would be nice.

#3 Updated by Tobias Brunner over 3 years ago

The actual problem is initiating the connection. I can install and uninstall the policies just fine.
Having a way to do that would be nice.

You mean other than by creating traffic?

#4 Updated by Noel Kuntze over 3 years ago

Tobias Brunner wrote:

The actual problem is initiating the connection. I can install and uninstall the policies just fine.
Having a way to do that would be nice.

You mean other than by creating traffic?

Yes. And without having to specify the remote address manually in the configuration. Sometimes waiting for the acquire
to expire so a second acquire can retry to initiate a CHILD_SA is just too long.

#5 Updated by Tobias Brunner over 3 years ago

Sometimes waiting for the acquire
to expire so a second acquire can retry to initiate a CHILD_SA is just too long.

When does that happen? Did you consider lowering charon.plugins.kernel-netlink.xfrm_acq_expires?

#6 Updated by Noel Kuntze over 3 years ago

Tobias Brunner wrote:

Sometimes waiting for the acquire
to expire so a second acquire can retry to initiate a CHILD_SA is just too long.

When does that happen? Did you consider lowering charon.plugins.kernel-netlink.xfrm_acq_expires?

Not yet.

Well, I remember that there are two reasons I'd like to have this for:

  • When an additional CHILD_SA to the remote peer is needed, a second IKE_SA configuration has to be used and the new CHILD_SA put in there or one can't initiate that CHILD_SA, because the remote_addrs is unknown.
  • Sometimes one wants to change some tiny parameter in a conn, so the configuration needs to be edited, reloaded, the IKE_SA brought down and up again. With trap-any style configurations, one can't bring it up again manually.

Also available in: Atom PDF