Subject: RE: [Capwap] RE: One issue "In order to support NAT, I recommend thatLWAPP only support one UDP port for Control tunnel and Data Tunnel"

From: Michael Montemurro <[email-masked]>
Date: Wed, 1 Mar 2006 10:15:53 -0500

Scott,

Yes there generally is a VPN between the branch and the main office. We've
run into situations where a customer uses NAT at the branch to limit IP
address allocation across branch offices.

Cheers,

	Mike 

> -----Original Message-----
> From: Scott G Kelly [mailto:[email-masked]] 
> Sent: March 1, 2006 9:34 AM
> To: Michael Montemurro
> Cc: capwap
> Subject: Re: [Capwap] RE: One issue "In order to support NAT, 
> I recommend thatLWAPP only support one UDP port for Control 
> tunnel and Data Tunnel"
> 
> Hi Mike,
> 
> Isn't there a VPN between the branch and the main office? If 
> not, there are very definite security concerns here. If so, 
> isn't this a configuration and routing problem, as opposed to 
> a capwap NAT traversal problem?
> 
> Maybe a simple ascii topology diagram would be helpful...
> 
> Scott
> 
> Michael Montemurro wrote:
> > David,
> > 
> > The scenario that I have observed where NAT traversal comes 
> into play 
> > is what I would call an enterprise branch scenario.
> > 
> > You have an AC that resides at the main office and a small remote 
> > branch office. There is still a requirement for centralized 
> control of 
> > the wireless network. The operating mode of the WTP at the branch 
> > location would likely be "Local MAC".
> > 
> > All control traffic between the AC and the WTP would 
> traverse the NAT. 
> > There are two options for the data traffic:
> > 1) The data traffic is bridged locally to the branch 
> network. In this 
> > case the STA would get an IP address on the LAN of the 
> branch network.
> > 
> > 2) The data traffic would traverse the WAN back to the AC. In this 
> > case the STA would get an IP address on a network that AC lives on.
> > 
> > Cheers,
> > 
> > 	Mike
> > 
> > 
> >>-----Original Message-----
> >>From: David T. Perkins [mailto:[email-masked]]
> >>Sent: February 28, 2006 5:44 PM
> >>To: Scott G. Kelly
> >>Cc: capwap
> >>Subject: Re: [Capwap] RE: One issue "In order to support NAT, I 
> >>recommend thatLWAPP only support one UDP port for Control 
> tunnel and 
> >>Data Tunnel"
> >>
> >>HI Emek,
> >>
> >>Last time around the scenario that you described below was 
> brought up, 
> >>I believe I asked questions like, "what IP address would the STA's 
> >>get, and where would their data be terminated". I don't remember 
> >>seeing a response. If there is a single WTP behind a NAT in a 
> >>geographical area, I believe that using a CAPWAP system is 
> >>inappropriate. It would be more cost effective (for both 
> hardware and 
> >>operations costs) to use a "stand alone AP".
> >>Also, I'm not sure if all CAPWAP ACs support multiple groups of 
> >>separately geograpically located WTPs. Note that since an AC is a 
> >>single point of failure, I certainly would not want to be in a 
> >>position as a service provider where I had multiple customers share 
> >>the same fate, unless the cost of the alternative was prohibative.
> >>I don't believe that this is the case.
> >>
> >>I really do want to hear motivations, with the alternative 
> listed, and 
> >>the tradeoffs for each approach. I've listed some of the 
> cons, can you 
> >>list some of the pros?
> >>
> >>Thanks,
> >>/david t. perkins
> >>
> >>On Tue, 28 Feb 2006, Scott G. Kelly wrote:
> >>
> >>
> >>>I, like David, wonder how realistic this concern might be. 
> >>
> >>In the first case described below (MSP's cloud-based AC manages 
> >>customer WTP), where does this WTP reside with respect to the 
> >>Internet? Wouldn't the provider need a secure tunnel to the 
> customer 
> >>edge in such cases?  The alternative is unauthenticated tuple-based 
> >>firewall holes - not a pretty picture from a security perspective.
> >>
> >>>In the second case described below (NAT traversal within a
> >>
> >>single administrative domain), is this realistic? Seems 
> more like an 
> >>abberation than a common case, and it seems clear that we 
> don' t want 
> >>to add this level of complexity just so we can deal with an 
> edge case. 
> >>It seems like the operational issues with this topology would more 
> >>than out-weigh any benefit.
> >>
> >>>----------------------------------------------------------------
> >>>From: Sadot, Emek (Emek) (esadotavaya.com)
> >>>Date: Tue, 28 Feb 2006 07:16:16 -0800 (PST)
> >>>
> >>>David,
> >>>
> >>>I was under the impression that the working group already
> >>
> >>went through
> >>
> >>>the "justification" process. To refresh our memory, I
> >>
> >>believe that the
> >>
> >>>key points that were brought up discussed the possibility that a 
> >>>service provider will connect their AC to their customer's
> >>
> >>WTPs across
> >>
> >>>a NAT device, or a cooperation which segments its 
> facilities by NAT 
> >>>devices and deploy the AC at the main site and the WTPs at remote 
> >>>sites (private side of NAT), or perhaps a deployment
> >>
> >>scenario would be
> >>
> >>>some sort of a hosted solutions environment, where the WTPs in the 
> >>>different NAT'ed customer enterprise sites are controlled
> >>
> >>by a central
> >>
> >>>AC which is part of the provider's hosted solutions equipment.
> >>>
> >>>My belief is that the CAPWAP protocol should not disallow the NAT 
> >>>traversal.
> >>>
> >>>Regards,
> >>>Emek
> >>>
> >>>-----Original Message-----
> >>>From: David T. Perkins [mailto:dperkins [at] dsperkins.com]
> >>>Sent: Monday, February 27, 2006 10:21 PM
> >>>To: zhaoyujin 31390
> >>>Cc: capwap [at] frascone.com
> >>>Subject: Re: [Capwap] One issue "In order to support NAT, I
> >>
> >>recommend
> >>
> >>>thatLWAPP only support one UDP port for Control tunnel and
> >>
> >>Data Tunnel"
> >>
> >>>HI,
> >>>
> >>>CAPWAP with NATs has come up from time to time on this list, and 
> >>>people have claimed that it is a "typical" or "basic"
> >>>scenario. I'm sorry, but I don't see it. Before the WG spends time 
> >>>resolving this issue, I'd really like to see STRONG justifications.
> >>>That is, why would you deploy a CAPWAP system split this
> >>
> >>way? And if
> >>
> >>>CAPWAP didn't support this NAT split, what would it cost
> >>
> >>you, or what
> >>
> >>>would you not be able to do?
> >>>
> >>>On Mon, 27 Feb 2006, zhaoyujin 31390 wrote:
> >>>
> >>>>Dear all:
> >>>>
> >>>>  I recommend that LWAPP only support one UDP port for Control 
> >>>>tunnel
> >>>
> >>>and Data Tunnel. 
> >>>
> >>>>  LWAPP protocol uses UDP packets, so that it can
> >>
> >>directly support
> >>
> >>>>NAT
> >>>
> >>>passthrough.
> >>>
> >>>>  One basic scenario is that WTP is behind NAT device and AC is in
> >>>
> >>>public network. For control tunnel, there are no problem. 
> >>
> >>Because it
> >>
> >>>is initiated by WTP, NAT device can create corresponding table for 
> >>>LWAPP control tunnel packets.
> >>>
> >>>>  The problems is:
> >>>>
> >>>>   1. The data packets can not be firstly sent from AC to WTP.
> >>>>
> >>>>   2. Even if WTP firstly sends pacekts, AC can get the 
> >>>>corresponding
> >>>
> >>>control tunnel with this LWAPP data tunnel based on the packets.
> >>>Because in one NAT device, there may be multiple WTP. All WTP's IP 
> >>>addresses are same which is NAT device global IP address,
> >>
> >>and AC can
> >>
> >>>not know the data packets belonging to which AP.
> >>>
> >>>>
> >>>>Best regards
> >>>>Yujin Zhao
> >>>>H3Com
> >>>
> >>>Regards,
> >>>/david t. perkins
> >>>
> >>>
> >>>_________________________________________________________________
> >>>To unsubscribe or modify your subscription options, please visit:
> >>>http://lists.frascone.com/mailman/listinfo/capwap
> >>>
> >>>Archives: http://lists.frascone.com/pipermail/capwap
> >>>
> >>
> >>_________________________________________________________________
> >>To unsubscribe or modify your subscription options, please visit:
> >>http://lists.frascone.com/mailman/listinfo/capwap
> >>
> >>Archives: http://lists.frascone.com/pipermail/capwap
> >>
> > 
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Scott G Kelly <[email-masked]>
Date: Wed, 01 Mar 2006 07:27:16 -0800

Okay, so unless I'm missing something, isn't this just a routing/config 
problem?