X-Account-Key: account1 X-UIDL: 110403 X-Mozilla-Keys: Return-Path: X-ListServer: CommuniGate Pro LIST 5.1.3 List-Unsubscribe: List-ID: List-Archive: Precedence: list Message-ID: Reply-To: "OS/2 Wireless Users Mailing List" Sender: "OS/2 Wireless Users Mailing List" To: "OS/2 Wireless Users Mailing List" X-Original-Message-ID: <468BCCC0.2070108@rollanet.org> Date: Wed, 04 Jul 2007 11:37:20 -0500 From: "Sam Lewis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Re: [OS2Wireless] NAT issues (was: Re: [OS2Wireless] NetWork World: IPv6 D-Day is coming up fast) Lewis G Rosenthal wrote: > On 06/30/07 01:03 pm, Sam Lewis thus wrote : >> Lewis, >> According to the presentation you linked "NAT is evil" Why is that? >> Why would designers hate it? >> Thanks, >> Sam >> > I guess that statement refers to the various issues with NAT and > traversal of point-to-point services (NAT-T, such as for VPN tunnels). > NAT can be a bear to deal with in this regard, mainly due to > implementations where RFC3235 has been ignored or taken too lightly > (see http://www.isi.edu/in-notes/rfc3235.txt). NAPT (the most workable > form of NAT) is not used nearly enough in small gateway devices (or > even in some of the larger boxes), leading to port translation issues > (i.e., the far end cannot remap an incoming port when the necessary > port is already in use by something else - and other such fun). > > Sometimes, it's a matter of just trial and error to find the right mix > of what works on each end (NAT, PAT, NAPT, MASQ). In the new Astaro v7 > gateway devices (and Astaro Security Linux), I'm now able to avoid > much of this by using generic proxies which are inherently more > secure than NAT by allowing the gateway to handle the transaction > between outside and inside instead of merely transposing the addresses > and/or ports and letting the traffic pass. > > I spent much time last week getting two IPSec VPNs to work with a > couple older Zyxel 600-series DSL boxes, which insisted upon infusing > their NATed inside interface addresses in the ID string of the IPSec > packets. I finally worked around the problem by specifying that > private IP as the VPN ID on the far end, thus "fooling" OpenVPN into > believing that it was getting a legitimate ID (using a private address > as a VPN ID is akin to using a skeleton key which fits a hundred > doors; how many private networks are 192.168.1.1?). > > NAT is just a mixed bag. It's great for some things and really tough > for others. When you need to share a single public IP between five or > ten machines, it's he only game in town and makes a lot of sense. > OTOH, when you need to also allow access to four servers behind the > NAT, then it becomes a sticky situation, better served with multiple > public IPs. > > Does that make a bit more sense, now, Sam? :-) > Uh, sure. I guess I relate NAT with personal/SOHO networks which just need internet access. Linking networks as in WANs I would think would need something a little more seamless. Thanks, Sam Scanned by WinProxy http://www.Ositis.com/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to To subscribe (new addresses), E-mail to: and reply to the confirmation email. Web archives are publicly available at: http://lists.2rosenthals.com This list is hosted by Rosenthal & Rosenthal, LLC P.O. Box 281, Deer Park, NY 11729-0281. Non- electronic communications related to content contained in these messages should be directed to the above address. (CAN-SPAM Act of 2003) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=