Generally, we will not find the CHILD_SA by searching for it with the
outbound SPI (the initiator of the DELETE sent its inbound SPI) - and if
we found a CHILD_SA it would most likely be the wrong one (one in which
we used the same inbound SPI as the peer used for the one it deletes).
And we don't actually want to destroy the CHILD_SA at this point as we
know we already initiated a DELETE ourselves, which means that task
still has a reference to it and will destroy the CHILD_SA when it
receives the response from the other peer.
libcharon_deinit() already calls all the functions we called manually.
Unloading the plugins will not work if charon->initialize() is called
as charon's static plugin features would already be unloaded before the
destroyed members are accessed in destroy() to flush them.
aacf84d837 ("testing: Add expect-connection calls for all tests and
hosts") removed the expect-connection call for the non-existing aaa
connection. However, because the credentials were loaded asynchronously
via start-script the clients might have been connecting when the secrets
were not yet loaded. As `swanctl --load-creds` is a synchronous call
this change avoids that issue without having to add a sleep or failing
expect-connection call.
If a called script interacts with the daemon or one of its plugins
another thread might have to acquire the write lock (e.g. to configure a
fallback or set a value). Holding the read lock prevents that, potentially
resulting in a deadlock.
This took a while as in the OpenSSL package shipped with Debian and on which
our FIPS-enabled package is based, the function SSL_export_keying_material(),
which is used by FreeRADIUS to derive the MSK, did not use the correct digest
to calculate the result when TLS 1.2 was used. This caused IKE to fail with
"verification of AUTH payload with EAP MSK failed". The fix was only
backported to jessie recently.
While this is not the latest 2.x release it is the latest in /old.
Upgrading to 3.0 might be possible, not sure if the TNC-FHH patches could
be easily updated, though. Upgrading to 3.1 will definitely not be possible
directly as that version removes the EAP-TNC module. So we'd first have to
get rid of the TNC-FHH stuff.
Even if not using caching when running the configure script (-C) this
allows pre-defining the result by setting the environment variable
ss_cv_func_pthread_condattr_setclock_monotonic=yes|no|unknown
before/while running the script.
As the check requires running a test program this might be helpful
when cross-compiling to disable using monotonic time if
pthread_condattr_setclock() is defined but not actually usable with
CLOCK_MONOTONIC.
References #1502.
fgetc() returns an int and EOF is usually -1 so when this gets casted to
a char the result depends on whether `char` means `signed char` or
`unsigned char` (the C standard does not specify it). If it is unsigned
then its value is 0xff so the comparison with EOF will fail as that is an
implicit signed int.
Updates the default Debian image used for the test environment from wheezy
to jessie. Also adds a script that allows chrooting to an image (base,
root or one of the guests). In pretty much all test scenarios
expect-connection is used to make test runs more reliable.
Fixes#1382.
There is a bug (fix at [1]) in hostapd 2.1-2.3 that let it crash when used
with the wired driver. The package in jessie (and sid) is affected, so we
build it from sources (same, older, version as wpa_supplicant).
[1] http://w1.fi/cgit/hostap/commit/?id=e9b783d58c23a7bb50b2f25bce7157f1f3
Sometimes tcpdump fails to process all packets during the short running
time of a scenario:
0 packets captured
18 packets received by filter
0 packets dropped by kernel
So 18 packets were captured by libpcap but tcpdump did not yet process
and print them.
This tries to use --immediate-mode if supported by tcpdump (the one
currently in jessie or wheezy does not, but the one in jessie-backports
does), which disables the buffering in libpcap.
However, even with immediate mode there are cases where it takes a while
longer for all packets to get processed. And without it we also need a
workaround (even though the version in wheezy actually works fine).
That's why there now is a loop checking for differences in captured vs.
received packets. There are actually cases where these numbers are not
equal but we still captured all packets we're interested in, so we abort
after 1s of retrying. But sometimes it could still happen that packets
we expected got lost somewhere ("packets dropped by kernel" is not
always 0 either).
The main difference is that ping now reports icmp_seq instead of
icmp_req, so we match for icmp_.eq, which works with both releases.
tcpdump now also reports port 4500 as ipsec-nat-t.
Several packages got renamed/updated, libgcrypt was apparently installed
by default previously.
Since most libraries changed we have to completely rebuild all the tools
installed in the root image. We currently don't provide a clean target in
the recipes, and even if we did we'd have to track which base image we
last built for. It's easier to just use a different build directory for
each base image, at the cost of some additional disk space (if not manually
cleaned). However, that's also the case when updating kernel or
software versions.
It is still compatible with the current release as the config in
sites-available will be ignored, while conf-enabled does not exist and
is not included in the main config.
Unlike `apt-get install` in a chroot debootstrap does not seem to start
the services but stopping them might cause problems if they were running
outside the chroot.
Newer versions of GCC are too "smart" and replace a call to malloc(X)
followed by a call to memset(0,X) with a call co calloc(), which obviously
results in an infinite loop when it does that in our own calloc()
implementation. Using `volatile` for the variable storing the total size
prevents the optimization and we actually call malloc().
This fixes DNS server installation if make-before-break reauthentication
is used as there the new SA and DNS server is installed before it then
is removed again when the old IKE_SA is torn down.
If running resolvconf fails handle() fails release() is not called, which
might leave an interface file on the system (or depending on which script
called by resolvconf actually failed even the installed DNS server).
Changes how the interface for routes installed with policies is
determined. In most cases we now use the interface over which we reach the
other peer, not the interface on which the local address (or the source IP) is
installed. However, that might be the same interface depending on the
configuration (i.e. in practice there will often not be a change).
Routes are not installed anymore for drop policies and for policies with
protocol/port selectors.
Fixes#809, #824, #1347.
We don't need them for drop policies and they might even mess with other
routes we install. Routes for policies with protocol/ports in the
selector will always be too broad and might conflict with other routes
we install.
Using the source address to determine the interface is not correct for
net-to-net shunts between two interfaces on which the host has IP addresses
for each subnet.
Other threads are free to add/update/delete other policies.
This tries to prevent race conditions caused by releasing the mutex while
sending messages to the kernel. For instance, if break-before-make
reauthentication is used and one thread on the responder is delayed in
deleting the policies that another thread is concurrently adding for the
new SA. This could have resulted in no policies being installed
eventually.
Fixes#1400.
memeq() is currently used to compare these but if there is padding that
is not initialized the same for two instances the comparison fails.
Using this function ensures the objects are compared correctly.
If a pseudonym changed a new entry was added to the table storing
permanent identity objects (that are used as keys in the other table).
However, the old mapping was not removed while replacing the mapping in
the pseudonym table caused the old pseudonym to get destroyed. This
eventually caused crashes when a new pseudonym had the same hash value as
such a defunct entry and keys had to be compared.
Fixesstrongswan/strongswan#46.
If two CHILD_SAs with mark=%unique are created concurrently they could
otherwise end up with either the same mark or different marks in both
directions.
This is the case for the IKE_SA_INIT and the initial IKEv1 messages, which
are pre-generated in tasks as at least parts of it are used to generate
the AUTH payload. The IKE_SA_INIT message will never be fragmented, but
the IKEv1 messages might be, so we can't just call generate_message().
Fixes#1478.
Some peers send an INITIAL_CONTACT notify after they received our XAuth
username. The XAuth task waiting for the third XAuth message handles
this incorrectly and closes the IKE_SA as no configuration payloads are
contained in the message. We queue the INFORMATIONAL until the XAuth
exchange is complete to avoid this issue.
Fixes#1434.
The versioning scheme used by Python (PEP 440) supports the rcN suffix
but development releases have to be named devN, not drN, which are
not supported and considered legacy versions.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
After adding the read callback the state is WATCHER_QUEUED and it is
switched to WATCHER_RUNNING only later by an asynchronous job. This means
that a thread that sent a Netlink message shortly after registration
might see the state as WATCHER_QUEUED. If it then tries to read the
response and the watcher thread is quicker to actually read the message
from the socket, it could block on recv() while still holding the lock.
And the asynchronous job that actually read the message and tries to queue
it will block while trying to acquire the lock, so we'd end up in a deadlock.
This is probably mostly a problem in the unit tests.
If there is currently no route to reach the other peer we just default
to left=%any. The local address is only really used to resolve
leftsubnet=%dynamic anyway (and perhaps for MIPv6 proxy transport mode).
Fixes#1375.
Metrics are basically defined to order routes with equal prefix, so ordering
routes by metric first makes not much sense as that could prefer totally
unspecific routes over very specific ones.
For instance, the previous code did break installation of routes for
passthrough policies with two routes like these in the main routing table:
default via 192.168.2.1 dev eth0 proto static
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.10 metric 1
Because the default route has no metric set (0) it was used, instead of the
more specific other one, to determine src and next hop when installing a route
for a passthrough policy for 192.168.2.0/24. Therefore, the installed route
in table 220 did then incorrectly redirect all local traffic to "next hop"
192.168.2.1.
The same issue occurred when determining the source address while
installing trap policies.
Fixes 6b57790270 ("kernel-netlink: Respect kernel routing priorities for IKE routes").
Fixes#1416.
An old (already rekeyed) CHILD_SA would get switched back into CHILD_REKEYING
state. And we actually want to change the currently installed CHILD_SA to
that state and later CHILD_REKEYED and properly call e.g. child_rekey() and
not do this again with an old CHILD_SA. Instead let's only check installed
or currently rekeying CHILD_SAs (in case of a rekey collision). It's also
uncommon that there is a CHILD_SA in state CHILD_REKEYED but none in state
CHILD_INSTALLED or CHILD_REKEYING, which could happen if e.g. a peer deleted
and recreated a CHILD_SA after a rekeying. But in that case we don't want
to treat the new CHILD_SA as rekeying (e.g. in regards to events on the bus).
Tobias Brunner