On 03/10/2013 12:19 AM, Alan McKinnon wrote: > On 10/03/2013 03:42, Walter Dnes wrote: >> On Fri, Mar 08, 2013 at 07:41:13PM -0500, Michael Mol wrote >> >>> The trouble with NAT is that it destroys peer-to-peer protocols. >>> The first was FTP in Active mode. >> >> In its day, it was OK. Nowadays, we use passive mode. What's the >> problem? >> >>> SIP has been heavily damaged as well. Anyone who's used IRC is >>> familiar with the problems NAT introduces to DCC. >> >> Every ADSL router-modem I've run into recently has >> port-forwarding. >> >>> Anyone who's ever played video games online,... >> >> A *CLIENT* that can't operate from behind NAT is totally >> brain-dead. >> >>> or who's tried hosting a Teamspeak or Ventrillo server, has had >>> NAT get in their way as well. >> >> Port-forwarding. > > > All those examples you give are much like a bunch of home machines > sitting behind a NAT gateway onto the internet. That's actually OK > and I reckon that is the intended use of NAT.
I want to point out that that's only true if the home network has at least one public IP. If you've got NAT 4x4, you're kinda screwed. (Alan will understand that, but for those unfamiliar with it, that basically means that if your home router is given an RFC1918 address by your ISP, port forwarding isn't going to do squat for you.) I've got a friend in a rural area who can't get a publicly-routable address. To access his home network from work, he rents a VPS and sets up a static tunnel. Such are the evils of NAT. > Personally, I'd prefer all of my machines to have a public address > but there's no chance in hell my NetOps colleagues are giving me that > with my DSL connection. Well, with IPv6, they're supposed to. ^^ > > We have any years of experience now with consumer connections and > the users that use them, these guys mostly can't admin a machine to > save their lives, so NAT in their case is a good thing on balance. There's nothing NAT really offers them that having a default simple firewall on their network gateway wouldn't solve. If inbound traffic is part of an established or related connection, accept it. Otherwise, reject it by default. That's all the security benefit NAT accomplishes, albeit without mangling any packets. > > The true evil of NAT comes about when some clown starts implementing > it on the network itself. I'm in city X, we have a large office in > city Y, and most of the traffic Y->X goes through a *router* doing > NAT. No-one knows anymore why this was originally done but we all > know what it will take to undo it. To get our backend systems to work > for client in city Y I have to put in the cursed "any any" firewall > rules, and that sends our Risk fellows ballistic for good reason. But > I have no choice, the network design essentially discarded all > information as to who the client is, so now I must allow all of > them. > > Any real-life network that grew organically over several years is > always going to be rife with examples of fuck ups like this, always > done in the name of expediency. I have lots of such examples, the > above is only the first that came to mind. > > So whereas NAT behind a home router for IPv4 is good, in almost > every other usage I've seen it is bad and really just a case of a > solution used in places it never ever belonged. NAT behind a home router is bad, too. For IPv4, it's only necessary because there aren't enough IPv4 addresses to let everyone have a unique one. (It's unfortunate we never got DHCP-PD for IPv4; that would solve a number of problems I've seen and foresee with small-business IPv4 networks both pre- and post-crunch.)
signature.asc
Description: OpenPGP digital signature
