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

RE: Problem with Cisco VPN concentrator



Title: RE: Problem with Cisco VPN concentrator

Michael, thanks for the input.. i have some comments inline

> -----Original Message-----
> From: Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca]
> Sent: Monday, December 03, 2001 7:01 PM
> To: Bikramjit Singh
> Cc: 'ipsec@lists.tislabs.com'; vpn@securityfocus.com
> Subject: Re: Problem with Cisco VPN concentrator
>
>
>
> >>>>> "Bikramjit" == Bikramjit Singh <BSingh@Nomadix.com> writes:
>     Bikramjit> We have developed kind of
>     Bikramjit> a VPN masquerade feature for our USG
> (Universal Subscriber
>     Bikramjit> Gateway) product to let ISAKMP and ESP
> connections passthrough
>
>   Noble. Please consider making your box do IPv6 with 6to4
> addresses (or
> preconfigured ones) as well.
>
>     Bikramjit> Since we are doing PAT ( port address
> translation) multiple
>     Bikramjit> subscribers trying to connect to the same Cisco VPN
>     Bikramjit> concentrator are unable to do that since Cisco
> can see only
>     Bikramjit> the our USG's IP address and the same port
> number for ISAKMP
>     Bikramjit> (UDP/500) traffic from multiple subscribers.
> This way Cisco
>
>   This isn't surprising. The box has no way to know that you
> are in fact
> multiple people behind the gateway.
>

Other concentrators like Nortel do distinguish different connections coming from the same IP/port by looking at initiator/responder cookie values ( i guess). i have been able to maintain multiple connections to the same Nortel server by 2 clients being address translated to the the same IP/port (a.b.c.d/500) at the same time. The cookie values will be different for different boxes behind our gateway.

>     Bikramjit> keeps the most recent connection only and the
> earlier clients
>     Bikramjit> connection gets dropped. Other devices (e.g
> Nortel Contivity)
>     Bikramjit> do not show such behaviour and can keep
> simultaneous sessions
>     Bikramjit> even though coming apparently ( USG's IP
> address) from the
>     Bikramjit> same client ( i guess by differentiating them
> on the basis of
>     Bikramjit> the ISAKMP initiator cookies).
>
>   That's certainly a common way do things, but it isn't required.
>
>   The other thing that some code does is to send everything
> from port 500,
> and demux on incoming based upon the ISAKMP cookies.  That way you
> interoperate with devices that insist on using port 500 for
> origination.

This is exactly what we are doing.. But with this configuration Cisco doesn't accept more than one connection. it drops the earlier connection. And if we disable this config and enable normal PAT mode where different source ports are assigned to ISAKMP sessions coming from different clients behind the gateway then Cisco can maintain multiple sessions but not the others (e.g Nortel expects to connect only if src port is 500). There is no way looking at the packet to know if it is going to a Cisco server or a non-Cisco server.

>     Bikramjit> Cisco accepts the issue with PAT in its
> release notes and says
>     Bikramjit> that it will accept multiple connection from
> the same client
>     Bikramjit> (apparently - although in our case they are
> multiple clients
>     Bikramjit> being PATed on the same IP address and same
> port) only if they
>     Bikramjit> have different source port numbers.
>
>   Okay, that's the opposite situation than I'd expect :-)

>     Bikramjit> Now the question. We want to support both
> Cisco and non-Cisco
>     Bikramjit> connection going through are box without the
> user seeing any
>     Bikramjit> disconnections. Cisco will work with normal
> PAT ( src ip/src
>     Bikramjit> port <---> USG IP/ assigned src port) But
> others ( e.g Nortel)
>     Bikramjit> don't, which require both destination and
> source port to be
>     Bikramjit> 500. Is there a way to "probe" the Cisco
> concentrator that
>     Bikramjit> will till us that it is a "Cisco" and so we
> should do normal
>     Bikramjit> PAT otherwise we should do our normal ISAKMP handling (
>     Bikramjit> keeping track of cookies)?
>
>   At a minimum, I guess you need to offer a way a way to
> configure PAT or not
> on a per-destination basis.
>

Yes, but is there a way to probe the destination and prompt it to say " I am a Cisco " other than snmp (for which we would need apriori knowledge of the community) and is still not a certain response..

>   You might be able to probe by doing a minimal IKE exchange
> and looking for
> vendor ID strings, but this would be bad.
>

How would you do this?? I do have at my disposal another IP address on the gateway which i could use for such activity ( this would make the Cisco VPN not disconnect the client because its being PATed onto a different IP address ).

>   Offer IPv6 as well and you can help this problem go away in
> the future.

not an option right now.

>
> ]       ON HUMILITY: to err is human. To moo, bovine.        
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON 
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca
> http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking,
> security guy");  [
>