IPSec Static Virtual Tunnel Interface

Lessons Discussion
43

Hello,

I noticed in the lesson “Cisco IPsec Tunnel Mode Configuration” we didn’t configure any tunnel interface and i’m not sure i understand correclty.

Is that correct to say:

  • “Cisco IPsec Tunnel Mode Configuration”: We use IPsec Tunnel mode so IPsec will create the new header without the need for a tunneml interface. The source IP for the new header will be the IP of the interface where we apply the crypto map. The destination IP of the new header will be the one configured with the set peer inside the crypto map
  • “Encrypted GRE Tunnel with IPSEC”: In that case we want to use a GRE tunnel so we need to configure the tunnel on the interface. GRE will be adding the new header, IPsec will just be used for encryption, so we use IPsec transport mode
  • “IPSec Static Virtual Tunnel Interface”: This is similar to “Cisco IPsec Tunnel Mode Configuration” but with this newer method, we need to apply an IPsec profile on a tunnel interface. So we create a tunnel but we specify we will not use the standard GRE but IPsec.

Thanks,

44

Hello David

Yes you are correct in your descriptions. These are all different methods of emplying encryption on traffic that is exchanged between two routers. The IPsec tunnel mode solution is policy based. In this case, the traffic is sent through the IPSec tunnel based on an ACL that defines what traffic is to be protected by the IPSec tunnel. It doesn’t create a virtual tunnel interface in the routing table of the router.

The IPsec Static VTI however operates a bit differently. It’s a route-based IPSec VPN method where the tunnel is seen as a point-to-point connection. Static VTI allows for routing protocols to run over the IPSec tunnel. The tunnel is considered as an interface, so it can be assigned an IP address, included in the routing process, and even support dynamic routing protocols and multicast routing.

I hope this has been helpful!

Laz

45

Hi In EVE NG routes tunnel line protocol is down after adding tunnel mode ipsec ipv4
is any one facing same issue. Please let me know the solution.

46

Hello Ravishankar

If your tunnel is going down after the tunnel mode ipsec ipv4 command, it may be due to a missing or incorrect configuration somewhere in the setup. There is no easy way to determine what this may be, you will have to perform some troubleshooting steps to determine why this is happening. Ensure that your configs on both devices are set correctly. You can also use some debug commands to determine the reason why the tunnel interface is going down. Some of these include:

  • debug crypto isakmp
  • debug crypto ipsec
  • debug crypto engine

Some additional show commands that can help you out include:

Let us know how you get along, and inform us of your findings so that we can help you further.

I hope this has been helpful!

Laz

48

Hi,
I reproduced the lab with EVE-NG and IOL 17.12.1.
When trying to ping H2 from H1 packets are dropped on R1 with the following message:

R1#
*Sep 30 15:34:55.381: CEF-Drop: Packet from 192.168.1.100 (Et0/1) to 192.168.2.254, adjacency fixup

I activated debug ip cef drops on R1 to get this message.

Any idea ?
BR, Damien.
---
Sorry .. just solved ! by removing ip cef from R1 and R2 :wink:
May be an issue related to the IOL I’m using ?
BR, Damien.

49

Hello Damien

Thanks for sharing your solution with us… Just a comment on the particular error message you’re getting. This is a somewhat common issue that is encountered when using CEF. The “adjacency fixup” message typically indicates that CEF couldn’t properly find an entry for the next-hop address in its adjacency table, leading to packet drops.

Removing ip cef resolved the issue because it forces the router to revert to process switching, which may handle the packets differently, particularly in simulation environments like EVE-NG with specific IOS versions. But I’m still not quite sure of the reason for your original CEF malfunction. It could be due to incompatibility of the IOS, or maybe some CEF parameter that was configured? If you’re interested, consider doing some troubleshooting with CEF activated, we’d be interested in hearing your results…

I hope this has been helpful!

Laz

50

Hi Team,

Why is Identity NAT for route-based VPN not required as it appears in the policy-based VPN?

51

Hello Po

It all comes down to where and how traffic is processed in eavh VPN type. Specifically, it has to do with the interaction between the routing decision, NAT operations, and the IPsec encryption engine.

On a Cisco IOS router, when traffic flows from an inside interface to an outside interface, operations occur in this order:

  1. routing
  2. NAT
  3. Crypto (IPsec)

(for more on NAT order of operations, take a look at this Cisco documentation)

This ordering is the root cause of the difference.

In Policy-Based VPNs, identity NAT is required because there is no logical tunnel interface. Both regular traffic and VPN-bound traffic are routed out of the same physical WAN interface, which has ip nat outside configured. Because the egress interface is the physical WAN interface, the NAT engine is invoked and will translate the private source IP (e.g., 192.168.1.x) to the router’s public IP. The crypto map ACL (which expects the original private source IP) is checked after NAT has already changed the source address. The result is that the translated packet no longer matches the crypto ACL and the traffic is not encrypted, and either gets sent unencrypted to the Internet or gets dropped.

Identity NAT is used to fix this, to tell the NAT engine “Do not translate traffic destined for the remote VPN subnet.” This preserves the original addresses so the crytpo ACL can match them correctly and encryption proceeds as it should.

When using route-based VPNs (VTIs etc) identity NAT is not required because a logical tunnel interface is created, and the IPsec profile is applied to it via the tunnel protection ipsec profile command. Routing directs traffic destined to the remote subnet via the tunnel interface (i.e. Tunnel0) before it ever reaches the physical outside interface where NAT is configured and applied. Because the Tunnel interface is not configured with ip nat outside, the NAT process is completely bypassed for the inner (payload) traffic.

The IPSec engine encrypts the packet at the tunnel interface. The resulting encrypted outer ESP packet (sourced from the tunnel endpoints’ public IPs) is then routed out the physical WAN interface, but this outer packet is already encapsulated and requires no exemption.

The result is that no Identity NAT is needed because VPN traffic is never presented to the NAT engine on the physical outside interface in the first place.

I hope this has been helpful!

Laz