IPSec Static Virtual Tunnel Interface

Why do we need both “tunnel mode ipsec ipv4” and “tunnel protection ipsec profile” commands?

I removed the “tunnel mode ipsec ipv4” but the packets are still being encrypted.

Hello Yuta

Each of the commands you mentioned provide different features for the tunnel. The tunnel mode ipsec ipv4 command is the one that defines the mode for the tunnel. More specifically, this command enables IPSec encapsulation.

The tunnel protection ip sec profile command is used to tie in the IPSec profile created earlier. This is where the encryption parameters are defined and applied.

It is for this reason that when you removed the tunnel mode ipsec ipv4 command that the packets are still encrypted.

It is possible to have tunnel mode gre which is the default and apply the tunnel protection ip sec profile command and successfully have an encrypted tunnel.

I hope this has been helpful!

Laz

Hi Laz,

Thank you for your reply.
Hmm, then what does “tunnel mode ipsec ipv4” do? If the packets are encrypted without this command why do we have this command?

Regards,

Yuta

Hello Yuta

So to reiterate, the tunnel mode ipsec ipv4 command configures the encapsulation. What does that mean? It may help to take a look at what we mean when we say encapsulation.

Now there is the option that I spoke about before, where you can use the following commands:

tunnel mode gre
tunnel protection ipsec profile profile_name

and the tunnel would be encrypted. This is because the first command deals with encapsulation while the second deals with the encryption.

Now if the commands are as follows:

tunnel mode ipsec ipv4
tunnel protection ipsec profile profile_name

then the encapsulation is ipsec as well. Now the IPSec encapsulation involves the entire original IP packet being encapsulated with a new packet header added. Protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected.

I hope this has been helpful!

Laz

Hi Laz,

Thank you for the explanation.
Please correct me if I am misunderstanding here. If the encapsulation is ipsec, then it means encrypting the original packets twice one with “tunel mode ipsec ipv4” and then “tunnel protection” command for second encryption while if we choose to use gre as encapsulation encryption is done on the whole gre and original packets?

Also would you please teach me how to decide which encapsulation type we should be using?

Regards,

Yuta

Hello Yuta

IPSec functions in two modes. Tunnel mode and transport mode. Tunnel mode is when IPSec is the protocol that is used for tunneling and for encapsulation. This is the case when we configure the following:

tunnel mode ipsec ipv4
tunnel protection ipsec profile profile_name

where the profile as shown in the lesson chooses to use the tunnel mode for IPSec.

Whenever you choosetunnel mode ipsec ipv4 it is necessary to include the type of encapsulation mechanisms that you will use by indicating the tunnel protection command as well. These two commands together will have the result of implementing an IPSec Tunnel Mode connection. The first indicating the tunnel mode and the second indicating the way in which that tunnel mode will be implemented.

Now, if you were to use these two commands:

tunnel mode gre
tunnel protection ipsec profile profile_name

then you are configuring a GRE tunnel with IPSec protection. This essentially is configuring IPSec in transport mode. In this case, the correct configuration would be to change the profile to indicate mode transport.

IPSec transport mode is usually used when another tunneling protocol (like GRE) is used to first encapsulate the IP data packet, then IPSec is used to protect the GRE tunnel packets. IPSec protects the GRE tunnel traffic in transport mode.

The following image gives us an idea of the difference between the modes.

image

More information about these modes can be found at the following introductory lesson to IPSec:
https://networklessons.com/cisco/ccie-routing-switching-written/ipsec-internet-protocol-security/

Now how do you decide which case to use? Well, take a look at the characteristics of each:

  • IPSec encapsulation does not support multicast
  • GRE does support multicast
  • IPSec is more complex to configure
  • GRE is less complex
  • IPSec includes security for the headers
  • GRE does not include any security but payload only can be encrypted with IPSec transport mode
  • GRE supports multiple Layer 3 protocols while IPSec only supports IP

These are just some of the characteristics of these two options, and based on those, you can choose what’s best for your application. Using IPSec in tunnel mode is by far the safest, but it does have drawbacks as seen above. GRE is most efficient, but it does have some security issues even when used with IPSec transport mode.

I hope this has been helpful!

Laz

1 Like

Hi there,
please, I need a clarification, is it true that we cannot use IPSec with DVTI/VTI and IPSec with crypto-map and access-lists in the same router? Let says we have one hub and two spokes topology, can we configure one spoke with IPSec using VTI and the other spoke with crypto-map and access-lists, then setting up the hub router to handle the two spokes, is it possible?
Within waiting for your insights, I will try to lab this on GNS3.

Hi Thierry,

I never tried this before so I’m not sure. Have you labbed it up yet?

Rene

Hi ,
I try in virtaul lab same as you config but i don’t know why host 1 cannot ping host 2.Router to Router can ping.Host to host cannot reach

Hello Ko

We’re sorry to hear that you’re having trouble. The only thing that I can say to help you is to verify that the configs are indeed correct. Can you share some of your configurations with us so we can take a look?

Laz

Hi, please can we have some usefull debug command for VPN troubleshooting ?

Hello Thierry

Take a look at this Cisco documentaiton. I believe it is quite thorough in its explanations:

I hope this has been helpful!

Laz

Hello Laz,

With respect to your pros and cons, I was able to setup the tunnels with the commands below
tunnel mode ipsec ipv4
tunnel protection ipsec profile ipsec
while running ospf and was able to establish neighbourship over the tunnel and have my pings encrypted. I am using IOSv 15.6.
Any thoughts on this with regarding multicast over ipsec tunnel mode and not GRE.

Hello Tariq

You touch on several issues with your post. First of all, IPSec direct encapsulation supports only unicast traffic. It has been designed to provide connections between only two devices, so multicast is problematic. In order to get multicast (and thus routing protocols such as OSPF which leverage multicast to operate) to function, you essentially have two choices:

  1. IPSec encrypted GRE tunnel
  2. IPSec VTI

The first is a somewhat more legacy solution, although it works very well. GRE supports multicast so OSPF and other routing protocols can function. The second, which you configured in your setup, is considered a newer method of implementation for site-to-site VPNs and is preferable due to the fact that it is simpler to employ, since you don’t have to set up complex access lists and crypto maps to define the traffic to encrypt.

Both will get you the result you need for multicast traffic, however, the latter is the simpler and more elegant choice.

I hope this has been helpful!

Laz

Hello Lazaros,

I’m stuck in this topic related lab. I’m trying to make an IPsec site to site connection between a CSR (on AWS) and a cyberoam FW (on prem). Since in AWS VPC NATS the traffic to CSR, therefore the packets are encapsulated over UDP on port 4500. The tunnels both side comes up however I’m not able to ping the tunnel interface nor the local subnets behind the CSR and Cyberoam FW.

However if the NAT-T is not assumed (in my lab) i.e. CSR interface is having static public ip and Cyberoam FW is also having static public IP then the static tunnel interface comes up and able to ping each other and also BGP adjacency forms.

show crypto isa sa

Interface: Tunnel1
Profile: IPROF
Session status: UP-ACTIVE     
Peer: 192.4.10.2 port 4500 
  Session ID: 0  
  IKEv1 SA: local 10.11.0.2/4500 remote 192.4.10.2/4500 Active 
  Session ID: 0  
  IKEv1 SA: local 10.11.0.2/4500 remote 192.4.10.2/4500 Active 
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0 
        Active SAs: 2, origin: crypto map
CSR2#sh cry ip sa peer 192.4.10.2

interface: Tunnel1
    Crypto map tag: Tunnel1-head-0, local addr 10.11.0.2

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

     local crypto endpt.: 10.11.0.2, remote crypto endpt.: 192.4.10.2
     plaintext mtu 1422, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x962C9052(2519502930)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x75622E80(1969368704)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2003, flow_id: CSR:3, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4607999/3427)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x962C9052(2519502930)
        transform: esp-aes esp-sha-hmac ,
        in use settings ={Tunnel UDP-Encaps, }
        conn id: 2004, flow_id: CSR:4, sibling_flags FFFFFFFF80000048, crypto map: Tunnel1-head-0
        sa timing: remaining key lifetime (k/sec): (4607998/3427)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)
          
     outbound ah sas:

     outbound pcp sas:
CSR2#sh cry isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.11.0.2       192.4.10.2      QM_IDLE           1002 ACTIVE
192.4.10.2      10.11.0.2       QM_IDLE           1001 ACTIVE

please can you help me troubleshoot where the problem could be?

Thanking in advance.

Hi Zeeshan,

What does your CSR1000V config look like? Even with elastic IP, AWS still uses NAT so you’ll have to deal with NAT-T. I never tried a VPN like this but I can take a look.

Rene

Hi Rene,

Many thanks for your response.

Yes, correct about NAT on AWS, this is why in this lab I later introduced a Router (VPC) performing NAT to simulate the AWS environment.

Please see below config of CSR in this virtual lab on eve. The tunnel 0 which is between CSR and ASAv works as expected. i.e. tunnel IPs are able to ping each other and BGP is forming. But on the other hand CSR and Cyberoam tunnels are UP but can’t ping each other.

Tunnel 0 = ASAv
Tunnel 1 = Cyberoam FW

interface Tunnel1
 ip address 15.15.16.1 255.255.255.0
 ip tcp adjust-mss 1372
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 192.4.10.2
 tunnel protection ipsec profile IPSECPROF
 ip virtual-reassembly

interface Tunnel0
 ip address 15.15.15.1 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 192.2.10.2
 tunnel protection ipsec profile IPSECPROF



  crypto keyring KEY_RING  
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp profile IPROF
   keyring KEY_RING
   match identity address 0.0.0.0 
crypto ipsec transform-set TSET esp-aes esp-sha-hmac 
 mode tunnel
crypto ipsec profile IPSECPROF
 set transform-set TSET 
crypto map MYMAP 10 ipsec-isakmp 
 set peer 192.3.10.2
 set transform-set TSET 
 match address 101


router bgp 65000
 bgp router-id 15.15.15.15
 bgp log-neighbor-changes
 network 10.40.40.0 mask 255.255.255.0
 neighbor 15.15.15.2 remote-as 65001
 neighbor 15.15.16.2 remote-as 65002
 neighbor 15.15.19.2 remote-as 65003
!


ip route 0.0.0.0 0.0.0.0 10.11.0.1
ip route 172.16.16.0 255.255.255.0 Tunnel1
ip route 172.16.19.0 255.255.255.0 Tunnel2

Gateway of last resort is 10.11.0.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.11.0.1
      4.0.0.0/32 is subnetted, 1 subnets
C        4.2.2.2 is directly connected, Loopback4222
      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.11.0.0/24 is directly connected, GigabitEthernet1
L        10.11.0.2/32 is directly connected, GigabitEthernet1
C        10.40.40.0/24 is directly connected, GigabitEthernet2
L        10.40.40.1/32 is directly connected, GigabitEthernet2
      15.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C        15.15.15.0/24 is directly connected, Tunnel0
L        15.15.15.1/32 is directly connected, Tunnel0
C        15.15.16.0/24 is directly connected, Tunnel1
L        15.15.16.1/32 is directly connected, Tunnel1
C        15.15.19.0/24 is directly connected, Tunnel2
L        15.15.19.1/32 is directly connected, Tunnel2
      172.16.0.0/24 is subnetted, 3 subnets
S        172.16.16.0 is directly connected, Tunnel1
B        172.16.17.0 [20/0] via 15.15.15.2, 00:34:07
S        172.16.19.0 is directly connected, Tunnel2

CSR2#ping 15.15.15.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.15.15.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/10/11 ms
CSR2#

CSR2#ping 15.15.16.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 15.15.16.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Thanks again for looking into this. I hope you can pin point the issue in the config.
Regards,
Zeeshan

hi ,

with virtual tunnel interface i can use routing protocol …for example if i use ospf protocol under ospf process i need to specify the network of the tunnel or the interface?

thanks !

Hello Andrea

IPSec is not capable of supporting routing protocols due to the fact that it only encapsulates unicast traffic. Dynamic routing protocols such as OSPF or EIGRP will use multicast communication to operate. Based on several instances in Cisco documentation, a static VTI can be used to allow routing protocols to form neighbor adjacencies in order to allow a dynamic routing protocol to function in such a topology. I have also labbed it up and found that OSPF does form a neighbor adjacency between R1 and R2, and the 192.168.1.0/24 and 192.168.2.0/24 subnets are shared between the routers.

Now in order to make the adjacency work, you must include the network of the tunnel interfaces in the network command of OSPF, and not of the actual physical interfaces. Now having said that, in a real world example, the two sites would be remote to each other, and the physical interfaces of the routers would be connected to some edge network device that connects to a WAN or to the internet. The routing between these two physical interfaces is considered already functional (via the ISP providing the WAN or internet connection). Therefore, the dynamic routing protocol should be enabled on the tunnel interface.

Remember that from the point of view of the hosts, there is no 192.168.12.0/24 subnet, and no routing to this subnet is possible. All traffic from H1 to H2 is tunnelled over that subnet, using the 12.12.12.0/24 subnet, therefore the tunnel interfaces should be used in the network command of OSPF.

I hope this has been helpful!

Laz

1 Like

Hi Zeeshan,

I loaded up your configs on two IOS routers, with a NAT router in between. It works without issues, I can’t see anything wrong with your config.

It can be difficult to find out why IPSec between two different vendor devices doesn’t work. When you look at the packets received/transmitted, do you see anything?

R1#show crypto ipsec sa | include pkts
    #pkts encaps: 153, #pkts encrypt: 153, #pkts digest: 153
    #pkts decaps: 124, #pkts decrypt: 124, #pkts verify: 124

Check whether packets from your IOS router make it to the Cyberoam firewall, and vice versa. This might help to figure out whether this is an IPSec or routing issue. Do you see the UDP header from both ends?

If it’s an IPSec issue, try a debug to see why the packets are refused. If it works without NAT, I’d guess it’s a routing issue.

Rene