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