Cisco IPsec Tunnel Mode Configuration

Hello Sovandara,

I understand this is confusing. When you don’t specify a value in the ISAKMP policy, it will use a default value. For example:

R1(config)#crypto isakmp policy 1
R1(config-isakmp)#encryption aes
R1(config-isakmp)#authentication pre-share 
R1(config-isakmp)#group 2

Now check the running configuration but make sure you add the “all” parameter. This shows all default (hidden) values:

R1#show run all | begin crypto isakmp
crypto isakmp policy 1
 encr aes
 hash sha
 authentication pre-share
 group 2
 lifetime 86400

As you can see above, the default hashing algorithm is sha. I’ll edit the lesson so others don’t tumble over this.


Hi Rene !
Can you describe the function of hashing algorithm ?

I’m really confuse about it.

Hello Heng

A hash function is a function or algorithm that can be used to map data of any size to a set of data of fixed size. So you can for example take various names of various lengths, process them through a hash function and come up with a set of data of fixed size, two digits for example, as shown in the following diagram:
The input of a hash function is called a key and the output is called a hash.

Hash functions can be useful in cryptography if they are a one way function. That is, if it is only possible to determine the hash from the key and not the other way around. Why is this useful? Imagine you and I want to verify each other’s identity. I have a key and you have that same key, but we want to keep that key private. I can verify my identity to you by posting that key on this forum, but that would reveal the key. What I can do is share the hash function with you. Then I can send you the hash of my key on the forum. You can then compare that with the hash of your key to see if it is the same. But I haven’t revealed the key on the forum, and since the hash function is a one way function, no one can reverse engineer the hash to find the key. In this way, I have authenticated my identity to you without actually sending the private key over an insecure link. In cryptography, this is the purpose of a hash.

Does it sound familiar? If so, then it should remind you of the private and public key methodology. The hash is the public key, the key is the private key.

Essentially, hash functions allow a pair of devices to authenticate each other without having to send a private piece of information such as the password over a potentially unsecured link. This is what is happening in Rene’s example. He uses the command hash sha. This command informs the other side of the hash algorithm that should be used to verify authentication across the IPsec tunnel.

I hope this has been helpful!


1 Like

Hi Laz
Thank you it help me a lot.

1 Like

I have followed the same steps to config the ipsec tunnel.
But could not do it.I got the below debug log.But when I have tried to do this by only placing 2 router it worked.But when the third router is in the place I could not do it.

*Oct  5 12:59:14.479: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
*Oct  5 12:59:14.479: ISAKMP:(0): sending packet to my_port 500 peer_port 500 (R) MM_SA_SETUP
*Oct  5 12:59:14.479: ISAKMP:(0):Sending an IKE IPv4 Packet.
*Oct  5 12:59:14.483: ISAKMP:(0):
*Oct  5 12:59:14.483: ISAKMP:(0):Old State = IKE_R_MM1  New State = IKE_R_MM2

*Oct  5 12:59:24.419: ISAKMP (0): received packet from dport 500 sport 500 Global (R) MM_SA_SETUP
*Oct  5 12:59:24.427: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Oct  5 12:59:24.427: ISAKMP:(0):Old State = IKE_R_MM2  New State = IKE_R_MM3

*Oct  5 12:59:24.431: ISAKMP:(0): processing KE payload. message ID = 0
*Oct  5 12:59:24.471: ISAKMP:(0): processing NONCE payload. message ID = 0
*Oct  5 12:59:24.471: ISAKMP:(0):found peer pre-shared key matching
*Oct  5 12:59:24.471: ISAKMP:(1006): processing vendor id payload
*Oct  5 12:59:24.471: ISAKMP:(1006): vendor ID is DPD
*Oct  5 12:59:24.471: ISAKMP:(1006): processing vendor id payload
*Oct  5 12:59:24.475: ISAKMP:(1006): speaking to another IOS box!
*Oct  5 12:59:24.475: ISAKMP:(1006): processing vendor id payload
*Oct  5 12:59:24.475: ISAKMP:(1006): vendor ID seems Unity/DPD but major 175 mismatch
*Oct  5 12:59:24.475: ISAKMP:(1006): vendor ID is XAUTH
*Oct  5 12:59:24.475: ISAKMP:re
R2#ceived payload type 20
*Oct  5 12:59:24.475: ISAKMP (1006): His hash no match - this node outside NAT
*Oct  5 12:59:24.475: ISAKMP:received payload type 20
*Oct  5 12:59:24.475: ISAKMP (1006): No NAT Found for self or peer
*Oct  5 12:59:24.475: ISAKMP:(1006):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Oct  5 12:59:24.475: ISAKMP:(1006):Old State = IKE_R_MM3  New State = IKE_R_MM3

*Oct  5 12:59:24.475: ISAKMP:(1006): sending packet to my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Oct  5 12:59:24.475: ISAKMP:(1006):Sending an IKE IPv4 Packet.
*Oct  5 12:59:24.475: ISAKMP:(1006):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Oct  5 12:59:24.475: ISAKMP:(1006):Old State = IKE_R_MM3  New State = IKE_R_MM4

*Oct  5 12:59:24.551: ISAKMP (1006): received packet from dport 500 sport 500 Global (R) MM_KEY_EXCH
*Oct  5 12:59:24.555: ISAKMP:(1006): phase 1 packet is a duplicate of a previous packet.
*Oct  5 12:59:24.555: ISAKMP:(1006): retransmissio

Hello Kaza

In your configuration, there is no need to include R2 at all. There is no need to add a third router. The tunnel created in the lesson is only between R1 and R3. It seems a little confusing with the specific topology as it is shown in the diagram. I will talk to Rene to see if we can clarify this.

I hope this has been helpful


Thanks for the reply.

1 Like

Dear Rene,

When I enter the command “ping source loop 0” the destination IP address of the packet shows for both transport and tunnel modes.
I can understand that this is the new outer header put by IPSec for tunnel mode. But how can it be like that for transport mode? It should not change the original IP header ryt? so the destination must be ryt?

Hello Roshan

In both cases, the destination IP should be since that is the address you are pinging. However, in transport mode, there is only one IP header, in tunnel mode there are two.

In transport mode you should only see as the destination IP in the single IP header.

In Tunnel mode you should see as the destination IP in the inside IP header, and as the destination IP in the outside New IP Header. This outside header will only exist on the link between the two routers. Once it reaches the other router, that will be stripped off and the inside IP header will be used to route to the destination.

Can you clarify where you see as the destination? Is it in wireshark? If so, where are you capturing your data? Let us know and we can further analyze the scenario.

I hope this has been helpful!


You activated CRYPTOMAP on interface fa0/0, did you mean to put this on gi0/1 like your diagram above?

R3(config)#interface fastEthernet 0/0
R3(config-if)#crypto map CRYPTOMAP

Hi @coolcomfort22,

Seems I replaced the image but forgot to update the interfaces. I just did that. Thanks for letting us know.


Hi Rene, you have created recursive route on R1 to reach, i tried to configure the same lab but i am unable to ping from R1

C is directly connected, FastEthernet0/0 is subnetted, 1 subnets
C is directly connected, Loopback0 is subnetted, 1 subnets
S [1/0] via
S [1/0] via


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

Do I need static routes on the R2 router as well for full reachability?

Hi Rene, pls advise…i deployed the same topology excluding the ipsec configs…i cant reach loopbacks from R1/R3…we have created 2 static routes and the 2nd route which is for loopback reachability is pointing to the next hop which is not directly connected but reachable via another static route…this is confusion

Hello Asif

It is not necessary to add any configuration to R2. R2 has routes to its directly connected networks, which are and Because the next hop for the destination is (and this is a reachable next hop via routing), the packet does indeed reach R3. My suspicion is that you have not configured the counterpart routing on R3 for the return trip of the echo reply, OR, there is some misconfiguration of the tunnel. My suggestion would be to verify configuration of the routing on R3, as well as verify the configuration of the IPSec tunnel. Using the show crypto ipsec sa command, make sure the correct parameters are displayed as shown in the lesson.

I hope this has been helpful!


Hi Laz,

Thanks for the detailed explanation.

While I had followed the exact configuration steps as mentioned in the post, I was trying to check reachability of the loopbacks before configuring the ipsec.

But after digging deep, my understanding is the loopbacks reach each other only after the ipsec tunnel is established as the static route to from R1 points to R3’s WAN ip which becomes directly connected through the tunnel.

Kindly confirm if my above understanding is correct.

Thanks and regards

Hello Asif

Yes, that’s absolutely right, your understanding is correct!



I replicated a lab on GNS3 and I’ve a question about the show isakmp sa output:
Should have I two isakmp security association? one for the TX traffic and one for RX. right?

R1#show crypto isakmp sa
dst             src             state          conn-id status        QM_IDLE           1002 ACTIVE


R3#show crypto isakmp sa
dst             src             state          conn-id status        QM_IDLE           1002 ACTIVE


What can I check for tshoot this issue?

The communication between the peers work correctly because I can ping the loopback in each router through the the tunnel.

Hello Giovanni

The output of this command shows the SA that has been created between the endpoints. The SA is not “direction based” so you won’t see two SAs, but only a single one for each peer. The src and dst columns you see indicate which device initiated the IKE negotiation. In both R1 and R3, you see that the src and dst are the same for the SA, because it was that initiated the IKE negotiation. Both routers know this, so they both display the same info.

Since communication is up, and since the SA looks good, your link is functioning and encrypting data, so there doesn’t seem to be anything to troubleshoot.

I hope this has been helpful!


1 Like

Dont looks right in my eyes… No fastethernet 0/0. That command should be replaced with:

R1(config)#interface gigaethernet 0/1 ?

Last but not least, we’ll activate the crypto map on the interface:

R1(config)#interface fa0/0
R1(config-if)#crypto map CRYPTOMAP

That’s all we have to do on R1. Now we’ll create a similar configuration on R3:

Hello Michael

Yes, you are correct, that should be interface gigabitethernet 0/1. I’ll let Rene know to fix the typo. Thanks for pointing that out!