GRE Tunnel and IPSEC VPN over same interface

[rpinon]

       My customer is presently comunicating to a call service provider via a GRE Tunnel over IPSEC. They chose to move all such connections to a traditional site to site VPN behind a firewall here at the corp office.  Like the questions says, is it possible for me to set up the site to site VPN on the same router? Both interface Tunnelx and the ethernet have the same crypto map assigned at the destination router.  I thought traffic could split by indentifying "interesting" traffic.  Thanks ahead for any ideas, suggestions

Ray

[Richard Burts]

Ray

I need some clarification about your question. You seem to be telling us that your customer currently has a GRE with IPSec tunnel, which most of us would understand to be a site to site VPN. Then you say that the customer is going to move it to a site to site behind a firewall. I would generally understand that moving it meant taking it off the original and putting it on something different. But your question seems to be about having two at the same time.

So it would help if we understood more about the situation. Is the new tunnel to be also a GRE with IPSec or was it to be just IPSec (without GRE)? Is the new tunnel to carry different traffic from the first tunnel, or is the new tunnel to carry the same traffic as the customer moves from one implementation to another?

In general it is quite possible to have two site to site VPNs on a single router (and on the same interface) as long as the destination devices are different and as long as the traffic going over the tunnels is different.

HTH

Rick

[rpinon]

Sorry I did not respond earlier, but I'v been beating on this non-stop.  I apologize not being to clear on my initial description. Yes, at the moment, it is a GRE Tunnel with IPSEC encryption. The idea is to eliminate the GRE tunnel,  go to site-to-site VPN (just IPSEC) . The connection here at corp is being moved behind a firewall. (But that makes no difference)  The same traffic eventually . I was hoping to set up the IPSEC VPN just to test and confirm all is well on same router.  One thing is remote side has an ACL on the physical interface (not tunnel interface), any tinkering with that kills the tunnel.

The destination IP is different, I created a new crypto map, new ACL etc. I  created a test subnet on my end to match the new ACL. No go.  I think it maybe the ACL on the remote router.

What do you think?  I tried to add the new host IP to the ACL, but again, the moment I try to edit the ACL, GRE tunnel is down,

access-list 101 remark auto generated by SDM firewall configuration (ugh!!)
access-list 101 remark SDM_ACL Category=1
access-list 101 permit ahp oldhost my_side_ip host remote_side_ip
access-list 101 permit esp oldhost my_side_ip host remote_side_ip
access-list 101 permit udp oldhost my_side_ip host remote_side_ip eq isakmp
access-list 101 permit udp oldhost host my_side_ip host remote_side_ip eq non500-isakmp

..

removed

..
access-list 101 deny   ip any any log

Thanks

Ray

[Richard Burts]

Ray

I understand a bit better but there still are some things that are not clear to me. Will the new tunnel be using the same outbound interface as the current tunnel? (I am assuming that would be logical but not necessarily the case) If so then there can only be a single crypto map. You can create a separate set of entries in the crypto map for your new tunnel.

I am also not clear what the intention is for access list 101. I originally thought that perhaps it was your new access list to identify the traffic to encrypt. But the logic in the access list looks like an inbound access list on the public interface. Can you clarify what you are using access list 101 for?

I am also not clear whether you are making changes on the corp side, on the remote side, or on both.

It does get a bit tricky to edit an ACL especially if it is filtering traffic on an active interface. Perhaps if I understood better what is going on I might be able to give you better advice on how to do it.

HTH

Rick

[rpinon]

ACL 101 is not part of the crypto map, just a acl put on the interface I guess for an extra layer of security, perhaps even to avoid a network ip conflict, still trying to dig that up the reason for that.

The crypto map contains entries for the GRE as well as for the IPSEC VPN.

The new tunnel will be run out of the same interface the existing GRE tunnel (same interface acl 101 is applied to) is coming out of, at least I hope to get that to work.

The IPSEC tunnel means a new destination peer.  Fortunately on the corp side,  the IPSEC VPN is terminating on a seperate router, so it was just a matter configuring, It's the remote side that is the challenge. 

[Richard Burts · Accepted solution]

Ray

Thanks for the additional information. So the existing entries in ACL 101 need to remain so the existing tunnel will still work. And you need to add entries that will permit the new tunnel. Editing an ACL that is actively filtering traffic can get tricky. Here is a technique that I sometimes use.

- create a new access list (perhaps ACL 102 assuming that 102 is not already in use).

- copy the entries from ACL 101 to 102 and add the extra entries that you need in the appropriate places in the ACL.

- once the new version of the ACL is complete in the config then go tho the interface and change the ip access-group to point to the new ACL.

This provides a transition that does not impact traffic. And it makes going back to the original easy - especially if something is not working as expected in the new ACL.

If the crypto map on the remote has an entry for the GRE and a separate entry for the IPSec that is a good thing and should work. I assume that the crypto map entry for GRE specifies an access list that permits the GRE traffic and that the crypto map entry for IPSec points to a different access list which identifies the IP traffic to be encrypted through the new IPSec tunnel.

HTH

Rick

[rpinon]

Apology Richard for not responding earlier. Your idea worked fine. it took some heavy tweaking, (customer environment), but I finally go it to work.  I am working on a similar project right now, (last one thank God!!!!) But in this case, I can not shutdown the existing GRE tunnel, and despite the ACL assigned to the crypto map plus static routes, the remote end router still chooses to send packets thru the GRE tunnel. MOre confuding is I found out this morning my test node IP is being sent to remote router via EIGRP.  I'm thinking next step is to shut down tunnel from my end and test the IPSEC VPN.

I'll keep you posted. Thanks again for you help!!!

Ray

[Richard Burts]

Ray

I am glad that my previous response was helpful in getting most of the sites changed. I do not have a clear understanding of the environment that you are currently dealing with. But your description makes me wonder whether they are running EIGRP over the GRE tunnel.

HTH

Rick

[rpinon]

Yes they are.

The local side goes thru the IPSEC VPN as confrmed by the show crypto ipsec, #encaps and #decaps increases accordingly. Remote, all counters stay at zero which makes me believe it is going thru the GRE tunnel, responses to ping as well. Static routes on both sides, ISKAMP and IPSEC settings match perfectly, ACLs are mirrors of each other. It was working, until GRE was kicked off, then it went "weird". Looking for a windows to shutdown GRE from this side completely and test the IPSEC VPN again. 

[Richard Burts]

Ray

I am glad that one side seems to be working and a bit puzzled why the other side would not be working. So here are a couple of questions that occur to me:

- on the not working side is the static route using the same mask as the EIGRP advertised route, longer mask, or shorter mask?

- on the not working side does the static route specify just the outbound interface, just the next hop address, or both the next hop address and the outbound interface?

HTH

Rick

[rpinon]

My local test ip is 192.168.20.111

Static route on remote side is to my outside IP here

Static route is masked as /32

EIGRP topology shows entire subnet masked as /24

For sake of conversation, if I try to ping remote test IP (10.6.238.12) from local side, pings fail, but tunnel is up. Again counters in show crypto ipsec increase accordingly

I go to remote side, successfully ping local test IP (192.168.20.111),

Now I can successfully ping remote side from local.

It almost appears as though I go through IPSEC tunnel when I ping out, but according to show crypto ipsec and debug on remote side, responses come thru GRE tunnel, as counters show zero. It is possible the routing here is a bit "ugly"