May
28

In a recent post here on the INE blog, we received some follow-up questions similar to the following:

“Why do IPSec peers end up using tunnel mode, even though we had explicitly configured transport mode in the IPSec transform-set?”

It is an excellent question, and here is the answer.   In a site to site IPSec tunnel the “mode transport”  setting is only used when the traffic to be protected (traffic matching the Crypto ACLs) has the same IP addresses as the IPSec peers, and excludes all other IP addresses.   When Crypto ACLs include IP addresses beyond of the 2 peer endpoints the “mode transport” setting is ignored, and tunnel mode is negotiated (due to IP addresses, other than the 2 peers, being part of the crypto ACL).       There is also an option for the key word “require” after “mode transport” which will prevent the peers from negotiating tunnel mode, and if the IP addresses in the Crypto ACLs are outside of the peers’s own IP addresses, IKE phase 2 will not successfully complete.

One notable exception to this, is GET VPN, where the KS policy of tunnel mode or transport mode will be used by the group members (whichever mode the KS has configured), regardless of the IP addresses used in the KS ACL for policy.

Below is a site to site example.  Let’s use the following topology, with R1 and R3 being peers, and a Crypto ACL that says to encrypt all ICMP traffic, regardless of the IP addresses.   This Crypto ACL will cause our peers to ignore the mode transport option, and negotiate tunnel mode.

3 routers in a row-NO-user

Below are the full configs, some debug output, and show commands to demonstrate that even with transport mode explicitly configured in the transform sets, if the crypto ACLs don’t exclusively include the endpoints of the VPN tunnel, the two peers go ahead and negotiate tunnel mode instead of transport mode.  Note the Crypto ACL includes all ICMP from any source to any destination.

First, here is R1:

R1#show run
!
hostname R1
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
mode transport
!
crypto map MYMAP 10 ipsec-isakmp
set peer 23.0.0.3
set transform-set MYSET
match address 100
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
crypto map MYMAP
!
router ospf 1
log-adjacency-changes
network 0.0.0.0 255.255.255.255 area 0
!
!
access-list 100 permit icmp any any
!
end

Now for R3

R3#show run
!
hostname R3
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
mode transport
!
crypto map MYMAP 10 ipsec-isakmp
set peer 10.0.0.1
set transform-set MYSET
match address 100
!
interface FastEthernet0/1
ip address 23.0.0.3 255.255.255.0
crypto map MYMAP
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
access-list 100 permit icmp any any
!
end
R3#

Let’s enable debug of crypto isakmp, and send a couple sets of PING requests from R3 to R1

R3#debug crypto isakmp
Crypto ISAKMP debugging is on

R3#ping 10.0.0.1 source 23.0.0.3 repeat 10

Here is the relevant portion of the debug output:

ISAKMP (0:1001): received packet from 10.0.0.1 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1001): processing HASH payload. message ID = 1137801467
ISAKMP:(1001): processing SA payload. message ID = 1137801467
ISAKMP:(1001):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP: encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
SAKMP:      authenticator is HMAC-SHA
ISAKMP:      key length is 128
ISAKMP:(1001):atts are acceptable.

To verify the tunnel mode is in place, we can look at the details of the SA:

R3# show crypto ipsec sa

interface: FastEthernet0/1
    Crypto map tag: MYMAP, local addr 23.0.0.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/1/0)
   current_peer 10.0.0.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
    #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0

     local crypto endpt.: 23.0.0.3, remote crypto endpt.: 10.0.0.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/1
     current outbound spi: 0x96474B70(2521254768)

     inbound esp sas:
      spi: 0x59B117E1(1504778209)
        transform: esp-aes esp-sha-hmac ,
 in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: MYMAP
        sa timing: remaining key lifetime (k/sec): (4399136/3319)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x96474B70(2521254768)
        transform: esp-aes esp-sha-hmac ,
 in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: MYMAP
        sa timing: remaining key lifetime (k/sec): (4399136/3319)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Thanks for the question, and best wishes in all of your studies!

 


You can leave a response, or trackback from your own site.

10 Responses to “When “transport mode” becomes “tunnel mode”, free of charge.”

 
  1. anna says:

    Hi Kieth

    crypto isakmp key cisco address 0.0.0.0 0.0.0.0

    I am confused with this statement

    Shouldn’t it be the peer address of R3 if we are configuring from R1 and vice versa

    Sorry for the trouble

    Please clarify

    Regards
    anna

  2. [...] http://blog.ine.com/2010/05/28/when-transport-mode-becomes-tunnel-mode-free-of-charge/#more-3943 -> I bet this is a “gotcha” even after choosing the transform-set as “transport mode”, it reverts to tunnel. [...]

  3. Kingsley Charles says:

    Hi,

    Great explanation.

    Why do we need tunnel mode for GETVPN? Cisco claims that GETVPN preserves the IP header attributes.

    Even if you use transport mode, the result would be same right?

    Any benefit in using tunnel mode for GETVPN?

    With tunnel mode, one thing is that the original IP address is authenticated. With transport mode, the IP header is not authenticated.

  4. praveen says:

    Hi,

    Its outstanding when i read something i like this. So closely you experts watch. I used to learn and practise i never used to watch what is really happening. After attending many interview questions i understand i should have deep knowledge.

    Regards,
    Praveen

  5. Jsteve says:

    Great read. One quick follow up question comes to mind. When labing up SVTI, which does not require proxy ACLs. The local and remote ident’s will allways be 0.0.0.0/0, therefore tunel mode will always negotiate. Is there any way to force transparent mode?

  6. Rewan says:

    Hi,

    When i say mode transport require, define the Crypto ACL from other IP address than peers, still i get the tunnel mode working. Can u pls clarify.

    Building configuration…

    Current configuration : 1249 bytes
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname R2
    !
    boot-start-marker
    boot-end-marker
    !
    !
    no aaa new-model
    !
    resource policy
    !
    memory-size iomem 5
    ip subnet-zero
    !
    !
    ip cef
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    crypto isakmp policy 10
    encr aes
    authentication pre-share
    group 2
    lifetime 6000
    crypto isakmp key 6 mySecret address 192.168.1.1
    !
    !
    crypto ipsec transform-set mySet esp-aes esp-sha-hmac
    mode transport require
    !
    crypto map R1_R2 10 ipsec-isakmp

    set peer 192.168.1.1
    set transform-set mySet
    match address 101
    !
    !
    !
    !
    interface Loopback1
    ip address 172.16.2.1 255.255.255.0
    !
    interface FastEthernet0/0
    ip address 192.168.1.2 255.255.255.252
    duplex auto
    speed auto
    crypto map R1_R2
    !
    interface FastEthernet0/1
    no ip address
    shutdown
    duplex auto
    speed auto
    !
    ip http server
    no ip http secure-server
    ip classless
    ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
    ip route 172.16.2.0 255.255.255.0 FastEthernet0/0
    ip route 172.16.4.0 255.255.255.0 FastEthernet0/1
    !
    !
    !
    !
    !
    !
    !
    control-plane
    !
    !
    !
    !
    !
    !
    !
    !
    !
    line con 0
    logging synchronous
    line aux 0
    line vty 0 4
    !
    !
    end

    _————————————————————-

    Building configuration…

    Current configuration : 1263 bytes
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname R1
    !
    boot-start-marker
    boot-end-marker
    !
    !
    no aaa new-model
    !
    resource policy
    !
    memory-size iomem 5
    ip subnet-zero
    !
    !
    ip cef
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    crypto isakmp policy 10
    encr aes
    authentication pre-share
    group 2
    lifetime 6000
    crypto isakmp key 6 mySecret address 192.168.1.2
    !
    !
    crypto ipsec transform-set mySet esp-aes esp-sha-hmac
    mode transport require
    !
    crypto map R1_R2 10 ipsec-isakmp
    set peer 192.168.1.2
    set transform-set mySet
    match address 101
    !
    !
    !
    !
    interface Loopback1
    ip address 172.16.1.1 255.255.255.0
    !
    interface FastEthernet0/0
    ip address 192.168.1.1 255.255.255.252
    duplex auto
    speed auto
    crypto map R1_R2
    !
    interface FastEthernet0/1
    ip address 172.16.3.1 255.255.255.0
    duplex auto
    speed auto
    !
    ip http server
    no ip http secure-server
    ip classless
    ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
    ip route 172.16.4.0 255.255.255.0 FastEthernet0/1
    !
    !
    !
    access-list 101 permit ip 10.1.1.0 0.0.0.255 172.16.2.0 0.0.0.255
    !
    !
    !
    !
    control-plane
    !
    !
    !
    !
    !
    !
    !
    !
    !
    line con 0
    logging synchronous
    line aux 0
    line vty 0 4
    !
    !
    end

    —————————————

    Regards,

    Rewan

  7. Rewan says:

    i would like to add acl in missing config.

    access-list 101 permit ip 172.16.2.0 0.0.0.255 10.1.1.0 0.0.0.255

    tnkx

  8. roger sambora says:

    Hi:

    When tunnel mode is ipsec ipv4, is the result the same?

    Will you also be doing a doc like this for ipsec ipv4?

    Thx.

    Roger

  9. Hi

    Great article! I’ve spent the evening trying to take the pulse of the IPv6 community on the best way smaller organizations can / should configure IPSEC SAs between IPv6 subnets from different ISPs.

    I ended up here after coming up short.

    For example, an organization that gets two /48s from two different co-location or WAN providers.

    To avoid the use of IPv6 unique local space, transport mode IPsec seems most appropriate (Whether IOS upgrades it to a ‘tunnel’-mode because the qualifying IPv6 ACL matches on /48s) ; but it seems that everyone seems to have their panties in a bunch over MPLS instead.

    Of course, that requires locking in on a vendor-neutral facility .. :)

  10. Sri says:

    Well done for giving a practical explanation. Many thanks to INE.

 

Leave a Reply

Categories

CCIE Bloggers