[c-nsp] IPSec VPN config failure

[Oliver Boehmer (oboehmer)]

Hi,

can we see the config? I'm not sure (not an IPSec geek) if you can
prevent phase1 from coming up when the client enters an invalid dest.
address (the loopback in your case), but phase2 will check the local
address configured in "crypto map <name> local-address
<vlan-5-subif-address>" and the Phase2 proposal will be rejected.
("IPSEC(validate_transform_proposal): invalid local address" in cry
ipsec/isakmp debug).

	oli

cisco-nsp-bounces at puck.nether.net <> wrote on Monday, September 04, 2006
11:44 PM:

> Hi,
> 
> I would like to ask you to look at the schema linked below:
> http://zarenks.n1.pl/nsp/ipsec_problem.jpg
> and read the problem description I am expiriencing.
> 
> I had tested similar config at lab environment, and no
> problems occured
> there. For sime reasons, after implementing that solution at
> commercial environment, strange behaviour occured.
> 
> The correct connection shall work in the follwing scenario.
> 
> 1. VPN User using the Cisco VPN client requests the connection to its
>     VPN network. Coming from the Internet network, the session goes
> through the Router A, VLAN 5 and is terminated wihtin the customer
> VRF (which is a part of customer VPN network) . Then the call
> (already as a 
> VPN session)
> is going through VLAN 10 to Customer MPLS based VPN.
> 
> Error description:
> 
> By mistake, the as a security gateway IP Address the incorrect addres
> was entered (loopbac100 address was entered instrad of subinterface
> where the cryptomap is applied).
> In regular config the first phase of the connection (ISAKMP group
> authentication) should not be authenticated . What was my
> surprise when
> I saw the user prompt.
> It occured that the connection goed from internet directly to VLAN 10
> and to Loopback100. 
> 
> I shutdown the subinterface of VLAN 5 at Router A side  - it didn not
> help anyway. Finaly it helped when I remove the crypto from
> subinterface 
> od VLAN 5 at
> router B side.
> 
> When I applied the map again, incorrect behaviour accured again.
> 
> It looks like the ISAKMP is authenticated despite the fact
> that traffic
> is not going through the crypto map.
> 
> Is there any reasonable explanation for such case ?
> 
> (Cisco 7206VXR/ NPE-G1/ 1GB RAM @ 12.3.(14)T7 )
> 
> I will appreciate any help
> thanks
> Zarenks
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/