[strongSwan-dev] [PATCH] Add support for left-/rightallowany to charon

Mirko Parthey mirko.parthey at informatik.tu-chemnitz.de
Wed Nov 30 12:09:34 CET 2011

On Wed, Nov 30, 2011 at 08:58:09AM +0100, Tobias Brunner wrote:
> > this patch adds support for left-/rightallowany to charon
> Thanks for the patch.  I don't really see, though, why this is needed.
> Could you please explain what kind of setup this option is required for
> in charon?

I have two security gateways in different locations.  Each of them has a
dynamic IP address and a corresponding name registered with dyndns.org.
I would like to set up a tunnel (net-net) connecting the LANs
behind the gateways. The tunnel should be persistent (always up),
so I set up ipsec.conf on both peers as follows:

and give the respective other side's dyndns name as right=, with the
"%" indicating rightallowany=yes:


(these names are fictional, obviously)

When one of the security gateways reboots, it cleanly shuts down the tunnel,
and the other side becomes passive. When the rebooted gateway comes back
up, it may get a different IP address, which it registers with the
dyndns service.  However, it may take a few minutes until the new name
resolution is visible to the other side.

Once charon is back up, it initiates a new IKE SA. Since the responder
has right= set to the peer's DNS name (as opposed to "%any"),
it resolves it to an IP address and compares it to the IKE_SA_INIT's
sender IP.  If they don't match because the updated DNS record is not
available yet, the responder rejects the request because it doesn't
match the given connection configuration.

This is where my patch comes in - it allows the following combination
within a single configuration:
- persistent tunnel
- dynamic IP addresses, dyndns names
- completely symmetric setup
- each side can be either initiator or responder, depending on the
- initiator will connect to a configured IP address (dyndns name)
- responder will accept connections from any address

The benefit is that each side can be independently rebooted, and the
tunnel will come back up quickly.

Does that make sense? Can it be done without code changes?


More information about the Dev mailing list