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).
When certificates are imported via Storage Access Framework we did handle
the selection directly in onActivityResult(). However, at that point the
activity might apparently not yet be resumed. So committing
FragmentTransactions could result in IllegalStateExceptions due to the
potential state loss. To avoid that we cache the returned URI and wait
until onPostResume() to make sure the activity's state is fully restored
before showing the confirmation dialog.
This fixes an interoperability issue with Windows Server 2012 R2 gateways.
They insist on using modp1024 for IKE, however, Microsoft's IKEv2
implementation seems only to consider the first 15 DH groups in the proposal.
Depending on the loaded plugins modp1024 is now at position 17 or even
later, causing the server to reject the proposal. By removing some of
the weaker and rarely used DH groups from the default proposal we make
sure modp1024 is among the first 15 DH groups. The removed groups may
still be used by configuring custom proposals.
Removes the progress dialogs while connecting/disconnecting, updates
the VPN profile editor (floating labels, helper texts) and allows
configuration of the remote identity (disables loose identity matching),
and selection of the local identity if certificates are used.
Also fixes an issue when redirected during IKE_AUTH and increases the
NAT-T keepalive interval.
Fixes#1403.
onSaveInstanceState is apparently called after pausing the fragment and after
that committing any FragmentTransactions causes an IllegalStateException.
We could use commitAllowingStateLoss() but that's not really necessary
as we don't need to update when we are not active anyway. We also don't
update the view directly after registration as this happens
asynchronously, i.e. we might be paused when it finishes.
Because the support library creates its own layout manually and uses
different IDs than the list_content layout we can't use the method we
used previously (and which is actually recommended in the docs).
For instance, onAttach() with an Activitiy as first argument was deprecated
with API level 23. However, the overload with a Context as first argument
does obviously not get called on older API levels. Luckily, the classes
provided by the support library handle that for us.
This adds a workaround for an issue on older platforms where the list is
not properly styled with colorAccent. Similarly applies to borderless buttons.
The term "gateway" is unfamiliar for most new users (or they confuse it
with the default gateway of their network) but they usually know that
they want to connect to a "server".
This mainly changes the color of the appbar (colorPrimary), the color
of the status bar (colorPrimaryDark) is black like the default.
The accent color (colorAccent) used for controls like buttons and check
boxes is a slightly toned down version of the default.
There is no AppCompatProgressDialog class as the use of ProgressDialog
is discouraged (instead progress bars should be placed in the layout directly).
To display the current ProgressDialog instances correctly on systems < 21 we
modify the window background color.
We'll have to change some stuff that Google deprecated (e.g. the tabs in
the ActionBar) and that requires changing the theme at least in activities.
Since that would look a bit inconsistent we'll change it globally and
use parts of the support library.
This allows using manual priorities for traps, which have a lower
base priority than the resulting IPsec policies. This could otherwise
be problematic if, for example, swanctl --install/uninstall is used while
an SA is established combined with e.g. IPComp, where the trap policy does
not look the same as the IPsec policy (which is now otherwise often the case
as the reqids stay the same).
It also orders policies by selector size if manual priorities are configured
and narrowing occurs.
This could interfere with cleanup handlers that try to acquire
mutexes while other threads holding these try to e.g. cancel the threads.
As cleanup handlers are only queued by the threads themselves we don't need
any synchronization to access the list.
Fixes#1401.
This allows two CHILD_SAs with reversed subnets to install two FWD
policies each. Since the outbound policy won't have a reqid set we will
end up with the two inbound FWD policies installed in the kernel, with
the correct templates to allow decrypted traffic.
We can't set a template on the outbound FWD policy (or we'd have to make
it optional). Because if the traffic does not come from another (matching)
IPsec tunnel it would get dropped due to the template mismatch.
If there is a DROP shunt that matches outbound forwarded traffic it
would get dropped as the FWD policy we install only matches decrypted
inbound traffic. That's because the Linux kernel first checks the FWD
policies before looking up the OUT policy and SA to encrypt the packets.
This allows us to install more than one FWD policy. We already do this
in the kernel-pfkey plugin (there the original reason was that not all
kernels support FWD policies).
GnuTLS, which can get loaded by the curl plugin, does not properly cleanup
some allocated memory when deinitializing. This causes invalid frees if
leak detective is active. Other invalid frees are related to time
conversions (tzset).
References #1382.
While building against this level in general would break our app on
older systems, the NDK will automatically use this level for 64-bit
ABI builds (which are not supported in older levels). So to build
against 64-bit ABIs we have to support this API level.
Tobias Brunner