[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with Cisco VPN concentrator



At 16:58 03.12.2001 -0800, Bikramjit Singh wrote:
>We have developed kind of a VPN masquerade feature for our USG (Universal 
>Subscriber Gateway) product to let ISAKMP and ESP connections passthrough 
>from clients behind our gateway to respective VPN servers. We have taken 
>tips to do accurate routing for inbound traffic from the Linux VPN 
>Masquerade patch code. We are facing a weird problem with the Cisco VPN 
>Concentrator series 3000 ( and maybe all Cisco VPN servers).
>
>Since we are doing PAT ( port address translation) multiple subscribers 
>trying to connect to the same Cisco VPN concentrator are unable to do that 
>since Cisco can see only the our USG's IP address and the same port number 
>for ISAKMP (UDP/500) traffic from multiple subscribers. This way Cisco 
>keeps the most recent connection only and the earlier clients connection 
>gets dropped. Other devices (e.g Nortel Contivity) do not show such 
>behaviour and can keep simultaneous sessions even though coming apparently 
>( USG's IP address) from the same client ( i guess by differentiating them 
>on the basis of the ISAKMP initiator cookies).
>
>Cisco accepts the issue with PAT in its release notes and says that it 
>will accept multiple connection from the same client (apparently - 
>although in our case they are multiple clients being PATed on the same IP 
>address and same port) only if they have different source port numbers.
>
>Now the question. We want to support both Cisco and non-Cisco connection 
>going through are box without the user seeing any disconnections. Cisco 
>will work with normal PAT ( src ip/src port <---> USG IP/ assigned src 
>port) But others ( e.g Nortel) don't, which require both destination and 
>source port to be 500. Is there a way to "probe" the Cisco concentrator 
>that will till us that it is a "Cisco" and so we should do normal PAT 
>otherwise we should do our normal ISAKMP handling ( keeping track of cookies)?
>
>Anybody has any other solution/idea for it?
>
>thanks
>
>-Bik
>
>------------------------------------------------------------------------------------------ 
>
>Bik Singh                                   818-575-2518 (Off)
>Research Scientist                      818-597-1502 (Fax)
>Product Development                  31355 Agoura Road
>Nomadix                         Westlake Village, CA 91361
>

My comment is that our product VPN+ 5.4 Gateway behaves very much like
the Concentrator in this case.

The software maintain a list of "currently connected remote clients"
and the primary index for the list is (remote IP address;UDP port number).

So, having multiple clients mapped to the same (IP address;port number) pair is
a bad idea, the gateway will delete session all the time.

I just wonder... All PNAT implementations I've seen choose a random port
(per UDP "session") for clients. The PNAT I'm exposed to every day is a
FW-1. And it translates my UDP-500 IKE packets to src-address
712 or whatever port was free.

And this is the behaviour I would expect from ANY PNAT box!

If the contivity requires port 500 as src, I'd call that a bug.

I'm aware that this won't help much, sorry.

J–rn Sierwald


References: