IPSec & GRE queries ....

Answered Question
Mar 21st, 2008
User Badges:

Hi Friends,


I have been going through IPSec & GRE study guides and have a few queries that i am struggling to find an answer for. Kindly help me clear these.


1. IPSec does not support multicast whereas GRE does. I am wondering why IPSec goes not support multicast. I understand IPSec encrypts all data including the IP Header and creates a new IP Header. But from my understanding, even GRE encapsulates the IP Header and creates a new IP Header. Then how come only GRE supports routing?


2. In GRE configuration, we specify the Tunnel Source & Tunnel Destination. Will these ip addresses be the source & destination ip address of the new header that GRE creates?


3. When you run GRE over IPSec, which is the interface to apply crypto_map to? I have seen implementations wherein sometimes its in Tunnel interface, sometimes on the Internet facing interface and sometime even on both?


Thanks in advance for your active participation on this.


Best Regards,

Manoj

Correct Answer by Richard Burts about 9 years 4 months ago

Manoj


1) To assume that routing protocols do not work over IPSec is too much generalization. As you say later in your post the real issue is multicast traffic over IPSe (which does not work until very recent releases of IOS). Since BGP uses unicast (TCP) addressing it will work over IPSec.


2) BGP would still work. BGP will advertise whatever network you tell it to advertise (assuming that the network is found in the IP routing table). If you advertise network 150.x.x.x and that network is not included in the interesting traffic access list then the traffic to and from that network would not be encrypted and would be sent in clear text.


3) If you had configured EIGRP there would be a problem since EIGRP uses multicast advertisements.


HTH


Rick

Correct Answer by Richard Burts about 9 years 4 months ago

Manoj


Here is a reference which explains the change in requirement for placement of the crypto map:

With IOS 12.2(13)T software and later (higher numbered T-train software, 12.3 and later), the configured IPSec crypto map only needs to be applied to the physical interface and is no longer required to be applied on the GRE tunnel interface. In software versions prior to this release, IPSec crypto maps need to be applied to both the tunnel interface and the physical interface. Having the crypto map on the physical and tunnel interface when using the 12.2.(13)T software and later should still work; however, Cisco highly recommends that you apply it just on the physical interface


If you want additional details here is the link:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a0080093f70.shtml


HTH


Rick

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (6 ratings)
Loading.
Richard Burts Fri, 03/21/2008 - 12:56
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


Here are my answers to your questions:

1) The specification of IPSec specifies that it processes unicast IP traffic. That was a design decision. The design decision probably could have been different but we can deal only with what it is and not what it might have been. The specification of GRE was different and does support multicast.


2) In GRE the address that we specify as tunnel source will be used as the source address of the GRE header and the address that we specify as tunnel destination will be used as the destination address of the GRE header.


3) This answer depends on what version of code you are running. In older versions of code you needed to put the crypto map on both the physical interface and the tunnel interface. In more recent versions of code you only need to put the crypto map on the physical interface.


HTH


Rick

Manoj Wadhwa Fri, 03/21/2008 - 13:04
User Badges:

Hi Rick,


Thanks for your answers. Need a clarification with regards to point "3". Can you let me know which codes require both on Tunnel & Physical interface and above which codes does it require only on the physical interface? If there is any document pertaining to this, please let me know. Thanks again.


BR,

Manoj

Manoj Wadhwa Fri, 03/21/2008 - 15:50
User Badges:

Hi,


While i was waiting for your answer for my point "3", i was setting up my sample lab trying to do testing for Gre over IPSec. I setup the IPSec connectivity and then run bgp over it just to verify that bgp does not come up (as should be the case). But to my surprise, the bgp did come up. I am totally confused on how come IPSec is allowing BGP. Kindly help me to clarify this. My topology is very simple


GreOverIPSEc1 ---> Internet ----> GreOverIPSec2. I have also attached the configs and the output which is under the Verification text. Thanks!




Attachment: 
Correct Answer
Richard Burts Sat, 03/22/2008 - 09:42
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


Here is a reference which explains the change in requirement for placement of the crypto map:

With IOS 12.2(13)T software and later (higher numbered T-train software, 12.3 and later), the configured IPSec crypto map only needs to be applied to the physical interface and is no longer required to be applied on the GRE tunnel interface. In software versions prior to this release, IPSec crypto maps need to be applied to both the tunnel interface and the physical interface. Having the crypto map on the physical and tunnel interface when using the 12.2.(13)T software and later should still work; however, Cisco highly recommends that you apply it just on the physical interface


If you want additional details here is the link:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_example09186a0080093f70.shtml


HTH


Rick

Richard Burts Sat, 03/22/2008 - 10:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


I have looked at the additional question that you ask about why BGP does run over the IPSec that you configured. Your assumption seems to be that BGP should not run here. Why do you think that BGP should not run?


In looking at your configs it seems fairly direct:

- you configure BGP between the end routers specifying BGP addresses as 10.10.10.x and 10.20.20.x

- you configure bgp update-source and ebgp multihop so that the addresses used for the TCP BGP packets will have source and destination addresses in 10.10.10.0 or 10.20.20.0

- your access list for interesting traffic permits any ip between 10.10.10.0 and 10.20.20.0


So the routers establish their IPSec negotiation and the IPSec connection is established. BGP is running and sends its TCP packet over the IPSec connection. The BGP traffic is permitted by the interesting traffic access list. Why would you expect that this would not work?


HTH


Rick

Manoj Wadhwa Sun, 03/23/2008 - 22:03
User Badges:

Hi,


I sincerely thank you for all your replies. It makes me think so foolish after i read your replies :-) ... But you know what, i have something for you again .. plz dont mind, hopefully this will be the last one.


1. The reason i thought BGP won't work is because i was under the impression that any routing protocol/ multicast traffic will not work over IPSec. But i was wrong.


2. Now in the above scenario, if i would have advertised a network say 150.x.x.x, it is not part of the interesting traffic. So will the BGP still work but just that for this update, the packet will not be encrypted and be sent in clear text?


3. What if i would have configured EIGRP instead of BGP (a different setup). As EIGRP uses multicast, will the EIGRP still work?


Thanks for your patience and time again for making things clarified for me.


Best Regards,

Manoj

Correct Answer
Richard Burts Mon, 03/24/2008 - 04:43
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


1) To assume that routing protocols do not work over IPSec is too much generalization. As you say later in your post the real issue is multicast traffic over IPSe (which does not work until very recent releases of IOS). Since BGP uses unicast (TCP) addressing it will work over IPSec.


2) BGP would still work. BGP will advertise whatever network you tell it to advertise (assuming that the network is found in the IP routing table). If you advertise network 150.x.x.x and that network is not included in the interesting traffic access list then the traffic to and from that network would not be encrypted and would be sent in clear text.


3) If you had configured EIGRP there would be a problem since EIGRP uses multicast advertisements.


HTH


Rick

Manoj Wadhwa Wed, 04/02/2008 - 02:58
User Badges:

Hi Rick,


Sorry for my late reply, i was sick hence unable to reply to you. I would thank you for the information you provided. I implemented IPSEC, GRE and GRE Over IPSec in my lab and was able to set things up though with some difficulty initially. Most of my doubts have been clarified and you were very helpful in clarifying those. I sincerely thank you for your help. As always, you are a champ for this forum :-). Take care always.


Regards,

Manoj

Richard Burts Wed, 04/02/2008 - 09:16
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


I am sorry to hear that you were sick and am glad you are now recovered. I am glad that you have got it working in your lab - and agree that in the first few times these things can be difficult to set up and get to work.


Thank you for the compliments. I am glad that my information was helpful to you. The forum is an excellent place and I encourage you to continue your participation in the forum.


HTH


Rick

lamav Wed, 04/02/2008 - 20:06
User Badges:
  • Blue, 1500 points or more

Manoj:


Just a quick clarification...


you said


"I understand IPSec encrypts all data including the IP Header and creates a new IP Header."


Actually, IPSec running in transport mode does not encrypt the original IP header. What you are describing is tunnel mode.

guruprasadr Thu, 04/03/2008 - 01:57
User Badges:
  • Gold, 750 points or more

HI Rick / Manoj,


In am running IPSec Tunnel beween the HUB and Spoke Locations.


By default, the IPSec Session will stay for only 60 minutes and it will re-establish even if there is an traffic / interesting traffic. Unless until there is not interesting traffic, the session will not come up.


Can you provide me an soulution where my IPSec session should not go off and it should be always Up and Running.


Best Regards,


Guru Prasad R

Manoj Wadhwa Thu, 04/03/2008 - 04:46
User Badges:

Guru,


One of the security features of IPSec is to re-establish the sessions even though the interesting traffic is going through it. This help not to compromise on any kind of attacks if any. By fault, if you exectute show cryto map command, you can see the lifetime that is configured. Below is the output on one of my routers which has default life time configured.


show crypto map

: 4608000 kilobytes/3600 seconds


In case you would like to increase the lifetime, you can execute the command "set security-association lifetime seconds xxxx" under crypto map.


Rick,


Plz let me know if i am right. Thanks!


Regards,

Manoj

Richard Burts Thu, 04/03/2008 - 04:48
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Guru


In some of the IPSec implementations I have done we run a routing protocol (could be EIGRP or OSPF) through the IPSec. The hello messages or keepalives are interesting traffic and serve to keep the connection up and active. I have not done it and so can not address the possibility from direct experience but I would assume that if you are running IPSec with GRE that configuring GRE tunnel keepalives would also accomplish this.


[edit] Manoj I believe that your statements are correct.


HTH


Rick

guruprasadr Thu, 04/03/2008 - 05:00
User Badges:
  • Gold, 750 points or more

Dear Rick,


In my HO i have 2" 7200 Router (1-Active, 1 - Standby) as IPSec Peer. I have 900 Spoke Location forming IPSec Peer relationship with HO.


I am providing the output of "show crypto map" for one of my spoke location"


Security association lifetime: 4608000 kilobytes/3600 seconds


with the above output the IPSec Life will expire in in 3600seconds and then re - establish. My requirement is: "I Dont Want my IPSec SA LifeTime to expire at all"


Let me know whether the IPSec SA LifeTime will by default expire in 60 minutes ?


Also, the MAX LifeTime for SA can be configured only to 86400seconds ?


Also, with the above setup explained, how do i run a Routing Protocol say OSPF between HUB & Spoke Locations as said in your POST.


Kindly provide the Solution with some Sample Configuration output if any available.


HI Manoj,


Thanks for your POST. Apprecicate your reply too.


Best Regards,


Guru Prasad R

Richard Burts Thu, 04/03/2008 - 08:33
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Guru


I obviously did not understand your requirement or I would have responded differently. You say:

My requirement is: "I Dont Want my IPSec SA LifeTime to expire at all"

now that I do understand your requirement my response is that your requirement is a direct violation of a basic architecture of IPSec and can not be accomplished. The basic architecture of IPSec says that to protect against an attacker breaking the encryption key that the working keys should periodically be re-negotiated and having a lifetime is the basic mechanism to accomplish this. It is not possible to run IPSec and to not have a lifetime that will time out the session.


As for running a routing protocol over IPSec there are at least 2 alternatives which you should consider. The traditional solution to run routing protocols that use multicast was to use IPSec with GRE. In release 12.3(14)T Cisco introduced a new feature of Virtual Tunnel Interface which treats the IPSec tunnel as a virtual interface and enables transmission of multicast without requiring GRE. For more information on this feature you can use this link:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008074f26a.pdf


HTH


Rick

Manoj Wadhwa Thu, 04/03/2008 - 05:03
User Badges:

Rick,


A quick question regarding your statement "In some of the IPSec implementations I have done we run a routing protocol (could be EIGRP or OSPF) through the IPSec. The hello messages or keepalives are interesting traffic and serve to keep the connection up and active". I am sorry to ask this to you again. IPSec does not allow multicast and EIGRP & OSPF does use multicast. How was this possible then? Were you running GRE over IPSEC ?


Regards,

Manoj

Richard Burts Thu, 04/03/2008 - 08:37
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Manoj


The traditional implementation of IPSec was restricted to unicast IP traffic. The traditional way to get multicast traffic (such as most of our routing protocols) was to combine IPSec with GRE. In release 12.3(14)T Cisco introduced a new feature of Virtual Tunnel Interface. The essence of this feature is that it does treat the IPSec connection as a virtual interface and this allows the sending of routing protocol traffic without requiring GRE. For more information about this feature you can look at this link:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a008074f26a.pdf


HTH


Rick

Actions

This Discussion