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 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
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.
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?
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.
Hi Rene, you have created recursive route on R1 to reach 3.3.3.3, i tried to configure the same lab but i am unable to ping 3.3.3.3 from R1
R1:
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3
S 192.168.23.0/24 [1/0] via 192.168.12.2
Router#
Router#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Router#
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
It is not necessary to add any configuration to R2. R2 has routes to its directly connected networks, which are 192.168.12.0/24 and 192.168.23.0/24. Because the next hop for the 3.3.3.3 destination is 192.168.23.3 (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.
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 3.3.3.3 from R1 points to R3’s WAN ip which becomes directly connected through the tunnel.
Kindly confirm if my above 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
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.0.0.1 10.0.0.5 QM_IDLE 1002 ACTIVE
IPv6 Crypto ISAKMP SA
R3#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
10.0.0.1 10.0.0.5 QM_IDLE 1002 ACTIVE
IPv6 Crypto ISAKMP SA
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.
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 10.0.0.5 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.
