IPsec (Internet Protocol Security)

Hello Helen

AH is capable of authenticating and verifying the integrity of each and every IP packet, including the header. This is important especially when mitigating against particular types of replay attacks, masquerade attacks, or man in the middle attacks, where the source IP address is changed or spoofed.

Because AH authenticates and verifies the integrity of the header of such traffic, IP addresses cannot be spoofed. Such changes to the header will be identified by the as fraudulent by the destination and will not be accepted.

ESP on the other hand will not protect against such attacks, but does provide protection at higher levels, including the encryption and authentication of the rest of the data of the IP payload.

I hope this has been helpful!

Laz

2 Likes

Hi,

Thank you very much and the IPSec tunnel lesson is very helpful and easy to understand. In IKE phase 1 aggressive mode wireshark captures on Message 1 and Message 2, Type Payload: Identification — > Identification Data is same in both initiator / responder messages as 192.168.12.2. Could you please confirm what is the expected tunnel ip address in initiator and responder messages in Main Mode (Encrypted Identification) and Aggressive Mode?

Thanks,
Venu

Hello Venu

The Identification data found within the Type Payload: Identification section is part of the identification procedure in the Aggressive mode authentication process of IKEv1. It specifically uses the IP address of the responder, and does not have to do with addressing issues (or the direction of the particular message being sent). It remains the same in both Message 1 and Message 2.

Note that there is no Identifier counterpart for the Main mode process. You can find out more about this particular parameter at RFC4945.

I hope this has been helpful!

Laz

Thank you Laz for the clarification and the confusion here is 50% of IKEv1 or IKEv2 tunnel setup messages are encrypted i guess after they exchange transform sets. I am planning to do hands-on and will talk to you if i have any questions

Hello Venu

Glad I could be of help. Hands on is always the best way to study, to fully understand these concepts. Let us know if you need any more help!

Laz

Hello ,

A) All items mentioned in the negotiation process i.e. STEP 1 we configure them manually on both customer end routers so they can negotiate ?

B) In STEP 2 of DH KEY exchange - The pre-shared key used in STEP 1 of authentication does it have any role in generating symmetrical/shared key ?

C) Step 2: DH Key Exchange - What does negotiated to exchange keying material mean in below paragraph
Once the negotiation has succeeded, the two peers will know what policy to use. They will now use the DH group that they negotiated to exchange keying material. The end result will be that both peers will have a shared key.

Regards
shaan

Hello Shaan

I assume you mean Phase 1. Yes, you must configure these parameters on both ends. The following lesson has an example of creating an IPSec tunnel between two IOS routers, and you can clearly see the configuration of phase 1 on both ends.

Take a look at the following post for this question:

The whole purpose of the DH key exchange is to securely exchange the shared key without actually transmitting the key over the public/insecure network. In order to do this, they exchange what is called “keying material”, that is, information that is used to enable both peers to obtain or derive the shared key. More information on how the DH algorithm operates can be found at the following post:

I hope this has been helpful!

Laz

1 Like

Hi Rene,
Thanks for your your article. I would like to know if you finally wrote an article explaining in detail about IPSec and NAT-Traversal.
Thanks in advance,
Raul

In the IPsec explanation topic,
The Hashing in IKE Phase 1 uses MD5 & SHA, but at the begging of the lesson it was mentioned Authentication uses this (MD5 & SHA).Little confuse who uses what.

Hello Kaza

MD5 and SHA are both cryptographic hash functions. They are algorithms that are used to produce a message digest, or a hash value of a certain length (MD5 produces a 128-bit hash value while SHA-1 produces a 160-bit value) when applied to a set of data.

Now, these algorithms can be used in various ways, one of which is to be used in authentication procedures. The output of the algorithm can be used to authenticate the original message. In the framework of IPSec, this involves the authentication of the credentials.

But, these algorithms are also used for data integrity. When information is sent, a message digest is sent with it. When a receiver receives data, it will run the hash algorithm on the received data and compare the result to the message digest that has been sent with the data, thus ensuring data integrity.

So you see, these are algorithms that are used as part of the authentication process, as well as part of ensuring data integrity.

I hope this has been helpful!

Laz

Hi,
When Renes says "IKE Phase 2
The IKE phase 2 tunnel (IPsec tunnel) will be actually used to protect user data. There is only one mode to build the IKE phase 2 tunnel which is called quick mode.

Just like in IKE phase 1, our peers will negotiate about a number of items:

IPsec Protocol: do we use AH or ESP?
Encapsulation Mode: transport or tunnel mode?
Encryption: what encryption algorithm do we use? DES, 3DES or AES?
Authentication: what authentication algorithm do we use? MD5 or SHA?
Lifetime: how long is the IKE phase 2 tunnel valid? When the tunnel is about to expire, we will refresh the keying material.
(Optional) DH exchange: used for PFS (Perfect Forward Secrecy)."

I am confused here, as I am thinking when I used to create these on a cisco router for example there was crypto isakmp profile or something similar where I would create the parameters for phase 1 ie. hash, auth, pre share key, lifetime, encryption but and then move on to phase 2 ie. the transform set with esp etc. but above it states
"Just like in IKE phase 1, our peers will negotiate about a number of items:

IPsec Protocol: do we use AH or ESP?
Encapsulation Mode: transport or tunnel mode?
Encryption: what encryption algorithm do we use? DES, 3DES or AES?
Authentication: what authentication algorithm do we use? MD5 or SHA?
Lifetime: how long is the IKE phase 2 tunnel valid? When the tunnel is about to expire, we will refresh the keying material.
(Optional) DH exchange: used for PFS (Perfect Forward Secrecy)."
I dont remember ever entering these twice ?
ie. I only put them for phase one, where is Renes getting these values for phase two as they are only entered once when creating the initial profile in phase one, then in phase two we create the transform set with esp etc.
Where is he getting the hash, auth, diffie group, lifetime, encryption for phase two as he states ? I thought these are only for phase one ?

Hello Sean

There are two ways to implement IPSec tunneling. The first, and the older way, is the one described in the lesson. You can see this configuration step by step in the following lesson:


In there you will see the two distinct steps of creating Phase 1 and Phase 2. However, the newer way of implementing, which is much simpler involves the configuration of an IPSec static virtual tunnel interface (VTI). This is the configuration you are describing in your post. This configuration and its details can be found in this lesson:

Even with this simpler configuration, Phase 1 and Phase 2 portions of the tunnel still exist in the underlying operation of the feature.

I hope this has been helpful!

Laz

How does the IPSEC_PROFILE know to use crypto isakmp policy 1. What if we have several crypto isakmp policy’s?

Hello Thor

When you configure an ISAKMP policy, you assign it a policy number. If you have multiple policies, during negotiation, the device will attempt to use the ISAKMP policies in sequential order. If the parameters of the first policy fail to be negotiated with the remote peer, then the next policy will be attempted. Take a look at this post for more details:

I hope this has been helpful!

Laz

Hello
I am not sure what outside IP to use to connect to the other site. Basically want a webserver at our site which has a private IP NATed to a public IP to connect to a database at the other site through a VPN tunnel. Should I use the website’s public IP for the phase 1 tunnel, or the IP address of the outside interface of our ASA or some another public IP just for the tunnel?

Does the newer way apply to Cisco ASA as well?

Hello Neil

It really depends upon what you want to achieve. One option is to create a site-to-site VPN tunnel using IPSec, and have the web and database servers connect to each other over that tunnel. This can be achieved by configuring the appropriate routing between sites. In this case, the endpoints of the tunnel would be the routers on the edge of each network. Thus the public IP address can be used for such a configuration, without taking any NATting into consideration.

More on how to create this using Cisco IOS routers can be found here:

And on an ASA:

Now if you want the web server to terminate the IPSec tunnel, then you will need IPSec to traverse the NAT translation. This can be a bit tricky, but it’s doable. It can be achieved using a feature called IPsec NAT Transparency. More about that can be found here:

In such a scenario, you must decide what the other endpoint of the tunnel will be. Will the web server connect to the remote router, or are you creating an IPSec tunnel from your web server directly to the database server, where the servers themselves are the terminating endpoints of the tunnel?

I hope this information will help you to determine the way in which you are planning to create your IPSec tunnel so that you can go on to the next step of the actual design and configuration of the tunnel itself.

Let us know how you get along, and if you have any other questions, feel free to let us know!

I hope this has been helpful!

Laz

Hi Laz
I think the ASA Site to Site IKEv2 IPSEC VPN will work - so that lesson config is very helpful
There are actually several servers on our side (on the same subnet) that need to connect to several server on their side. Both sides use private IPs for these.

Our ASA outside interface’s public IP is used by our Anyconnect VPN. Can I assign another public IP as the peer address for our side?
Our ASA does NAT for some private IPs on our side but not for any of servers private IPs we want to connect with.
The servers IPs on our side use dynamic NAT/PAT to reach the internet for updates etc.
object network obj_any
nat (any,outside) dynamic interface

In terms of access we just want to be able to connect to pull data from their system. We don’t want them to have any access to our system other than possibly a ping or to be able to monitor the connection
Is this done by setting the crypto map connection type of just by defining the access-list

crypto map set connection-type { answer-only | originate-only | bidirectional }

Also not sure about what to set for the lifetime seconds or what exactly that does. We want to tunnel stay open at all times.
Do I need to configure sla monitor to keep the tunnel open?

The lesson config doesn’t show a no-nat rule. Would this be needed in this case?

When I open up the ASA Site to Site Wizard, I see this.

Sorry for so many questions. Thanks for your help.

Hello Neil

Yes, VTIs can be configured on an ASA as well. You can find out more about VTI configuration on an ASA at the following Cisco documentation:

I hope this has been helpful!

Laz

Hello Neil

Glad to hear that the lesson is helpful.

Yes, it is possible to use the same outside interface for both AnyConnect VPN clients as well as for a site-to-site IPsec tunnel. Just ensure that the devices that are to connect to each other exist within the subnets that are tunneled through the VPN. In other words, they should be part of the “interesting traffic” of the VPN tunnel. Since you only want there to be access between the specific servers, you can configure the interesting traffic to only include the server on your end, ensuring that they don’t have access to other devices on your network. More info can be found here:

The crypto map set connection-type command is actually used to specify the connection types for the backup LAN-to-LAN feature and is supported only by specific devices. The following command reference includes more information about that:

To find out more about the lifetime parameter, take a look at this command reference:

You do not need to create an SLA monitor to keep the tunnel open, and you will see that from the above link.
Concerning no-nat, this is a configuration method that existed for versions before ASA8.3. More info can be found at these links:

I hope this has been helpful!

Laz