VPN3k problem: RRI not working with Backup LAN-to-LAN

[ovt]

Hi!

I'm trying to setup LAN-to-LAN IPSec tunnel from remote office VPN3k concentrator to the central site with two VPN3k concentrators connected to different ISPs. The remote office L2L tunnel is defined as "Originate-only" and two IP addresses of central site concentrators are provided. The central site L2L tunnels are defined as "Answer-only". Also, RRI is necessary at the central site in order to update the internal router routing table (obviously, each remote site can connect to different VPN concentrator at the central site for load-balancing purposes).

The problem is that RRI not working with "Answer-only" L2L tunnels -- the routing table of the concentrator is not populated with the static route to the remote site LAN. (SA with correct proxy IDs is established and traffic is flowing between sites.)

If I define the central site L2L tunnel as "Bidir." the routing table *is* populated with the static route to the remote LAN *regardless* of the presence of the tunnel. Obviously, this is unappropriate for redundancy -- the route should be added to the routing table when the tunnel is connected only.

Can anybody comment on this? Is it possible to achieve redundancy and simple load-balancing with L2L tunnels running from remote sites with a single VPN3k box to the central site with two VPN3k boxes installed.

Regards,

Oleg Tipisov,

REDCENTER

[cchristou]

Hello Oleg,

The VPN 3K look at the crypto access-lists to inject the relevant routes into the routing table, i.e, if you have net 10.0.0.0/0.0.0.255 defined for a particular remote site as interesting traffic, the VPN3K will use this and put it into the routing table regardless of whether the tunnel is up or not!! I too found out as you have now that this is not much good when you are tryng to provide a redundant solution. One thing I will say is that it has been maybe six months since I last tested this so I'm not sure if Cisco have enhanced this feature in the latest s/w version.

Regards

[ovt]

I'm running the latest VPN3k code. To my surprise, if the L2L tunnel is defined as "Answer-only", which makes sense for Central site office, it doesn't put the route into the routing table at all!

Oleg

[dhucaby]

Greetings,

I'm stuck on the same problem with a VPN3K too. I doubt if this will be enhanced any time soon. I'm finding that IOS, PIX, and VPN3K platforms all take the same approach - if an IPSec peer is statically defined (the peer address is configured into the crypto map), then RRI will always inject the route even if the tunnel is not up. However, RRI will inject routes dynamically if the peer falls within a dynamic crypto map policy.

This seems to be oriented more toward injecting routes for the benefit of VPN clients as they come and go. But in my mind, LAN-to-LAN tunnels should be considered similarly because they are not always up and in use. RRI should inject a route dynamically for any type of tunnel.

[ovt]

Hi!

In general I agree, but some clarification is needed here.

1. Yes, static crypto maps always add the static route even if the tunnel is not up, but dynamic IOS crypto maps add the route dynamically (when the tunnel is connected). Also, dynamic crypto maps can contain "peer" statements. The problem here is that dynamic crypto maps cannot initiate tunnels, even if they have "peer" statements. This should be considered as design BUG. It would be useful to configure crypto maps that can initiate tunnels AND add the route dynamically when the tunnel is connected.

2. VPN3k "Answer-only" L2L tunnels are, in essense, dynamic crypto maps with a peer statement. They cannot initiate tunnels. And unfortunetly they don't add the RRI route at all. This is clearly a BUG in the implementation (not a design bug).

3. VPN3k "Bidirectional" L2L tunnels are, in essense, static crypto maps. They add the RRI route even if the tunnel is not up. See 1.

In general, RRI is stupid thing for LAN-to-LAN. Obviously, running routing protocol (this may be even unicast RIP) over the tunnel is more appropriate for L2L.

Unfortunetly, VPN3k boxes have very limited functionality here. I think VPN3k NAD will not work if we have 2 concentrators at the central site (for redundancy and load balancing, VRRP is not used) and single concentrator at the remote site. But this should be carefully tested.

Oleg Tipisov,

REDCENTER