When "transport mode" becomes "tunnel mode", free of charge.

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!