[Users] Re: Cisco 3000 Concentrator

-----BEGIN PGP SIGNED MESSAGE----- Admin Note: Post to users@lists.freeswan.org for a larger audience - sfs-users is a virus/spam filtered sublist.

And now onto the problem at hand:

On Wed, 26 Feb 2003, David Prestwich wrote:

> According to the company, the Cisco Concentrator is behind the firewall in a
> DMZ. When we try to bring up the connection we get the following:
>
> From our secure log for the authentication I'm seeing similar results.
> ---------------------------snip---------------------------------------
> Feb 25 13:04:03 zen Pluto[7826]: "test" #28793: initiating Main Mode
> Feb 25 13:04:04 zen Pluto[7826]: "test" #28793: ignoring Vendor ID payload
> Feb 25 13:04:04 zen Pluto[7826]: "test" #28793: we require peer to have ID
> '209.226.X.B', but peer declares '10.190.180.10'
> Feb 25 13:04:15 zen Pluto[7826]: "test" #28793: ignoring Vendor ID payload
> Feb 25 13:04:15 zen Pluto[7826]: "test" #28793: we require peer to have ID
> '209.226.X.B', but peer declares '10.190.180.10'
> Feb 25 13:04:34 zen Pluto[7826]: "test" #28793: ignoring Vendor ID payload
> Feb 25 13:04:34 zen Pluto[7826]: "test" #28793: we require peer to have ID
> '209.226.X.B', but peer declares '10.190.180.10'
> Feb 25 13:04:45 zen Pluto[7826]: "test": terminating SAs using connection
> -------------------------snip-------------------------------------------
>
> The company has never created a Lan-to-Lan connection with their Cisco 3000
> Concentrator before. We were supposed to be their first. They do however
> have several client connections for remote users that are working.
>
> So after several days explaining to them why we believed their configuration
> was incorrect ( it seems obvious to us that their endpoint is declaring its
> internal IP) with either the PIX or the Concentrator, they decided to open a
> task with Cisco.
>
> The Cisco guy conferenced in with us and we tried for a couple of hours to
> get things running. We made little progress while he took several logs.
> After a day of him “looking” into the problem, here was his response:
>
> “Well, I have run this scenario past a few people now. The general
> consensus seems to be that the Linux is looking more deeply into the packet
> than it needs to for some reason. I can't seem to find anything that
> supports the idea that if the clients are working ok with the concentrator
> behind the PIX, the L2L should be when going to a 3rd party device...
> However, there are a few changes I might make in the PIX config, just to
> test.”
>
> Has anyone else seen something like this? Cause I’m at a loss for word on
> what to do next.

NAT does things like this all the time. Things to try:

On your end, try setting forcing the ID:

rightid=10.190.180.10 or
rightid=@10.190.180.10

On the PIX side - they appear to be mangling IPSec packets somehow, which is inherently evil and gives problems like this. If they play to do IPSec connections to other devices, they will run into issues like this every time... giving a *real* ip to the 3000 is recommended for future sanity :)

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

I have a PIX stuffed in my desk here, perhaps I'll finally break it out. Anyone know how to crack the password of it? (Came from one of our now-closed/laid-off offices)

• -- Ken Bantoft The Unoffical FreeS/WAN Site: ken(at)freeswan.ca http://www.freeswan.ca PGP Key: finger ken@bantoft.org I'd rather run Unix than Windows or MacOS any day, because Unix sucks less. -- jwz

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPl6J01iWUusaxGxpAQH2kQP/U7YhN6ucCJcd+D16XvF/DnDgE0WBtOho pPQAPBbyL6q6JePUQeeXttFPSCpUfBGS2Ahfjv5lH+Bc5qmwV2ZoNpp4qqzg1Z79 QGgLrBcERatfFgb6jpVIjzzOz9choAbZvuEj8kKAtQKFNMBgvEs9c4J8GmlXDqD3 9/Wb1B0NMAo=
=QgYV
-----END PGP SIGNATURE-----