Dynamic VPN Tunnels

[virgilv]

I am trying to figure out different ways for configuring dynamic tunnels between two routers, in which either side could initiate the tunnel.

I have played with DMVPN, however this really relies on the spoke router "registering" with the hub, thus initiating IPSec.

I have also configured TED, but TED relies on routable addresses (encrypted traffic) and dynamic crypto maps.

Is there a way to mix TED on one side and a typical LAN-to-LAN config (set peer / crypto map / etc.) on another side such that either end could initiate the tunnel. If not, what other ways can that be achieved.

I have spent a number of hours trying to figure this out and haven't come up with much.

[ehirsel]

Will one or both of the rotuers get a dynamic ip address assignment on their provider-facing interface? Or will they both have static addresses?

[virgilv]

Uh - let's say both have static addresses and / or one could have a dynamic address.

This is a little problem I have been trying to figure out for a while now and I just can't seem to find the right combination.

[ehirsel]

I believe that TED is your best option, however that requires that you have cisco routers on both ends - DMVPN may the same requirement, I don't know for certain.

I would use TED, as it will allow not only for dynamic peer discovery by either end, but in using dynamic crytpo maps it makes the config much easier to maintain.

You seemed to be leery of using TED due to using the dynamic maps (and routable ip addresses - though that is needed for any solution).

Do you plan to run any dynamic routing protocols between the peer routers? You may want to consider doing that, using GRE over IPSec (GRE/IPSec) to force one end to always do the initiation. The advantage will come if you have one end that will have a dynamic assigned ip address, as once the address is assigned and the routing protocol is about to advertise network reachability, then that router will initiate the IPSec tunnel to the hub. You can use TED or DMVPN in this case.

For the case where both ends have static addresses, then using TED with or without running routing protocols using GRE/IPSec should work fine.

Let me know if this helps.

[virgilv]

Well, that is good info, however I had counted TED out because (I don't know if I mentioned this before) there is a requirement that one side doesn't use dynamic crypto maps.

My "hesitation" about TED and routable IP's was that the IP's have to be "publically" routable, as opposed to private routing througha GRE tunnel or NAT'ing or something like that.

I am getting desperate on this problem, because I just can't figure it out.

[ehirsel]

What about running dynamic routing protocols? Are you running any of them (i.e., RIP, OSPF, EIGRP)?

I think your easiest solution is to use run a routing protocol and advertising them using GRE/IPSec via DMVPN, and dynamic crypto maps on both routers. The dynamic route protocol would issue periodic keepalives, as long as both ends are operating normally. In that case you don't really care which is the spoke and which is the hub.

Though if you want, one router can be passive (so it is the hub), and the adv. router can be the spoke. This way you get the benefit of easy maintenance along with IPSec. Doing this will always force one side, or both, to initiate a tunnel when it is time for SA est. by running the hello and adv. over GRE using IPSec. Without running some type of periodic traffic, it may not be possible to do what you want. Instead of running route protocols, you can have two hosts run a ping or periodic ftp/http across the two routers - again this regular traffic will force a SA est. and either router can do the initiation.

I wasn't aware of TED using public ip addresses, instead of private.

Let me know if this helps out more.

[virgilv]

I think I inadvertantly tried what you are talking about here. And I think you're right - IPSec SA's can be initiated from either side.

However, with DMVPN's, the spoke registers with the hub upon booting or if the outside interface should go down and then backup, it will register. In this case, phase 1 of your tunnel is always going to be initiated by the spoke, isn't it?

I think what I have been trying to describe isn't do-able. I have tried every method I can think of and it seems that with the combination of elements I have described, you will always end up with either the spoke being the only one to initiate, OR you will end up with a dynamic crypto map on both sides, which I don't want to do.

This isn't a production scenario I have been working on - it is just a chalenge, but I was lead to believe it could be done and so far I don't agree that it can be. The closest thing I could think of was using TED on one side (the "hub") and then using traditional crypto maps on the other and this just won't work because the spoke side always sees that TED request as a packet that falls within the boundaries of it's crypto ACL, but the packet is not an IPSec packet (rather a UDP 500 packet). Thus, the hub ends up giving an error message that basically states received was not IPSec and IPSec was expected so it tosses it (no TED reply).

However, I don't know that the challenge stated that the tunnel had to be initiated from a phase 1 perspective from either side. Maybe I just read that into the problem. I can see phase 2 being initiated from either side with the restrictions that I have described. Do you agree?

[ehirsel]

Normally the side that initiates phase 1 will also initiate phase 2, as the purpose of phase 1 (ike) is to get phase 2 (ipsec) working between the peers and to allow the phase 2 negotiation to be processed by the authenticated peers.

That said, the other issue that you have is that one side will have a dynamic ip address assigned, so static crypto maps between pre-define peers cannot be used. If both sides have dynamic assigned addresses you need to use TED, DNS or certificates as the only way the peers can recognize the other valid peer by name is to use a cert - dns may be used instead, but it has to be dynamic to account for address changes, and I don't know if cisco IOS routers can do what MS Win clients can - register their ip address to a dynamic dns.

As you found out, TED needs to be configured on both sides, as the side that is not configured will not respond to the probe packets.

Running GRE over IPSec to tunnel route protocol updates will allow the side that has the dynamic address to initiate the phase 1 to the other side and this is your best bet. DMVPN can be used in this case.

[virgilv]

With regards to DMVPN, what if I used "ip nhrp map x.x.x.x y.y.y.y" on both sides. I know you typically use a static map on the spoke side only, but I tried this and it seemed to half-way work. I'll explain:

I set up GRE tunnels with DMVPN and advertised the GRE tunnel network in EIGRP, along with loopback networks on either side. I had used an ip nhrp map on both the hub and the spoke. The tunnels came up and my loopbacks were advertised to both remote ends.

However, I did a "clear crypto isakmp" and "clear cyrpto sa" and then initiated a ping from the hub to the spoke (GRE tunnel IP), which failed. But then, after about 5 minutes, the GRE tunnel came up, I had isakmp sa's and IPSec sa's and I could ping the remote end. It seemed that exactly what I have been trying to set up (with the specified restrictions) could be done. However, the loopback addresses were never advertised again, unless I either cycled one of the routers or did a shut / no shut on the physical interface. The funny thing is that I did establish a neighbor relationship in EIGRP - yet the loopback addresses were not advertised - hence the "half-way worked".

Does this make any sence? By the way - my 3rd attempt on the Security Lab is this Friday.