Hi Stig, On Tue, 2008-07-15 at 12:38 +0200, Stig Johansen wrote: > Make sure the traffic enters the VRF correctly via a ISAKMP-profile. > Check the following quickly hacked example:
Thank you (and others) very much. It was exactly the VRF part of the ISAKMP profile that was missing. It seems a little unintuitive to me; I thought that the traffic on the outside interface was "non VRF" when going towards the global next hop, and that I could thus use a regular ISAKMP setup for the IPSec tunnel. BTW: Is this "crypto isakmp profile" the new "best practice" way of doing things? It seems to be the only way to make the example work, but sometimes I feel it's a little overkill to have to define key-ring + profile instead of just using "crypto key ...". Are there other benefits of the profile way of doing things? > Given that the peers are directly connected at outside interfaces with a > 192.0.2.0/24-network. If not, adjust peer-ip's and add default route in > global routingtable. No routing *into* VRF's are needed, just outgoing > for the network-destination to be routed out into global-table, > encrypted or not. Ok. I presume the routing back into the VRF is needed if the traffic is not encrypted. Otherwise the router wouldn't know how to process incoming traffic. I guess with the ISAKMP/IPSec setup the router can infer where to route traffic, but without it would have no clue. Regards, Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
