using route maps for crypto maps

[tato386]

I have two possible next hops for a remote network. I need to use IPSec if using one and not the other. I figured I could use a route map like this:

access-list 20 permit 192.168.2.2

access-list 120 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

!

route-map mymap permit 10

match ip address 120

match ip next-hop 20

!

However, when I do this my crypto map says that it is incomplete:

!

crypto map vpnmap 1 ipsec-isakmp

! Incomplete

set peer 1.1.1.1

set transform-set vpnset

match address mymap

!

Is this not possible? I am running 12.2(4) IOS.

Thanks,

Diego

[gfullage]

It's not possible like you have it here, since your crypto map is expecting to use an ACL called mymap, and that doesn't exist. The route-map "mymap" doesn't get referenced by the crypto map just because it has the same name.

You're not going to be able to do this on this one router if both the next-hops to this remote network are out the same interface.

If they're out different interfaces, then make your crypto map reference the access-list, and only apply that crypto map to the one outbound interface, it'll then work just like a standard VPN.

If both next-hops are out the same interface, there's no way you can tell the router to encrypt the traffic if it's going to one particular next-hop and not the other. You're better off doing just the policy routing on this router, remove the crypto stuff all together, then put the crypto map config on the one next-hop router, that way if the packet's sent to that router it'll be encrypted by that router, if it's sent to the other one it won't be encrypted.

[tato386]

You bring up an interesting point here. Lets say that I apply a crypto map to an interface that is going to redirect the packets to another router that is available on the same segment as the original router interface. In other words, the packet will not exit via an interface on the router that receives that packet. Will the first router encrypt the packet then forward the packet? The destination router is not IPSec capable, but I want the packets to be encrypted by the first router. How can I accomplish this?

Thanks,

Diego

[gfullage]

IPSec doesn't work like that though, both ends need to be IPSec capable and have already built a tunnel between them before any packets will be encrypted. If no tunnel exists, then packets won't be encrypted, simple as that. For a tunnel to exist, both ends need to be IPSec capable and be configured appropriately.

There's no way to just have one router encrypt packets and forward them on without having some other device ready to accept them and decrypt them. Sorry.

[tato386]

I think that you misunderstood my question. I realize that their needs to be two routers running IPSec to create a tunnel, and there is. However, in order for IPSec router A to get to IPSec router B there are several routers in the middle. In my case it just so happens that the first hop in the path to IPSec router B is via a router that sits on the same segment as the interface that receives the packet that need to be encrypted and sent on its way to IPSec router B. My worry is that since the packets do not go "thru" the router, that is, in one interface and out another, the encryption won't happen. In my case, I have a router with and interface that has an IP of 10.0.0.1/24 and a crypto map applied. The crypto map says that the encrypted packets need to be sent to router 192.168.1.1. The first hop on the way to 192.168.1.1 is via 10.0.0.2. Will the first router encrypt and then forward to 10.0.0.2?

Diego

[gfullage]

OK sorry about that.

Sounds like you simply want to configure one-armed tunnelling, where the unencrypted packet comes in on the same interface that it needs to go out on, the same interface that the crypto map is applied to.

If so, then yes this works, but you need to make sure your routing is set up correctly. For example, all the hosts need to have a route to the remote network that points to 10.0.0.1. This router then needs a route to the remote network that points to 10.0.0.2. You need to turn off ICMP redirects on this interface so the router doesn't send an ICMP redirect to all the hosts telling them to send further packets straight to 10.0.0.2. Use the "no ip redirects" command on the interface for this.

Other than that, it should work fine, just watch your routing and you should be OK.

[tato386]

Got it.

I was missing the "no ip redirects". I was using the "no ip proxy-arp" cuz I knew I needed something like that but wasn't sure exactly what.

Thanks,

Diego