CDRouter Support

CDRouter IKE Test Summaries (Full)

test-summary version 13.3

Test Case Descriptions

  • Modules: 2
  • Test Cases: 58

Below is a full description of the testcases in each module


ike.tcl

IKEv1 site-to-site tunnel testing

Test Module Name Synopsis
Verify gateway can act as tunnel initiator ike.tcl ike_1 Verify gateway can act as tunnel initiator


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test verifies that device under test can initiate IKE Phase 1
    exchanges (Main Mode or Aggressive Mode) and Phase 2 exchanges (Quick Mode)
    to establish a tunnel when traffic is presented that matches the tunnel
    configuration.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway can act as tunnel responder ike.tcl ike_2 Verify gateway can act as tunnel responder


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test verifies that the device under test can act as a
    responder in both a Main Mode and Quick Mode exchange.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify traffic is not sent in the clear when all Phase 2 SAs are deleted ike.tcl ike_4 Verify traffic is not sent in the clear when all Phase 2 SAs are deleted


    step 1. Delete all existing Quick Mode SAs for the tunnel
    step 2. Configure CDRouter to ignore any new Quick Mode packets
    step 3. Send traffic from LAN that matches tunnel
    step 4. Verify traffic is not sent in the clear out WAN interface

    NOTE: When a site-to-site tunnel is configure on the device under
    test, traffic that matches the tunnel should not be sent in the clear
    when the tunnel is down. This test brings the tunnel to a down state by
    deleting all of the Quick Mode SAs but leaving any existing Main Mode SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify traffic is not sent in the clear when all Phase 1 and 2 SAs are deleted ike.tcl ike_5 Verify traffic is not sent in the clear when all Phase 1 and 2 SAs are deleted


    step 1. Delete all existing Quick Mode and Main Mode SAs for the tunnel
    step 2. Configure CDRouter to ignore any new Main Mode and Quick Mode packets
    step 3. Send traffic from LAN that matches tunnel
    step 4. Verify traffic is not sent in the clear out WAN interface

    NOTE: When a site-to-site tunnel is configured on the device under
    test, traffic that matches the tunnel should not be sent in the
    clear when the tunnel is down. This test brings the tunnel to a down
    state by deleting all of the Main Mode and Quick Mode SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway switches to new Phase 2 SA after peer initiates new Phase 2 SA ike.tcl ike_10 Verify gateway switches to new Phase 2 SA after peer initiates new Phase 2 SA


    step 1. Establish a new Quick Mode SA using the existing Main Mode SA
    step 2. Verify a new Quick Mmode SA is established
    step 3. Wait ikeNewQuickModeDelay milliseconds
    step 4. Send traffic from LAN that matches tunnel
    step 5. Verify router switches to new Quick Mode SA
    step 6. Repeat 2 additional Quick Modes


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway switches to new Phase 2 SA after peer initiates new Phase 1 and 2 SA ike.tcl ike_12 Verify gateway switches to new Phase 2 SA after peer initiates new Phase 1 and 2 SA


    step 1. Establish a new Main Mode SA
    step 2. Establish a new Quick Mode SA using new Main Mode
    step 3. Verify a new Quick Mode SA is established
    step 4. Wait ikeNewQuickModeDelay milliseconds
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify router switches to new Quick Mode SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify deletion of old Phase 1 and 2 SAs does not stop traffic over new SA ike.tcl ike_14 Verify deletion of old Phase 1 and 2 SAs does not stop traffic over new SA


    step 1. Establish a new Main Mode SA
    step 2. Establish a new Quick Mode SA using new Main Mode
    step 3. Verify a new Quick Mode SA is established
    step 4. Wait ikeNewQuickModeDelay milliseconds
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify router switches to new Quick Mode SA
    step 7. Delete old Quick Mode SAs
    step 8. Delete old Main Mode SAs
    step 9. Verify tunnel traffic from LAN is still forwarded using new SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify old Phase SA continues to work after new Phase 2 SA is initiated ike.tcl ike_16 Verify old Phase SA continues to work after new Phase 2 SA is initiated


    step 1. Delete all Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 and Phase 2
    step 3. Verify tunnel traffic is using the new Phase 2 SA
    step 4. Initiate a new Phase 2 SA using the same Phase 1
    step 5. Send traffic from LAN that matches tunnel
    step 6. Send return traffic back using original Phase 2 SA
    step 7. Verify traffic on the original Phase 2 SA is still forwarded


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway has retransmission strategy for Phase 1 establishment ike.tcl ike_30 Verify gateway has retransmission strategy for Phase 1 establishment


    step 1. Delete all Quick Mode and Main Mode SAs
    step 2. Initiate traffic from the LAN that matches tunnel
    step 3. Verify Phase 1 packet is sent by IKE gateway
    step 4. Do not respond to Phase 1 packet
    step 5. Continue to send traffic on the LAN
    step 6. Wait for additional Phase 1 packet from IKE gateway
    step 7. Continue until 3 Phase 1 packets have been sent

    NOTE: This test will verify that the router continues to send Phase 1
    packets to initiate a tunnel that is down. The test will wait up to 120
    seconds to 3 Phase 1 packets to be sent.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway has retransmission strategy for Phase 2 establishment ike.tcl ike_31 Verify gateway has retransmission strategy for Phase 2 establishment


    step 1. Delete all Quick Mode and Main Mode SAs
    step 2. Initiate traffic from the LAN that matches tunnel
    step 3. Verify new Phase 1 is established
    step 4. Continue to send traffic on the LAN
    step 5. Wait for additional Phase 2 packet
    step 6. Do not respond to Phase 2 packet
    step 7. Wait for Phase 2 packet to be retransmitted

    NOTE: This test will verify that the router retransmits the Phase 2 packets
    when establishing a new quickmode SA. The test will wait up to 280 seconds
    for 2 Phase 2 packets to be sent. The test fails if the router restarts the
    exchange by sending a new Phase 1 packet.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway sends Phase 1 delete notification after Phase 1 lifetime expires (initiator) ike.tcl ike_40 Verify gateway sends Phase 1 delete notification after Phase 1 lifetime expires (initiator)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 1 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway sends Phase 2 delete notification after Phase 2 lifetime expires (initiator) ike.tcl ike_41 Verify gateway sends Phase 2 delete notification after Phase 2 lifetime expires (initiator)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for the Phase 2 SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 2 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (initiator) ike.tcl ike_42 Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (initiator)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for Phase 1 SA to expire
    step 4. Router should delete the expired Phase 1 SA
    step 5. Send traffic from LAN to force tunnel up
    step 6. Verify router attempts to establish new Phase 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (initiator) ike.tcl ike_43 Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (initiator)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Send traffic on LAN to force gateway to initiate new Phase 1 and 2
    step 3. Wait for the Phase 2 SA lifetime to expire
    step 4. Router should delete the Phase 2 SA
    step 5. Send traffic from LAN that matches tunnel
    step 6. Verify traffic is not sent on expired Phase 2 SA
    step 7. Verify traffic is not sent in the clear


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway sends delete notification after Phase 1 lifetime expires (responder) ike.tcl ike_50 Verify gateway sends delete notification after Phase 1 lifetime expires (responder)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Estabalish a new Phase 1 SA to that gateway is in responder mode
    step 3. Wait for SA lifetime to expire
    step 4. Verify router sends a DELETE Notification for this Phase 1 SA

    NOTE: This test uses the value of testvar 'ikeMinimumLifetime' to
    set the value of the lifetime for the new Phase 1. The lifetime value is
    in seconds and defaults to 20. Some implementations may not allow a
    lifetime to be created if it is smaller than the router's configured lifetime.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway sends delete notification after Phase 2 lifetime expires (responder) ike.tcl ike_51 Verify gateway sends delete notification after Phase 2 lifetime expires (responder)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 SA
    step 3. Establish a new Phase 2 SA so that gateway is in responder mode
    step 4. Wait for the Phase 2 SA lifetime to expire
    step 5. Verify router sends a DELETE Notification for this Phase 2 SA

    NOTE: This test uses the value of testvar 'ipsecMinimumLifetime' to
    set the value of the lifetime for the new Phase 1. The lifetime value is
    in seconds and defaults to 20. Some implementations may not allow a
    lifetime to be created if it is smaller than the router's configured lifetime.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (responder) ike.tcl ike_52 Verify gateway deletes Phase 1 SA after Phase 1 lifetime expires (responder)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish new Phase 1 SA
    step 3. Ignore any Phase 2 initiation attempts
    step 4. Wait for Phase 1 SA to expire
    step 5. Router should delete the expired Phase 1 SA
    step 6. Send traffic from LAN to force tunnel up
    step 7. Verify router attempts to establish new Phase 1

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (responder) ike.tcl ike_53 Verify gateway deletes Phase 2 SA after Phase 2 lifetime expires (responder)


    step 1. Delete all existing Phase 1 and Phase 2 SAs
    step 2. Establish a new Phase 1 SA
    step 3. Establish a new Phase 2 SA
    step 4. Ignore any new Phase 1 or Phase 2 attempts
    step 5. Wait for the Phase 2 SA lifetime to expire
    step 6. Router should delete the Phase 2 SA
    step 7. Send traffic from LAN that matches tunnel
    step 8. Verify traffic is not sent on expired Phase 2 SA
    step 9. Verify traffic is not sent in the clear


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway sends NOTIFY message when tunnel specification does not match ike.tcl ike_70 Verify gateway sends NOTIFY message when tunnel specification does not match


    step 1. Configure CDRouter to use an unknown subnet for Phase 2 proposal
    step 2. Bring down all existing Phase 1 and 2 SAs
    step 3. Initiate new Phase 1 SA
    step 4. Initiate a new Phase 2 exchange with the gateway
    step 5. Verify the gateway sends a NOTIFY message with NO-PROPOSAL-CHOSEN
            or INVALID-ID-INFORMATION

    NOTE: The sending of a Notify payload is not required but is commonly supported
    to help administrators determine VPN configuration mismatches.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.4: Security Association Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.4

Test Module Name Synopsis
Verify gateway reuses Phase 1 SA when Phase 2 setup fails ike.tcl ike_72 Verify gateway reuses Phase 1 SA when Phase 2 setup fails


    step 1. Delete all existing Phase 1 and 2 SAs
    step 2. Initiate a new Phase 1 SA
    step 3. Initiate a new Phase 2 SA with unaccpetable proposal
    step 4. Send traffic on LAN interface to try to establish the tunnel
    step 5. Verify gateway does not create additional Phase 1 SAs


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway reuses Phase 1 SA when Phase 2 is deleted ike.tcl ike_73 Verify gateway reuses Phase 1 SA when Phase 2 is deleted


    step 1. Delete all existing Phase 2 SAs
    step 2. Initiate traffic on the LAN to force gateway to create new Phase 2
    step 3. Verify router uses existing Phase 1 and does not create new Phase 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 1 ike.tcl ike_80 Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 1


    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1 using INITIAL-CONTACT
    step 3. Gateway should delete all existing Phase 2 SAs
    step 4. Ignore any Phase 2 requests
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist

    NOTE: This test is skipped if Aggressive Mode tunnels are configured.
    When Aggressive Mode is used, INITIAL-CONTACT messages can only sent
    in Phase 2 or Informational messages after the Phase 1 SA is established.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 2 ike.tcl ike_81 Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received during new Phase 2


    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1
    step 3. Initiate new Phase 2 with INITIAL-CONTACT
    step 4. Gateway should delete all existing Phase 2 SAs
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify INITIAL-CONTACT is ignored if not protected under IKE SA ike.tcl ike_82 Verify INITIAL-CONTACT is ignored if not protected under IKE SA


    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1 using INITIAL-CONTACT in first packet (unprotected)
    step 3. Gateway should not delete all existing Phase 2 SAs
    step 4. Verify tunnel is still operational

    RFC 2407 IP Security Domain of Interpretation
    Section 4.6.3 IPSEC Notify Message Types

    NOTE: All Notify messages must be protect by an IKE SA including
    the INITIAL-CONTACT message. The first packet in a new Main Mode
    exchange is not protected and could possibly be spoofed.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received from NOTIFY ike.tcl ike_85 Verify gateway deletes existing Phase 2 SAs when INITIAL-CONTACT message is received from NOTIFY

    step 1. Verify Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 1
    step 3. After Phase 1 is established, send a NOTIFY message with INITIAL-CONTACT
    step 4. Gateway should delete any existing SAs
    step 5. Initiate traffic from LAN for tunnel
    step 6. Verify no traffic is sent on the tunnel since no Phase 2 SAs exist


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify the maximum number of Phase 2 SAs that can be established with remote gateway ike.tcl ike_100 Verify the maximum number of Phase 2 SAs that can be established with remote gateway


    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Create ikeMaxPhase2SA additional Phase 2 SAs
    step 3. Verify all Phase 2 SAs are created

    NOTE: The testvar 'ikeMaxPhase2SA' controls how many total Phase 2 SAs
    will be created. The default value is 20 Phase 2 SAs.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify Phase 1 SA can be established when unknown Vendor IDs are included ike.tcl ike_110 Verify Phase 1 SA can be established when unknown Vendor IDs are included


    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Initiate a new Phase 1 SA include 3 unknonwn vendor IDs
    step 3. Initiate a new Phase 2 SA
    step 4. Verify gateway switches to new Phase 2 SA


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway rejects Phase 2 proposals with unknown payloads ike.tcl ike_122 Verify gateway rejects Phase 2 proposals with unknown payloads


    step 1. Verify existing Phase 1 and Phase 2 SAs exist
    step 2. Initiate new Phase 2 SA using bad payload
    step 3. Verify Phase 2 SA is not established
    step 4. If NOTIFY message is received, verify type is PAYLOAD-MALFORMED
            or INVALID-PAYLOAD-TYPE


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.3: Generic Header Processing

    https://tools.ietf.org/html/rfc2408#section-5.3

Test Module Name Synopsis
Verify starting ESP sequence number for new phase SA is 1 ike.tcl ike_130 Verify starting ESP sequence number for new phase SA is 1


    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Initiate ICMP Echo Request from LAN over the tunnel with inbound
    step 4. Verify first IPSEC ESP packet has a sequence number of 1


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.3: Sequence Number Generation

    https://tools.ietf.org/html/rfc2406#section-3.3.3

Test Module Name Synopsis
Verify gateway anti-replay detection ike.tcl ike_135 Verify gateway anti-replay detection


    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Initiate ICMP Echo  Request from LAN over the tunnel with inbound
            starting ESP sequence number of 1
    step 4. Verify ICMP Echo Request is successful
    step 5. Reset the ESP sequence number to 1
    step 6. Initiate another ICMP Echo Request from LAN over the tunnel
    step 7. Verify inbound ESP packets are not forwarded to LAN


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test Module Name Synopsis
Verify out of sequence ESP packets to not trigger replay detection ike.tcl ike_136 Verify out of sequence ESP packets to not trigger replay detection


    step 1. Find existing Phase 1 SA
    step 2. Initiate a new Phase 2 SA
    step 3. Send 3 UDP Echo Requests from the LAN over tunnel
    step 4. Send UDP Echo Replies back over the tunnel using out of
            order ESP sequence numbers
    step 5. Verify UDP packets are forwarded to the LAN

    NOTE: The gateway must have a SPI window size of at least 3 packets
    to pass this test.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test Module Name Synopsis
Verify IPSEC window moves forward ike.tcl ike_140 Verify IPSEC window moves forward


    step 1. Find the existing Phase 1 SA
    step 2. Establish a new Phase 2 SA
    step 3. Set the outbound ESP sequence number to 0x5000000
    step 4. Initiate ICMP Echo Request from LAN over the tunnel
    step 5. Set the outbound ESP sequence number back to 0x1000000
    step 6. Initiate ICMP Echo Request from LAN over the tunnel
    step 7. Verify WAN IPSEC ESP packets with old sequence number
            are not forwarded to LAN


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.4: Sequence Number Verification

    https://tools.ietf.org/html/rfc2406#section-3.3.4

Test Module Name Synopsis
Verify gateway responds to Dead Peer detection R-U-THERE requests ike.tcl ike_200 Verify gateway responds to Dead Peer detection R-U-THERE requests


    step 1. Find existing Phase 1 SA
    step 2. Send R-U-THERE request
    step 3. Verify R-U-THERE ACK is received
    step 4. Continue up to 5 R-U-THERE requests

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway supports peer IDs of type ID_FQDN ike.tcl ike_300 Verify gateway supports peer IDs of type ID_FQDN


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of ID_FQDN
    step 4. Verify Phase 1 is successful
    step 5. Initiate a Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: By default, this test uses a FQDN of "fqdn-test.cdroutertest.com". A different
    FQDN name can be used by configuring the testvar 'ike_FQDN'.

    testvar ike_FQDN fqdn-test.cdroutertest.com


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway supports peer IDs of type ID_USER_FQDN ike.tcl ike_301 Verify gateway supports peer IDs of type ID_USER_FQDN


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of ID_USER_FQDN
    step 4. Verify Phase 1 is successful
    step 5. Initiate a Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: By default, this test uses a USER_FQDN of "cdrouter@fqdn-test.cdroutertest.com".
    A different USER_FQDN name can be used by configuring the testvar 'ike_USER_FQDN'.

    testvar ike_USER_FQDN cdrouter@fqdn-test.cdroutertest.com


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway gracefully fails when ID type is unknown ike.tcl ike_302 Verify gateway gracefully fails when ID type is unknown


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a Phase 1 exchange with an ID type of 0x57
    step 4. Verify Phase 1 is not successful

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway ignores unknown transform in Phase 1 proposal ike.tcl ike_310 Verify gateway ignores unknown transform in Phase 1 proposal


    step 1. Delete all existing Phase 2 and Phase 1 SAs
    step 2. Initiate a new Main Mode using an unknown transform
            followed by a valid transform.
    step 3. The gateway should select the second transform that
            is valid
    step 4. Verify Main Mode completes
    step 5. Verify Quick Mode completes
    step 6. Verify the tunnel is operational

    NOTE: This test is skipped if the maximum number of transforms
    supported is not greater than 1. The testvar 'ikeMaxTransforms'
    can be used to configure the maximum number of transforms that
    CDRouter will send in a Phase 1 Main Mode proposal.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.6: Transform Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.6

Test Module Name Synopsis
Verify gateway can find valid transform in large list of transforms ike.tcl ike_311 Verify gateway can find valid transform in large list of transforms


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1 with up to 20 unknown transforms in Phase 1
            followed by 1 valid transform
    step 4. Router should search transform list and find valid transform
    step 5. Verify Phase 1 completes
    step 6. Initiate Phase 2
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test is skipped if the maximum number of transforms
    supported is not greater than 1. The testvar 'ikeMaxTransforms'
    can be used to configure the maximum number of transforms that
    CDRouter will send in a Phase 1 proposal.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2408 "Internet Security Association and Key Management Protocol (ISAKMP)" Section 5.6: Transform Payload Processing

    https://tools.ietf.org/html/rfc2408#section-5.6

Test Module Name Synopsis
Verify gateway recovers gracefully if no valid transform is found in proposal ike.tcl ike_312 Verify gateway recovers gracefully if no valid transform is found in proposal


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using unknown transform
    step 4. Phase 1 exchange should fail
    step 5. Initiate a new Phase 1 exchange using a valid transform
    step 6. Verify Phase 1 exchange is successful
    step 7. Initiate a new Phase 2 exchange
    step 8. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway ignores unknown transform in Phase 2 proposal ike.tcl ike_320 Verify gateway ignores unknown transform in Phase 2 proposal


    step 1. Delete all existing mainmode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1
    step 4. Verify Phase 1 exchange completes
    step 5. Initiate Phase 2 with 1 unknown transforms followed
            by 1 valid transform
    step 6. Verify Phase 2 exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: This test creates the first transform with an SA attribute of
    of 0xfe which is currently not defined.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway handles large transform list during Phase 2 ike.tcl ike_321 Verify gateway handles large transform list during Phase 2


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Phase 1
    step 4. Verify Phase 1 exchange completes
    step 5. Initiate Phase 2 with 11 transforms
    step 6. Verify Phase 2 exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify new Phase 2 can be established with SA Lifetime using both seconds and bytes ike.tcl ike_330 Verify new Phase 2 can be established with SA Lifetime using both seconds and bytes


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange
    step 4. Initiate a new Phase 2 exchange using an SA lifetime that
            includes attributes for SA Life Type of both seconds and bytes
    step 5. Verify Phase 2 exchange is successful
    step 6. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify Phase 2 SA setup using small Nonce sizes (8) ike.tcl ike_350 Verify Phase 2 SA setup using small Nonce sizes (8)


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using a Nonce size of 8
    step 4. Verify Phase 1 is successful
    step 5. Initiate a new Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: IKE implementations must support Nonce sizes from 8 to 256 bytes.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify Phase 2 SA setup using large Nonce sizes (256) ike.tcl ike_351 Verify Phase 2 SA setup using large Nonce sizes (256)


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate a new Phase 1 exchange using a Nonce size of 256
    step 4. Verify Phase 1 is successful
    step 5. Initiate a new Phase 2 exchange
    step 6. Verify Phase 2 is successful
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: IKE implementations must support Nonce sizes from 8 to 256 bytes.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway can act as tunnel initiator and responder at the same time ike.tcl ike_360 Verify gateway can act as tunnel initiator and responder at the same time


    step 1. Send delete for all Phase 2 and Phase 1 SAs
    step 2. Initiate traffic on the LAN to force router to initiate
            and new Phase 1 on the LAN
    step 3. Wait for Phase 1 packet on the WAN
    step 4. Initiate a new Phase 1 exchange on the WAN
    step 5. Verify Phase 1 exchange is successful
    step 6. Initiate a Phase 2 exchange
    step 7. Verify Phase 2 exchange is successful
    step 8. Verify traffic can be sent over the tunnel in both directions

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway handles Diffie-Hellman public keys with leading zeros ike.tcl ike_365 Verify gateway handles Diffie-Hellman public keys with leading zeros


    step 1. Delete all existing mainmode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode using a DH public key that starts with
            leading zeros ('00')
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: The Diffie-Hellman public value passed in a KE payload, in either a
    Phase 1 or Phase 2 exchange, MUST be the length of the negotiated
    Diffie-Hellman group enforced, if necessary, by pre-pending the
    value with zeros.

    NOTE: Some IKE implementations do not maintain the leading '00' if the
    public key that is generated starts with '00'. This leads to
    interoperablity problems since the keying material produced will not
    match on both sides.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2631 "Diffie-Hellman Key Agreement Method" Section 2.1.2: Generation of Keying Material

    https://tools.ietf.org/html/rfc2631#section-2.1.2

Test Module Name Synopsis
Verify gateway handles ephemeral Diffie-Hellman shared secret with leading zeros ike.tcl ike_366 Verify gateway handles ephemeral Diffie-Hellman shared secret with leading zeros


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP echo from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. When Main Mode is initiated, seach for a DH key pair
            based on the gateways public key that will produce a leading
            '00' for the epermeral key.
    step 6. Verify tunnel is established
    step 7. Verify traffic can be sent over the tunnel in both directions

    NOTE: The Diffie-Hellman public value passed in a KE payload, in either a
    Phase 1 or Phase 2 exchange, MUST be the length of the negotiated
    Diffie-Hellman group enforced, if necessary, by pre-pending the
    value with zeros.

    NOTE: Some IKE implementations do not maintain the leading '00' if the
    epermeral key that is generated starts with '00'. This leads to
    interoperablity problems since the keying material produced will not
    match on both sides.

    NOTE: RFC 2631 states that leading zeros MUST be preserved when computing
    the shared secret (ephemeral key). Versions based on OpenSSL may
    experience problems since the DH_compute_key function does not maintain
    any leading zeros when returning the length of the key.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 2631 "Diffie-Hellman Key Agreement Method" Section 2.1.2: Generation of Keying Material

    https://tools.ietf.org/html/rfc2631#section-2.1.2

Test Module Name Synopsis
Verify gateway accepts fragmented IKE packets ike.tcl ike_370 Verify gateway accepts fragmented IKE packets


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Set MTU of CDRouter gateway to 108 bytes
    step 4. Initiate Main Mode
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Restore default MTU
    step 9. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway accepts fragmented IKE packets in reverse order ike.tcl ike_371 Verify gateway accepts fragmented IKE packets in reverse order


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Set MTU of CDRouter gateway to 108 bytes
    step 4. Initiate Phase 1 sending IPv4 fragments in reverse order
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Restore default MTU
    step 9. Verify traffic can be sent over the tunnel in both directions


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

Test Module Name Synopsis
Verify gateway ignores IKE packets with an invalid UDP checksum ike.tcl ike_380 Verify gateway ignores IKE packets with an invalid UDP checksum


    step 1. Delete all existing Phase 2 and Phase 1 SAs
    step 2. Initiate a Phase 1 exchange including invalid UDP checksums
    step 3. Router should ignore IKE packets with invalid checksum
    step 4. Verify Phase 1 SA is not established

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409


ike-natt.tcl

IKEv1 NAT-Traversal testing

Test Module Name Synopsis
Verify gateway detects NAT and uses NAT-T in initiator mode ike-natt.tcl ike_natt_1 Verify gateway detects NAT and uses NAT-T in initiator mode


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
            is present
    step 6. Once tunnel is established, verify tunnel encapsulation is UDP
            for traffic received from VPN gateway
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using correct UDP encapsulation based
            on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
Verify gateway detects NAT and uses NAT-T in responder mode ike-natt.tcl ike_natt_2 Verify gateway detects NAT and uses NAT-T in responder mode


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Verify Main Mode exchange completes
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Verify traffic can be sent over the tunnel in both directions
    step 8. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
            is present
    step 9. Once tunnel is established, verify tunnel encapsulation is UDP
            for traffic received from VPN gateway
    step 10. Initiate traffic from LAN over tunnel
    step 11. Verify ESP traffic is using correct UDP encapsulation based
             on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
Verify gateway sends NAT-T Keep Alives in initiator mode ike-natt.tcl ike_natt_10 Verify gateway sends NAT-T Keep Alives in initiator mode


    step 1. Delete all existing Phase 1 and Phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Use NAT-T detection payload that indicates NAT in both directions
    step 6. Verify traffic can be sent over the tunnel in both directions
    step 7. Verify IKE Keep-alive packets are sent every ikeKeepAlive seconds

    NOTE: The expected IKE Keep-alive interval is configured using the testvar
    'ikeKeepAlive'. It defaults to 20 seconds based on the default recommendation
    in RFC 3948.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
Verify gateway sends NAT-T Keep-alives in responder mode ike-natt.tcl ike_natt_11 Verify gateway sends NAT-T Keep-alives in responder mode


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode
    step 4. Use NAT-T detection payload that indicates NAT in both directions
    step 5. Verify Main Mode exchange completes
    step 6. Initiate Quick Mode
    step 7. Verify Quick Mode exchange completes
    step 8. Verify traffic can be sent over the tunnel in both directions
    step 9. Verify IKE Keep-alive packets are sent every ikeKeepAlive seconds

    NOTE: The expected IKE Keep-alive interval is configured using the testvar
    'ikeKeepAlive'. It defaults to 20 seconds based on the default recommendation
    in RFC 3948.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
When floating NAT-T header is used, IKE responses are sent to source port ike-natt.tcl ike_natt_20 When floating NAT-T header is used, IKE responses are sent to source port


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode and Quick Mode
    step 4. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
    step 5. Once NAT-T is negotiated switch IKE packets to new UDP source port
    step 6. Verify IKE responses are sent back to UDP source port
    step 7. Once tunnel is established, verify tunnel encapsulation is UDP
    step 8. Initiate traffic from LAN over tunnel
    step 9. Verify ESP traffic is using correct UDP encapsulation based
            on the configured version of NAT-T


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
Allow IKE negotiations to begin on port 4500 ike-natt.tcl ike_natt_30 Allow IKE negotiations to begin on port 4500


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode using UDP source port 4500 and UDP destination port 4500
    step 4. Verify Main Mode exchange completes
    step 5. Include NAT-T Vendor ID and NAT-D payloads that indicate NAT
    step 6. Once tunnel is established, verify tunnel encapsulation is UDP
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using correct UDP encapsulation based
             on the configured version of NAT-T

    NOTE: The test can only be run if the NAT-T version is greater draft-00.
    Draft-00 only allowed the original IKE port of 500.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
No UDP encapsulation when NAT not detected in initiator mode ike-natt.tcl ike_natt_40 No UDP encapsulation when NAT not detected in initiator mode


    step 1. Delete all existing phase 1 and phase 2 SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Send ICMP Echo Request from the LAN that matches the tunnel destination
    step 4. Wait up to 120 seconds for tunnel to be established
    step 5. Include NAT-T Vendor ID and matching NAT-D payloads that
            indicate NAT is not present
    step 6. Once tunnel is established, verify tunnel encapsulation is
            tunnel and not UDP encapsulated
    step 7. Initiate traffic from LAN over tunnel
    step 8. Verify ESP traffic is using native ESP encapsulation

    NOTE: When NAT is not detected based on the NAT-D payloads,
    UDP encapsulation should not be used.

    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Test Module Name Synopsis
No UDP encapsulation when NAT not detected in responder mode ike-natt.tcl ike_natt_41 No UDP encapsulation when NAT not detected in responder mode


    step 1. Delete all existing Main Mode and Quick Mode SAs for the tunnel
    step 2. Send a DELETE Notification for each SA
    step 3. Initiate Main Mode with NAT-T VID
    step 4. Use matching NAT-D payloads so that no NAT is detected
    step 5. Initiate Quick Mode
    step 6. Verify Quick Mode exchange completes
    step 7. Once tunnel is established, verify tunnel encapsulation
    step 8. Initiate traffic from LAN over tunnel
    step 9. Verify ESP traffic is using native ESP encapsulation
            instead of UDP encapsulation

    NOTE: When NAT is not detected based on the NAT-D payloads,
    UDP encapsulation should not be used.


    References:

    IETF RFC 2409 "The Internet Key Exchange (IKE)"

    https://tools.ietf.org/html/rfc2409

    IETF RFC 3947 "Negotiation of NAT-Traversal in the IKE"

    https://tools.ietf.org/html/rfc3947

    IETF RFC 3948 "UDP Encapsulation of IPsec ESP Packets"

    https://tools.ietf.org/html/rfc3948

Contents

×

About CDRouter

QA Cafe CDRouter is a comprehensive and powerful test automation solution focused on feature, security, and performance testing for broadband and enterprise edge gateways, Wi-Fi and mesh systems, and other CPE.

Get in touch via our Contact page or by following us on your favorite service: