[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: