IPsec VPN between two routers - ESP Transport mode and Tunnel mode

[Difan Zhao]

Hi experts,

I have this question about the Transport mode and Tunnel mode for a while.

Based on my understanding "Tranport" mode won't be possible because you will always have "internal" or private IP addresses in the original IP headers. They are always different than the Public IP addresses on the interfaces enabled with Crypto MAP. When encapsulated in the VPN tunnel, the internal IP addresses must be included or the remote VPN router won't know where to forward the packet.

In order to test I built a simple GNS3 lab with three routers. R1 and R3 are configured as VPN routers and the R2 is to simulate Internet.

My configs are very basic too. The R2 is routing between 1.1.1.0/24 and 2.2.2.0/24. It's set as gateway of R1 and R3.

R1:

crypto isakmp policy 100
encr aes
authentication pre-share
group 2
crypto isakmp key 123456 address 2.2.2.2
!
crypto ipsec transform-set ESP_null esp-null esp-sha-hmac
!
crypto map MAP 10 ipsec-isakmp
set peer 2.2.2.2
set transform-set ESP_null
match address VPN

!

ip access-list extended VPN
permit ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255
!

R3:

crypto isakmp policy 100
encr aes
authentication pre-share
group 2
crypto isakmp key 123456 address 1.1.1.2
!
!
crypto ipsec transform-set ESP_null esp-null esp-sha-hmac
!
crypto map MAP 10 ipsec-isakmp
set peer 1.1.1.2
set transform-set ESP_null
match address VPN

!

ip access-list extended VPN
permit ip 10.0.0.0 0.0.0.255 192.168.1.0 0.0.0.255

I configured transform-set to "null" so it won't encrypt the traffic.

Then I tried both "transport" mode and "tunnel" mode. I pinged from one host in the R1's internal network to another host in the R3's internal network. I also tried "telnet". I also captured the packets and carefully compared them in the two modes.

The packets are encapsulated exactly the same way!!!

It's just SPI + Sequence No. + <orignal IP Packet> + padding

I will attach my captures here for you guys to analyze. I'd appreciate any explaination. I maybe just confused when the NAT is involved...

I guess my next step is to check if the two modes make a difference when GRE is used.

Thanks,

Difan

[Marcin Latosiewicz · Accepted solution]

Hi Difan,

As you point out transport mode is not always applicable (i.e. it's applicable if IP of source and destination are equal to corresnpoding proxy IDs).

A typical scenario in this transport mode is used:

- Encryption between two hosts

- GRE tunnels

- L2TP over IPsec

Even if you set "mode transport" it doesn't mean that it will be the one used. IOS routers and I blieve also ASA will perform fallback to tunnel mode even if transport mode is configured but not applicable.

I can have a look at your sniffer traces, but first of all can you please check if you did have transport mode on your ipsec sas? "show crypto ipsec sa" output will show you either tunnel or transport mode.

HTH,

Marcin

[Difan Zhao]

Hi Marcin,

You are right! In the "show crypto ipsec sa" I see that it's still operating in the tunnel mode even I configured it to be in the "transport" mode.

...

     inbound esp sas:
      spi: 0x72545220(1918128672)
        transform: esp-null esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: SW:1, crypto map: MAP
        sa timing: remaining key lifetime (k/sec): (4539567/3541)
        IV size: 0 bytes
        replay detection support: Y
        Status: ACTIVE

...

     outbound esp sas:
      spi: 0x273759B9(657938873)
        transform: esp-null esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: SW:2, crypto map: MAP
        sa timing: remaining key lifetime (k/sec): (4539567/3541)
        IV size: 0 bytes
        replay detection support: Y
        Status: ACTIVE

I guess I will just assume that the IOS automatically "fix" it for me in this scenario lol

Thanks for the clarification!

Difan