If we mistakenly detect a new IKE_SA as a reauthentication the client
won't request the previous virtual IP, but since we already migrated
it we already triggered the assign_vips() hook, so we should reassign
the migrated virtual IP.
Fixes#1152.
Since we don't use the kernel-netlink plugin anymore and the headers
in the NDK are reasonably recent, we don't need this anymore (at least
when building the app).
Fixes#1172.
We already did so during Phase 1 but because all three Quick Mode
message have the same message ID we occasionally dropped the third
message as retransmit, so we do it there too. For INFORMATIONAL
and TRANSACTION exchanges we don't expect more than one inbound message
with the same message ID so we still use them there.
Fixes#1198.
This ensures we don't pass data (via msg_control) defined in a different
scope to sendmsg(). Actually, some compilers (e.g. GCC 5.2.1) might
optimize the memcpy() call away causing the packets not to get sent from
the intended source address.
It also makes the code clearer than with all these ifdefs.
Fixes#1171.
In some scenarios an IKE_SA might get restarted multiple times (e.g.
due to retransmits and delayed INVALID_KE_PAYLOAD notifies) so that
two IKE_SA_INIT messages might be sent that only differ in the
previously randomly generated NAT_DETECTION_SOURCE_IP payload.
This could cause an authentication failure on the responder if the two
peers don't use the same IKE_SA_INIT message in their InitiatorSignedOctets.
While the payload is generated in a reproducible way it will still change
when the daemon is restarted, which should make detecting the payloads
as fake a bit harder (compared to e.g. just using 0.0.0.0:0 as address).
Fixes#1131.
If the job gets queued for a newly created IKE_SA it might not yet be
checked in when the job is running, reschedule the job in that case.
This should fix the two p2pnat test scenarios, which occasionally
failed because one of the peers did not initiate the connection to
the mediation server.
In some cases we call wait_for_entry() but don't actually check out the
entry afterwards (e.g. because it doesn't match certain criteria). So
there won't be a call to checkin() for such entries causing waiting
threads to get signaled. Instead, such threads would be blocked until
another thread properly checks out/in the entry (or does a blocking
enumeration).
The `nat-local` and `nat-remote` keys contain information on the NAT
status of the local and remote IKE endpoints, respectively. If a
responder did not detect a NAT but is configured to fake a NAT situation
this is indicated by `nat-fake` (if an initiator fakes a NAT situation
`nat-local` is set). If any NAT is detected or faked `nat-any` is set.
Closesstrongswan/strongswan#16.
If we haven't received the third QM message for multiple exchanges the
return value of NEED_MORE for passive tasks that are not responsible for
a specific exchange would trigger a fourth empty QM message.
Fixes: 4de361d92c ("ikev1: Fix handling of overlapping Quick Mode exchanges")
References #1076.
Previously, the current segment was held while checking for duplicate
SAs, which requires acquiring all segments. If multiple threads did this
concurrently this resulted in a deadlock as they couldn't acquire the
segments held by the other threads attempting to do the same. With the
default configuration only one segment is used, which prevents the problem
as only one thread can check in an IKE SA concurrently.
Fixes: a064eaa8a6 ("Handling of initial contact")
left|rightsubnet default to %dynamic, which is basically 0.0.0.0/0 until an
address is assigned to it. So if only one side was undefined and the other
traffic selector was IPv6 an address family mismatch would occur.
References #595.
From recvfrom(2) (which UDPSocket#recv backs into):
The return value will be 0 when the peer has performed an orderly
shutdown.
(i.e. it will return an empty string)
Previously in this scenario, Vici::Transport#recv_all would spin
forever trying to pull more data off the socket. I'm not entirely
clear what happened that caused strongSwan to shutdown the socket, but
it probably should not cause vici Ruby apps to spin.
Closesstrongswan/strongswan#13.
Tobias Brunner