[c-nsp] IPSec to MPLS VPN

[Oliver Boehmer (oboehmer)]

Kristofer Sigurdsson <> wrote on Tuesday, April 25, 2006 3:34 PM:

> I'm trying to setup IPSec access to an MPLS VPN via an 1841 router's
> EasyVPN server.  The router is connected via one interface, which is
> the routers general uplink, for both MPLS stuff and clients coming in
> from various places.
> 
> So, to sum it up, users are supposed to VPN into the box and get put
> in a VRF, which is a part of an MPLS VPN.  I've got most of it
> working, I can VPN (via IPSec) to the box, I can ping between the box
> and the client.  Also, the MPLS VPN is working, other routers on the
> network can ping a loopback on the 1841, which is in that VRF, the
> 1841 can ping other addresses in the MPLS VPN.
> 
> The problem, however, is that the VPN clients cannot reach anything
> beyond the 1841.  The route is redistributed, I can see that via "show
> ip route vrf FOO <ip>" on the other routers, but no traffic is passed.
>  Traceroute goes nowhere (just asterisks).
> 
> On a related note, the direct uplink router from the 1841, a 7301,
> marks the routes with "MPLS Required" when I do a "show ip route vrf
> FOO <ipaddress>", but it still works for the addresses on the 1841,
> but not for it's clients.
> 
> Please tell me this is not an example of Cisco's silly "you can't go
> out the same interface you came in through" IPSec rule?

I have never used MPLS on the 1841, but on other platforms there is
(almost) nothing wrong running such a setup "on-a-stick", i.e. having
"crypto map" and "mpls ip" on the same interface. The only caveat is
that IOS can't encrypt and tag-encapsulate the packets at the same time,
i.e. the encrypted packets (those in the global routing context) back to
your IPSec peer will not be tag-switched but rather sent as IP, so your
next-hop needs to encapsulate them into MPLS (if desired).

I am not sure if this has ever been tested on the low-end devices like
the 1841. Can you check your config on a different platform (7200/7301,
etc.)?

	oli