On Wed, Dec 02, 2015 at 03:53:46PM +0100, Marko CupaÄ wrote:
> On Tue, 1 Dec 2015 23:49:37 +0000 (UTC)
> Stuart Henderson <[email protected]> wrote:
>
> > Neither isakmpd nor iked tracks DNS changes.
>
> This is good to know, thank you for the information.
>
> > On the central side use "passive" not "dynamic". Remove the "peer
> > $gw_branche" to set this for the 'default peer' (i.e. to avoid
> > matching on IP address).
> >
[ ...snip ]
> > It might be easier to get the basic setup working with psk first, but
> > when you have that up and running, see the PUBLIC KEY AUTHENTICATION
> > section in isakmpd(8) and get that setup, it is pretty simple to use
> > and much safer than psk.
>
> That was the idea from the beginning, didn't want to complicate further
> before having basic setup working.
>
You have things working as well as they can if you have a Dynamic IP
address for one endpoint. It's really too bad that ipsec is such a
black box in this area. You really have to deconstruct IPSec to
understand the mechanisms that it uses to identify a peer and choose a
configuration.
When your ipsec.conf file specifies multiple stanzas corresponding to
different tunnels, the isakmpd or iked has to figure out which peer
it's talking to. Let's call this peer endpoint identification. It has
to do this so it can apply the correct stanza to the connecting
peer. It can identify a peer via IP address, FQDN from DNS, or via a
key or certificate. Alternatively your static side configuration can
specify a default and if the dynamic side only needs to present the
correct key, the static side can establish the tunnel. As someone
mentioned above, both isakmpd, and iked do a DNS lookup at program
startup and then never consult DNS again. The implication of "once at
startup DNS" is that using FQDN via DNS with a dynamic IP is always
going to be problematic.
You know that the tunnel parameters you have are setup correctly on
both sides because the tunnel works initially. If your dynamic side is
truly dynamic what's happening is this:
The dynamic side tries to renegotiate because it's IP address
changed;
The static side rejects the negotiation because it hasn't updated
it's config to match the new state in DNS.
Moving to public keys will fix the renegotiation problem by using an
identification token that's independent of DNS.
-- Chris
[demime 1.01d removed an attachment of type application/pgp-signature which had
a name of signature.asc]
