IPSec over GRE

pthaks_2000 · ‎06-03-2008

I am in the middle of testing IPSec over GRE. The kind of requirement that I have wants me to run IPSec over GRE interface ONLY and not on physical interface.

During the course of my testing, I found out that as long as I have IPSec configured both on my physical and tunnel interface, the end to end ping is working and the ipsec sa command shows the packets being encrypted and decrypted showing that encryption is also working.

However, when I remove the crypto map from the physical interface and it is still configured on the tunnel inteface, my end to end ping still works but my encryption stops. I cannot see any packets being encrypted/decrypted.

Does that mean that for the encryption to work on GRE tunnel, one MUST have the crypto maps applied on the physical interface ALSO?

So, if there is no IPSec on physical interface, effectively there is no encryption happening even though you have configured it on the tunnel interface.

Is that the way it works?

Regards

Pooja

attrgautam · ‎06-04-2008

Pooja

That is not true...AS long as you have IPSEC applied on the logical interface/GRE, it should suffice...

I hope your crypto ACL is not encrypting the GRE traffic itself in which case what you are doing will be GRE over IPSEC and the crypto map needs to be on the interface.

Maybe if could share your configurations, it may help

michael.leblanc · ‎06-04-2008

If you are using IOS Release 12.2(13)T or higher, you should "only" be applying the crypto map on the "physical" interface. This is "highly recommended" by Cisco docs I have read.

If you are using an IOS Release earlier than 12.2(13)T, you will need to apply the crypto map to "both" the GRE tunnel interface and the physical interface.

I'm not sure what would lead you to configure it on the GRE tunnel interface only.

Your crypto ACL is going to specify that "only" traffic directed through the GRE tunnel will be encapsulated with IPSec as it leaves the physical interface anyway.

pthaks_2000 · ‎06-05-2008

My requirement is such that there is a dual homed hub site and single homed branch site connected via MPLS. The customer wants IPSec between primary hub site link and single homed branch site.

However, in case the primary hub link fails, the traffic should fall back on backup hub link and still be able to access the branch site.

The solution that I had thought was to create a GRE between primary hub link and branch site. On top of GRE, IPSec is configured. A static route at both the primary hub router and branch router would point towards GRE tunnel.

In addition to this, standard BGP routing is also working between the respective routers and their corresponding PEs. At branch site, due to presence of lower metric static route, it installs this route in the routing table.

Therefore, in normal working, all traffic between the 2 sites would be routed to the GRE due to static route and since IPSec is configured on GRE, the traffic would be encrypted.

However, in case the primary link fails, GRE tunnel will fail, static route will become invalid. At the hub sote due to HSRP running between primary and backup routers and tracking the primary link, the local hub LAN will fall back on the backup router. This backup hub router has a BGP route for the branch site pointing towards the MPLS.

At the branch router, since the GRE tunnel has failed, the static route becomes invalid and is removed from the routing table. Simultaneously, the BGP route with hgiher metric than the static route now gets installed in the routing table and forwards all the traffic over the physical WAN interface towards MPLS.

Since there is no IPSec configuration on the physical interface at the branch site, my end to end communication is still possible even though the primary link at hub is down.

This is the main reason for me to configure IPSec ONLY on GRE tunnel and NOT on physical interface.

Do you still see any issues with this?

FYI, I have tested this successfully at the test lab with Cisco 87x series.

michael.leblanc · ‎06-06-2008

Your statement: "FYI, I have tested this successfully at the test lab with Cisco 87x series." is contrary to your initial post.

I think Virtual Tunnel Interfaces might address your need.

Take a look at the following document:

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.pdf

Consider the following excerpt which conveys that you can send data to or bypass the encryption process based on the routing table:

An IPSec virtual tunnel configuration does not require a static mapping of IPSec sessions to a physical interface. This allows for the flexibility of sending and receiving encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted when it is forwarded from

or to the tunnel interface. The traffic is forwarded to or from the tunnel interface by virtue of the IP routing table. Dynamic or static IP routing can be used to route the traffic to the encryption engine. Using IP routing to forward the traffic to encryption simplifies the IPSec VPN configuration when

compared with using access control lists (ACLs) with the crypto map in native IPSec configuration.

Also, wouldn't it make more sense to use dynamic routing with fall back to "floating static routes", rather than falling back to dynamic?