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

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.

    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.
 
    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. 

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

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

]       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");  [
References: