Cisco IPsec Tunnel Mode Configuration

Hi Renee!

I am wondering, is there anyway to initialize phase 1 or 2 from the router itself? For example, if I have an ACL such as permit host A to host B, normally I would have to ping from host A to B in order to initialize the tunnel. However, I’m wondering if there is anyway to initialize phase from from just the 2 peers without having to generate traffic from the end points?

I hope that’s clear, Thanks!

I went through this IPsec Tunnel configuration and checked the R1#‘show crypto ipsec sa’ table; but it did not come up with local and remote ident: ip addresses. that shows in your post as well as in ipsec site-to-site vpn. Everything else fine.

R1#show crypto ipsec sa

interface: Serial1/0
    Crypto map tag: cryptomap, local addr 12.12.12.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)


please help to know why it is?

Hmm are you sure the VPN is working? Do you see the number of encrypted/decrypted packets increase?

differences between Diffie-Hellman and Authantication

hello , i have mixed up in my mind the two concepts. If we have already used pre-shared keys why is necessary to use Diffie-Hellman group? Of course i understand DIffie-Hellman parameter is mandatory to the configuration. Diffie-Hellman isn’t for exchange keys for origin authentication encryption and for integrity ? i am wonder if all these methods are linked together with share secret key

Thanks in advance

Geia sou Dionisis

Authentication and the use of the Diffie-Hellman algorithm are two distinct and separate functionalities of ISAKMP negotiation.

The authentication pre-share command indicates that a pre-shared key will be used (configured manually on each device) as the method by which the devices will establish the identity of each other as an IPsec peers.

The group 2 command on the other hand indicates the use of Group 2 Diffie-Hellman identifier to derive a shared symmetric secret without transmitting it. This is used for the purpose of encryption.

So the preshared key is to identify the peer, while the DH secret key is for encryption and decryption purposes.

I hope this helps!

Laz

Geia sou Lazare ,

your answered me very clear and you have simplified it for me . Are there any sources that you know that they can help me to learn more about IPsec . Not about configuraton because Rene explains about it very nice but for details about the protocols that we use . Like could we use HMAC with PKI player ( private- public key )instead for pre-share key authentication ? Now you understand how much confuse my mind all these concepts. :smile:

Thanks a lot

1 Like

Hello again Dionisis

IPsec has been developed by IETF and as such there are quite a few RFCs that describe it and how it functions at a very low level. Because there are very many of these, the IETF has published RFC 6071 which is a snapshot of IPsec- and IKE-related RFCs. This can be found here.

Also, Wikipedia’s page on IPsec has a list of links to related RFCs that include HMAC, PKI and other cryptographic algorithms and modes of operation.

I hope this has been helpful!

Laz

Hello Laz ,
It is helpful
Thanks again about the information you have gave me

1 Like

Rene,
I am not sure how to add a comment at the end of a lesson.

I just finished the Lesson on IPSEC tunnel mode and had trouble getting my GNS3 to work. After looking through your configs, I noticed that you had an extra command.
In the lesson you failed to mention the mode tunnel under the Crypto IPsec transform command.

Thanks for such great work,

John Harmon

Hi John,

Did you use IOS 12.4T? I think that’s the problem then.

In IOS 15, tunnel mode is added automatically under the crypto ipsec transform-set.

Rene

Hi Rene !
As I read your lesson introduction to IPsec I saw that in phase 1 it will do the Negotiation on several items include Hashing, but in your configuration of phase 1 i cannot found configuration of hash value
image
Could you help to explain me.
Thank you
Sovandara

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.

Rene

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:
image
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!

Laz

Hi Laz
Thank you it help me a lot.
Sovandara

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 192.168.12.1 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):
R2#Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Oct  5 12:59:14.483: ISAKMP:(0):Old State = IKE_R_MM1  New State = IKE_R_MM2

R2#
*Oct  5 12:59:24.419: ISAKMP (0): received packet from 192.168.12.1 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 192.168.12.1
*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 192.168.12.1 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 192.168.12.1 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

Laz

Thanks for the reply.

1 Like

Dear Rene,

When I enter the command “ping 3.3.3.3 source loop 0” the destination IP address of the packet shows 192.168.23.3 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 3.3.3.3 ryt?

Hello Roshan

In both cases, the destination IP should be 3.3.3.3 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 3.3.3.3 as the destination IP in the single IP header.

In Tunnel mode you should see 3.3.3.3 as the destination IP in the inside IP header, and 192.168.23.3 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 192.168.23.3 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!

Laz