It seems that several people are reporting IPsec VPN issues with pfsense 2.x (note: which includes the recent ipsec-tools 0.8.0). While some problems may be due to misconfiguration (e.g. the racoon / mpd conflict), the pfsense<->pfsense VPN scenario should be trouble-free.
As most of the problems posted here seem to be related to rekeying, I've been searching the ipsec-tools-devel mailing lists for clues. Check the following discussions:
http://old.nabble.com/why-is-SA-lifetime-kilobyte-limit-disabled-in-racoon–td31648198.html
Even if Node-A think IPsec-SA is expired at this time, Node-B doen't
think so. i.e. the states of IPsec-SA is mismatched.
Understand – similar things already happen with time-based
lifetimes if there is a clock skew between the two boxes.
(This is particulary bad if the oldest available SA is used
by the kernel.)
Racoon's strategy of rekeying is "Initiator do it." If Node-B
is responder, Node-A doesn't start rekeying even if IPsec-SA is
expired.
That sounds like a bug in racoon. It seems that if either end is
unsatisfied with the SA, that end should trigger a new one.
I'd also call this a shortcoming at least. The standards are
weak, and one doesn't know how other implementations behave.
It would be safer if both sides did care about renegotiations.
But the key
question is what the other implementions do, and what the standard says.
I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
It initiates a Phase 2 exchange if the soft timeout on its
side expires, even if it was responder initially. (It randomizes
the soft timeouts to minimize the chance that both sides start
the exchange simultanously.)
PFC2409 says that both sides can initiate rekeying. "Can" --
this is not much of a guideline for implementors.
I can see the argument that especially with a 24h or less
lifetime, AES doesn't need volume-based rekeying.
OK, I was more concerned about interoperability. What if
the other side insists in some volume limit?
I've just tried OpenBSD's isakmpd (the oldish version in pkgsrc).
It initiates a Phase 2 exchange if the soft timeout on its
side expires, even if it was responder initially. (It randomizes
the soft timeouts to minimize the chance that both sides start
the exchange simultanously.)
PFC2409 says that both sides can initiate rekeying. "Can" --
this is not much of a guideline for implementors.
True, but it seems the original responder initiating a renegotiation is
the only reasonable behavior.
At the very least, it would appear to suggest that if the original
initiator rejects an attempt on the part of the original responder to
rekey, that's a bug.
True, but it seems the original responder initiating a renegotiation is
the only reasonable behavior.
If both side start rekeying at same time, there is/was a problem of
SA selection.
The two rekeying session makes two pair of IPsec-SAs. racoon can
do this, and IPsec implementations (kernel side) do one of following:
a. Use oldest IPsec-SA to send and keep all IPsec-SAs to receive(KAME)
b. Use newest IPsec-SA to send and keep all IPsec-SAs to receive(Fast IPsec)
c. Use newest IPsec-SA to send/receive and purge older IPsec-SAs
Of cause, c. is bad behavior, but small implementations(kernel side)
may handle only one sessions and one key pair at a time.
Standards don't prohibit this. This problem is exist between IKE
standards and IPsec standards. It seems IKEv2 makes this more clean.
Today, most implementations select b. or have configuration for it.
And racoon isn't used on other than KAME, Fast IPsec, or Linux(a. or b.)
I think your logic actually works fine. But racoon is old product,
so it doesn't catch recent trends up.
http://marc.info/?l=ipsec-tools-devel&m=129905181832157&w=2
http://marc.info/?l=ipsec-tools-devel&m=129916127621017&w=2
let me revive the discussion on an active negotiation,
as opposed to a passive daemon. Until recently my use
of IPsec was tied to isakmpd, ipsecctl, and OpenBSD
and my views are conditioned by this fact. There the
IPsec daemon is normally active in initiating its
negotiations at startup, unless told to configure
a passive listener for a particular tunnel/transport.
At the other extreme there is even a so called
active-only setting.
The implicit and default setting in racoon-0.7.3 is
"passive off", but this still waits for a demand to be
detected. Thus the mode is better described as "passive
until harshly bugged to get going"! The need to ping
and wait for a ridiculously long delay should not be
acceptable in most circumstances. Forgive me for the
critisism, but to me this is a design flaw. It is a
question of dependability and of trust to erect the
desired IPsec tunnels already at booting time.
Funny: when we tried to switch from racoon to isakmpd at work, a long
long time ago, this is one of the things we noticed on our TODO list:
patch isakmpd to negociate SAs only when traffic comes to the tunnel :-)
And this is how things should (can ?) be done according to RFC 2367
which provide SADB_ACQUIRE PFkey message….
Now, doing comparative browsing in the sources 0.7.3
and 0.8, the actual use of the variable PASSIVE in
"struct remoteconf" has indeed expanded somewhat.
Is the code progressing or maturing into a state
that allows an actively negotiating daemon? I.e.,
without waiting for traffic demand before commencing?
Not afaik.
Feel free to provide a patch for that, this would not be so
complicated to parse all config and start negociation for needed
tunnels, but there are also setups where we want to have tunnels
negociated only when needed (so when traffic comes to the tunnel), so
a patch will need to provide this feature as optional.
The best would be to have a peer-based (or sainfo based ?) token for
that.
Please also note that this is quite easy to also generate dummy
traffic for the needed tunnels when you activate the configuration if
you want.
And of course generate dummy traffic from time to time to ensure the
tunnel will always be up.
