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

RE: IPSec NAT pass-through: how the server distinguish different clients?



Jayant,

Distinguishing the connections based on source port is for the non-UDP
encapsulation case. I have developed and tested IPsec ALG for our NAPT
product (USG) and while trying to do connections from multiple clients
behind the NAT we found that Cisco required floating of IKE source port
otherwise it will lead to termination of the original connection as soon as
a new client connected to the same VPN server.. We also found this in
Cisco's release notes for the concentrator we were using (3000 series).. 

Regards,

Bik

> -----Original Message-----
> From: Jayant Shukla [mailto:jshukla@trlokom.com]
> Sent: Thursday, September 05, 2002 8:05 PM
> To: BSingh@Nomadix.com; f_ye@yahoo.com; ipsec@lists.tislabs.com
> Subject: RE: IPSec NAT pass-through: how the server distinguish
> different clients?
> 
> 
> Hi Bik,
> 
> I am not very clear on your explanation. Is it for IPsec with UDP
> encapsulation or without?
> 
> If it is for IPsec (without UDP encapsulation), then I do not 
> understand
> your comment about distinguishing connections based on source port
> number.
> 
> The UDP encapsulation draft does not specify the use of ports 
> and lists
> this issue as one of the problems. Therefore, CISCO's 
> implementation may
> not be according to the draft.  
> 
> If they are using ports to distinguish the traffic, then there are IPR
> issues. We have patents pending that cover it. Although we are
> considering giving up our IPR, we have not done so yet. 
> 
> Regards,
> Jayant
> www.trlokom.com 
> 
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]
> > On Behalf Of BSingh@Nomadix.com
> > Sent: Wednesday, September 04, 2002 11:36 AM
> > To: f_ye@yahoo.com; ipsec@lists.tislabs.com
> > Subject: RE: IPSec NAT pass-through: how the server distinguish
> different
> > clients?
> > 
> > Feng,
> > 
> > I have observed that Cisco VPN concentrator distinguishes different
> > connections coming from the same IP (NAT IP) based on the 
> source port.
> So
> > you have to change the IKE source port for different connections
> coming
> > from
> > clients behind the NAT.. Then Cisco recognizes them as different
> > connections. But I have also observed that this is not reliable and
> the
> > connections break as Cisco sends some IKE packets back with
> destination
> > port
> > 500 which the NAT box doesn't know who to forward to.. And 
> even if you
> > forward to all clients it doesn't really stay on..
> > 
> > Best course is to do UDP encapsulation.
> > 
> > Hope this helps..
> > 
> > -Bik
> > 
> > > -----Original Message-----
> > > From: Feng Ye [mailto:f_ye@yahoo.com]
> > > Sent: Wednesday, September 04, 2002 9:30 AM
> > > To: ipsec@lists.tislabs.com
> > > Cc: Van Aken Dirk
> > > Subject: RE: IPSec NAT pass-through: how the server
> > > distinguish different clients?
> > >
> > >
> > > Thanks for the answer. But what I observed is the
> > > opposite. I captured all the packets in the server VPN
> > > side, what I see from the captured packets are:
> > > 1. When clientA talk with the server, there're ESP
> > > packets going back and forth with clientA's SPI (say,
> > > SPI_A) and server's SPI (say, SPI_S).
> > > 2. Then clientB start to talk with the server, I can
> > > see there're UDP/500 packets for main mode and quick
> > > mode.
> > > 3. Then clientB send ESP with a different SPI (say,
> > > SPI_B), however, upon receiving SPI_B, the server
> > > still responds with SPI_S, not a new SPI. So when this
> > > response packet reached my NAT box, the box has
> > > associated SPI_S with SPI_A so it forward the packet
> > > to clientA. This caused the problem.
> > >
> > > I think the problem is in server setting, how can the
> > > server distinguish different clients behind the NAT,
> > > since for all these clients, the server settings are
> > > the same: same tunnel destination IP address (the NAT
> > > public address), same protocol (ESP), same
> > > encryption/authentication (DES-MD5, etc).
> > >
> > > Anybody has a clue? Besides, this is not about UDP
> > > encapsulation, it's pure ESP packets.
> > >
> > > Thanks!
> > >
> > > feng
> > >
> > >
> > > --- Van Aken Dirk <VanAkenD@thmulti.com> wrote:
> > > > Hi Feng,
> > > >
> > > > Do I understand you correctly i.e.
> > > >
> > > > 1) packets form the clients to the server always use
> > > > the same SPI value
> > > >
> > > > 2) packets from the server to the clients use a
> > > > different SPI value per
> > > > client
> > > >
> > > > Can you confirm this ?
> > > >
> > > > BTW, regarding selection of SPI value it is
> > > > important to know that the SPI
> > > > is chosen by the receiving system.
> > > > i.e If a client wants to receive packets from a
> > > > server, it is the client
> > > > that tells the server which SPI value to use.
> > > >
> > > > Best regards - Dirk
> > > >
> > > > -----Original Message-----
> > > > From: Feng Ye [mailto:f_ye@yahoo.com]
> > > > Sent: Wednesday 4 September 2002 6:05
> > > > To: ipsec@lists.tislabs.com
> > > > Subject: IPSec NAT pass-through: how the server side distinguish
> > > > different client?
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I have implemented IPSec NAT pass through in the
> > > > access box by looking at cookie/SPI values. I can
> > > > sucessfully do the 1 to 1 and 1 to many cases, but
> > > > can't do the many to 1 case, because I don't know
> > > > how
> > > > to configure the public side VPN server.
> > > > That server don't know how to distinguish different
> > > > clients behind the NAT, because they all have the
> > > > same
> > > > tunnel endpoint IP address (the NAT public address),
> > > > and they all use ESP, and the same
> > > > encrypt/authenticate algorithm. So to the server,
> > > > all
> > > > of them belongs to the same SA. Captured packets in
> > > > the server side shows that even different clients
> > > > use
> > > > different SPI to talk to the server, the server
> > > > responses with the same SPI, thus caused the
> > > > problem.
> > > > I tested with cisco 2600 and win2000 as the VPN
> > > > server, all has the same problem.
> > > > Is anybody there can give me a clue? Thanks a lot!
> > > >
> > > > feng
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Finance - Get real-time stock quotes 
> http://finance.yahoo.com
> > >
> 
>