| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
When handling thousands of IKE_SAs, the unique ID based lookup is rather slow,
as we have no indexing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iOS and Mac OS X clients establish individual IPsec SAs for the traffic
selectors received in Split-Include attributes (might have been different
in earlier releases). If we return 0.0.0.0/0 as TSr that either results
in a bunch of Quick Mode exchanges (for each TS), or with the latest
client releases an error notify (ATTRIBUTES_NOT_SUPPORTED).
We also can't install the IPsec SA with all configured subnets as that
would cause conflicts if the client later negotiates SAs for other subnets,
which iOS 8 does based on traffic to such subnets.
For Shrew and the Cisco client, which propose 0.0.0.0/0, we still need to
override the narrowed TS with 0.0.0.0/0, as they otherwise won't accept
the Quick Mode response. Likewise, we also have to narrow the TS before
installing the IPsec SAs and policies.
So we basically have to follow the client's proposal and only modify TSr
if we received 0.0.0.0/0. Since we don't get the original TS in the
narrow hook we handle the inbound QM messages and make note of IKE_SAs on
which we received a TSr of 0.0.0.0/0.
Fixes #737.
|
|
|
|
|
|
|
| |
When having the unity plugin enabled and both peers send the Unity Vendor ID,
we proposed 0.0.0.0/0 as traffic selector, even if no Split-Include has been
received on the SA. This can break compatibility with some responders, as
they don't narrow the TS themselves, but expect the configured TS.
|
|
|
|
|
|
| |
Since the narrow hook types reflect the roles in the Quick Mode exchange
the plugin behaved incorrectly if the server initiated the CHILD_SA
rekeying.
|
|
|
|
|
| |
Cisco clients and Shrew expect a remote TS of 0.0.0.0/0 if Unity is
used, otherwise Quick Mode fails.
|
|
|
|
| |
received
|
|
|
|
| |
that
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|