.. _example_vpn_ipsec_unique_unique:

######
Unique
######

Tests for the unique connection option, which controls what
happens when a peer (identified by remote IKE identity)
establishes a new SA while an existing one is already active.
Although these tests use site-to-site peer configurations,
the unique option behaves identically for DMVPN profiles.
DUT0 acts as responder. DUT1 and DUT2 share the same IKE
identity (roadwarrior) to trigger the uniqueness check on
DUT0. Tests are split into two groups: proactive tests use
unique never on initiators, so they do NOT send INITIAL_CONTACT
(isolating the responder's proactive uniqueness check), and
INITIAL_CONTACT tests use the default unique (no) on
initiators, so they DO send INITIAL_CONTACT (testing the
responder's reaction to peer-initiated cleanup).

**********************************
Test Never Without Initial Contact
**********************************

Description
===========

With ``unique = never`` and no INITIAL_CONTACT,
no uniqueness checks are performed. Both SAs
coexist without restriction.

Scenario
========

.. include:: unique/testneverwithoutinitialcontact

.. raw:: html

  <hr>

*******************************
Test No Without Initial Contact
*******************************

Description
===========

With ``unique = no`` and no INITIAL_CONTACT,
no proactive duplicate check is performed.
Both SAs coexist.

Scenario
========

.. include:: unique/testnowithoutinitialcontact

.. raw:: html

  <hr>

************************************
Test Replace Without Initial Contact
************************************

Description
===========

With ``unique = replace`` and no
INITIAL_CONTACT, the responder proactively
detects the duplicate and accepts the new SA.
DUT1 may auto-reconnect, so we only verify
that DUT2's SA is accepted (unlike ``keep``
which rejects it).

Scenario
========

.. include:: unique/testreplacewithoutinitialcontact

.. raw:: html

  <hr>

*********************************
Test Keep Without Initial Contact
*********************************

Description
===========

With ``unique = keep`` and no INITIAL_CONTACT,
the responder proactively detects the duplicate
and rejects the new connection from a different
IP, keeping the existing SA. If the peer
reconnects from the same IP, the new connection
is allowed (treated as reauthentication).

Scenario
========

.. include:: unique/testkeepwithoutinitialcontact

.. raw:: html

  <hr>

**********************************
Test Never Ignores Initial Contact
**********************************

Description
===========

With ``unique = never``, INITIAL_CONTACT
notifications from the peer are ignored.
Both SAs coexist even when the new peer
sends INITIAL_CONTACT.

Scenario
========

.. include:: unique/testneverignoresinitialcontact

.. raw:: html

  <hr>

*********************************
Test No Reacts To Initial Contact
*********************************

Description
===========

With ``unique = no``, the responder does not
proactively check for duplicates but does
delete existing SAs when the new peer sends
INITIAL_CONTACT.

Scenario
========

.. include:: unique/testnoreactstoinitialcontact

.. raw:: html

  <hr>

**************************************
Test Replace Reacts To Initial Contact
**************************************

Description
===========

With ``unique = replace``, the responder also
reacts to INITIAL_CONTACT from the new peer,
destroying existing SAs for the same identity.

Scenario
========

.. include:: unique/testreplacereactstoinitialcontact

.. raw:: html

  <hr>

******************************
Test Keep With Initial Contact
******************************

Description
===========

With ``unique = keep``, if the new peer sends
INITIAL_CONTACT, the existing SA is destroyed
regardless of the keep policy. INITIAL_CONTACT
is processed before evaluating the unique
policy.

Scenario
========

.. include:: unique/testkeepwithinitialcontact

.. raw:: html

  <hr>