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.
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.
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?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...