[c-nsp] Remote Access 2 MPLS VPN - complicated scenario

Sebastian piestaga at aster.pl
Thu Aug 4 02:28:19 EDT 2005


Hi,

I have got quite interesting scenario but without your help I don't
think I am able to cope with it.

Cisco VPN client is connectiong to IPSec aggregator through one of
two available VLANs (say VLAN1 is a global one and VLAN2 is for IPSEC)

On the aggregator I put the VLAN2 interf. into transitional VRF say:
TEMP not to Customer VRF say: CUST.
(I can't put it directly to Customer's VRF, because of security reason
and possible routes leaking)

I see that the IPSec session between customer's PC (Cisco VPN Client)
and IPSec aggregrator is established correctly.
The IPsec session is coming from Internet through VLAN2 and vrf TEMP,
next the isakmp configuration parameters says that those session is to
be placed into destination VRF which is CUST vrf.
So the setup of IPSec tunnel works perfect.

!!!

Problem is that I have no connectivity inside that IPSec tunnel.

VLAN1 is the default vlan what means it is located within global
routing table.


What I see in CUST vrf is for example:

     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.5 [1/0] via 20.20.20.2

!!! and all remaining customer's MPLS routers !!!

My problem is that (in this case) address 20.20.20.2 is remote
user unknown address CEF is not able to find a route to that IP.
It should (somehow) find that in TEMP vrf.
Of course the TEMP vrf has a default set on the Internet facing
interface but it does not help.

When debug ip packet on aggregator when pinging from the PC the
loopback interface that is located within CUST vrf I can see
the following output.

IP: tableid=3, s=4.4.4.5 (GigabitEthernet0/2.102), d=99.99.99.99 (Loopback9999), routed via RIB
IP: s=4.4.4.5 (GigabitEthernet0/2.102), d=99.99.99.99, len 60, rcvd 4

IP: s=99.99.99.99 (local), d=4.4.4.5, len 60, unroutable


whereas the TEMP vrf routing table shows:

     1.0.0.0/30 is subnetted, 1 subnets
C       1.1.3.0 is directly connected, GigabitEthernet0/2.102
S*   0.0.0.0/0 [1/0] via 1.1.3.2

1.1.3.1 and 1.1.3.2 are both ends of VLAN2, and address 20.20.20.2 is
routable from TEMP vrf table point of view.

Do you have any idea, how to force the routing proccess to send the
traffic back to Customet PC via the same VLAN2 the IPSec session is
established ?

I would be grateful for any help or remarks

Regards
Sebastian




More information about the cisco-nsp mailing list