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.
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.
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:
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…
