Some doubts to create an IPSec tunnel.

[ciscolover]

Hi all ¡¡¡

I want to create an IPSec tunnel between 2 Cisco routers(R1-R2) passing through internet. I hope you can help me ¡¡¡¡ The authentication method is a preshared key. I explain all the steps.

1)

I think than I need at least one similar ISAKM policy in the 2 sites but I can put some ISAKM policys (policy 1, policy2 , policy 3).

This it's correct?Can I to apply exactly the same Crypto Isakm policy in the 2 routers?

In the ISAKM policy I put, for example:

R1)crypto isakmp policy 1

     encr 3des

     authentication pre-share

     lifetime 40000

R2)crypto isakmp policy 1

     encr 3des

     authentication pre-share

     lifetime 40000

Afther that I create the transform set. I think, this it needs be exactly in the 2 routers. I have a doubt, the name of the transform set needs be the same or I can name it differently?

For example:

R1-->crypto ipsec transform-set router1 esp-3des esp-sha-hmac

R2-->crypto ipsec transform-set router2 esp-3des esp-sha-hmac

Then I create the crypto key. I think I need to configure the public ip of the differents routers. The X.X.X.X are the public IP of the remote router.

R1)crypto keyring EXAMPLER1

     pre-shared-key address X.X.X.X key password

R2)crypto keyring EXAMPLER2

     pre-shared-key address X.X.X.X key password

Then I create the crypto isakmp profile in the 2 routers.Here i have doubts... It's necessary vrf?¿¿?¿?

R1)crypto isakmp profile NAMEISAKMPROFILE

       vrf ?¿?¿?¿

       keyring EXAMPLER1

       match identity address PUBLICREMOTEIP 255.255.255.255

R2)crypto isakmp profile NAMEISAKMPROFILE

       vrf ?¿?¿

       keyring EXAMPLE2

       match identity address PUBLICREMOTEIP 255.255.255.255

I create the access list in the 2 routers with the traffic than I need to mach in the tunnel.

r1)ip access-list extended ACLR1

permit ip x.x.x.x x.x.x.x

r2)ip access-list extended ACLR2

permit ip x.x.x.x x.x.x.x

And finally I create the crypto map in the 2 routers: I have 2 doubts, which is the use of teh secuence to enter in the crypto map? It's necessary to put the reverse-route in the crypto map?

R1)crypto map R1 3000 ipsec-isakmp

set peer PUBLICIPOFR2

set transform-set ROUTER1

set isakmp-profile NAMEISAKM

match address ACLR1

reverse-route

!

R2)crypto map R2 3000 ipsec-isakmp

     set peer PUBLICIPOFR1

     set transform-set ROUTER2

     set isakmp-profile NAMEISAKM

     match address ACLR2

     reverse-route

Thanks all for your help. Please, correct me when you think that is a bad configuration ¡¡¡¡

Best regards.

[Peter Paluch]

Hello,

Let me show you a workable configuration for you so that you can adapt it for your purposes, okay?

crypto isakmp policy 1
 encr 3des
 authentication pre-share
 lifetime 40000
!
crypto isakmp key 0 password address X.X.X.X
!
crypto transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
ip access-list extended ACLR1
 permit ip A.A.A.A M.M.M.M B.B.B.B N.N.N.N
!
crypto map R1 1 ipsec-isakmp
 match address ACLR1
 set peer X.X.X.X
 set transform-set ESP-3DES-SHA
!
interface ...
 crypto map R1

No VRFs, ISAKMP profiles, IPsec profiles, keyrings, reverse route, any of that stuff - it complicates things unnecessarily here. Regarding the reverse route: with plain IPsec between two static sites, you simply modify your routing table and add a static route towards the internal network behind the other IPsec tunnel endpoint towards the ordinary next hop behind the interface on which the crypto map is installed. This has to be done reciprocally on the other endpoint as well.

Please feel free to ask further - but if this does not work be sure to enclose your existing configuration of both routers and indicate which networks are internal.

Best regards,

Peter

[ciscolover]

Thanks all for the replyes ¡¡¡¡¡¡¡¡¡

Peter, one of the routers are out of my administration. It belongs to another enterprise and they have send me the running-config.

His configuration is like R1 and I need to configure R2. I can't modify it.

Knowing that, the configuration than I have post, for R2, It,s correctly?

Best regards.

[Peter Paluch]

Hello,

Use the style of configuration I suggested at your tunnel endpoint. If it does not work, we'll try to make it work. You may eventually want adding the reverse-route into your crypto map but apart from that, it should work.

Best regards,

Peter

[ciscolover]

Thanks Peter, let me to ask you the last doubts.

-You suggested than I put crypto key better than crypto keyring. And you suggested than I not create an ISAKM profile.

Which is the difference?Why in the other enterprise they have crypto keyring instead of crypto key?¿Maybe because they have more tunnels configured in the same router?

I think in the 2 cases this can works. I have observed than in the crypto keyring you cannot put if the password is encrypted or not....Which is the difference between crypto key and crypto keyrin? Please, could you explain me this?

-You suggested than I not create VRF. I think this is to create different instances and is not necessary in my router. This it's correct?

-I need to configure reverse route like the other side...

-In the crypto map you put a different sequence number than the other remote router. I think this it's a local parameter for my router and it not affects if it's different than the other side..

Thanks for all, I'm not an expert of IPsec tunnels and I try to understand it.

Regards

[Peter Paluch · Accepted solution]

Hello,

Using the crypto key instead of a keyring is about simplifying your configuration. A keyring is a set of keys you can refer to in other parts of configuration, such as the ISAKMP profiles. This is especially useful if using VRFs (separate routing tables) for different IPsec VPNs, because these VPNs may use the same IP address space and hence the IP addresses alone would not be able to uniquely identify which key shall be used. Because an ISAKMP profile can refer to a particular VRF and a keyring, it allows each VRF/VPN to have its own set of keys that will always be uniquely identifiable, even IP addresses in different VRFs are identical.

For your peer, using keyrings is probably useful, assuming they terminate lots of IPsec tunnels. But assuming a simple IPsec tunnel initiated from your router, there is no advantage in using keyrings for you. If possible, keep things simple.

The ISAKMP profiles are another concept that is usable if you are serving multiple IPsec tunnels with possibly diverse security requirements. Again, with a single IPsec tunnel, the ISAKMP profiles would work but there is no advantage in using them at the cost of having the configuration more complicated. You can read more about the ISAKMP profiles here:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/prod_white_paper0900aecd8034bd59.html

You also do not need to create VRFs - that would create another separate virtual router within your router, in a similar way how a VLAN creates a virtual switch inside a physical switch. If you do not know that you need them, you do not need them

Feel welcome to ask further!

Best regards,

Peter

[ciscolover]

Amazing replay.

I'll go to create it in GNS3 and I'll put here the results before to try it at work.

Thanks a lot.

[Joseph W. Doherty]

Disclaimer

The      Author of this posting offers the information contained within this      posting without consideration and with the reader's understanding   that    there's no implied or expressed suitability or fitness for any    purpose.   Information provided is for informational purposes only  and   should not   be construed as rendering professional advice of any  kind.   Usage of  this  posting's information is solely at reader's own  risk.

Liability Disclaimer

In      no event shall Author be liable for any damages whatsoever    (including,   without limitation, damages for loss of use, data or    profit) arising  out  of the use or inability to use the posting's    information even if  Author  has been advised of the possibility of   such  damage.

Posting

Depending on what type of traffic you need to exchange between your routers, you might want to define an explicit tunnel between the routers whose tunneled traffic is encrypted.  For a single logical link between your routers, perhaps a VTI tunnel would be suitable.  Complexity wise, about the same as what Peter has posted, the VTI tunnel interface would take the place of the ACL, crypto map, and crypo map on the physical interface.

PS:

In your original post, I see you're using 3des, but if your devices support it, you might opt for AES instead.

[ciscolover]

Ok peter in thing that works ¡¡¡

How can I confirm it? with show ip sec SA? I can watch some encrypted paquets.

I have create the acl with 2 statements,

Permit nework1 network2 --->this not matches any paquet.

Permit network2 network1 -->this matches and encrypts a lot of paquets.

I though that was necessary to permit encrypt the traffic of the 2 networks. Maybe with only one statement it works.

And finally, wich ports are used for this IP/SEC tunnel?

500/udp and IP 47?¿?¿

Best regards

[Peter Paluch]

Hello,

Hey, I am glad to see it worked

With regard to your ACL, your ACL should always contain only the traffic in the direction from your local network towards the remote network (i.e. what traffic should be encrypted - the decryption will be performed automatically). Do not enter any reversed entries into the ACL.

You can have a look at show crypto ipsec sa - there should be counters for encrypted/decrypted packets increasing.

IPsec uses ports UDP/500 for ISAKMP, UDP/4500 for NAT-T and IP protocols 50 (ESP) and 51 (AH, not used in your transformation set).

Best regards,

Peter

[ciscolover]

Ok peter last question,

My tunnel uses 500,4500and 50. Thats correct?

It seems that works because it encrypts packete. Can i watch if the tunnel it, up or down with another command?

Thanks!!!!

[Peter Paluch]

Hello my friend,

Your tunnel uses UDP/500 and IP protocol 50. I do not currently believe you are also using UDP/4500 because that port is used for NAT Traversal scenarios - but I would personally recommend opening that port as well.

Because this kind of IPsec tunnel configuration is not represented by an interface, it is not easy to readily see if the IPsec tunnel is up. The only way to be sure is to check the show crypto ipsec sa that will show you the security associations negotiated with the other party. If the other party is not recorded in this output, the tunnel is not currently operational.

Best regards,

Peter

[ciscolover]

Hi all ¡¡¡

Today I have tryed it but the First fase doesn't works.

I think it's because I need a Nat transversal configuration. In one of the sides.

The topology is like this:

-router1 with ipsec and public ip-

-INTERNET

-Router2 with public ip

-firewall(with nat)

-routerwith ipsec

[Peter Paluch]

Hello,

Some debugs would be helpful.

Please enclose the output of these debugs:

debug crypto isakmp

debug crypto isakmp error

Best regards,

Peter

[ciscolover]

It works perfectly, thanks all ¡¡ The problem was than I needed nat in my tunnel.

Thanks ¡¡¡