Posted by: Anonymous Coward
on January 27, 2004 09:27 AM
A few points about your comments. I see and respond to your major arguments as follows:
1. Configuration of a firewall is difficult.
Current firewall management software is getting easier and easier, local firewalls (as included in many Linux and I believe new Windows distributions) would come with a configuration allowing outgoing connections without incoming connections. Standard firewalls (linux based) I have used come with very reasonable default configurations as well as have good utilities for changing the configurations.
2. Applications work through NAT without problem.
Yes you can port forward but if the app has ip information in the payload your NAT must have a special module or code to handle rewriting that app. There are many cases where this was necessary (a quick look at my firewall shows modules for FTP, H323, Quake3, and many more).
New apps must have a module written, the developers have to write additional code for handling NAT (slowing development and making some tasks impossible) or it just doesn't work through NAT.
Several internal servers have problem using the same external address and port (ex: I want to have ssh access to several internal machines but port 22 is forwarded only to one). Yes there are ways to overcome this but they complicate the environment.
3. NAT does not complicates troubleshooting.
NAT clearly adds a step of checking to see what address/ports are being translated (if you have access to the point where NAT is being done). It also adds the possiblility of running out of ports with port-forwarding (many internal addresses using the port space of one or a few external addresses).
4. NAT hinders the ability of the destination to find out what the actual source address is.
You seems to think this is not the case. How would you stop a client (potentially infected or misbehaving) from DOSing you on port 25 (SMTP) while still allowing well-behaving clients to connect?
IMO, NAT was a solution to limited IP address space. People later found it provided some security, which it does. It does so much in the same way you CAN pound a nail in with a screwdriver (it is not a good tool for the job).
When you implement a sufficient address space (such as with IPv6) NAT boxes can be replaced by firewalls. This results in better application support, reduced network app development costs, easier troubleshooting and a simpler network design (one global address space).
Learn about Linux
Download Linux
Get Linux help
Re:I hate NAT :-)
Posted by: Anonymous Coward on January 27, 2004 09:27 AM1. Configuration of a firewall is difficult.
Current firewall management software is getting easier and easier, local firewalls (as included in many Linux and I believe new Windows distributions) would come with a configuration allowing outgoing connections without incoming connections. Standard firewalls (linux based) I have used come with very reasonable default configurations as well as have good utilities for changing the configurations.
2. Applications work through NAT without problem.
Yes you can port forward but if the app has ip information in the payload your NAT must have a special module or code to handle rewriting that app. There are many cases where this was necessary (a quick look at my firewall shows modules for FTP, H323, Quake3, and many more).
New apps must have a module written, the developers have to write additional code for handling NAT (slowing development and making some tasks impossible) or it just doesn't work through NAT.
Several internal servers have problem using the same external address and port (ex: I want to have ssh access to several internal machines but port 22 is forwarded only to one). Yes there are ways to overcome this but they complicate the environment.
3. NAT does not complicates troubleshooting.
NAT clearly adds a step of checking to see what address/ports are being translated (if you have access to the point where NAT is being done). It also adds the possiblility of running out of ports with port-forwarding (many internal addresses using the port space of one or a few external addresses).
4. NAT hinders the ability of the destination to find out what the actual source address is.
You seems to think this is not the case. How would you stop a client (potentially infected or misbehaving) from DOSing you on port 25 (SMTP) while still allowing well-behaving clients to connect?
IMO, NAT was a solution to limited IP address space. People later found it provided some security, which it does. It does so much in the same way you CAN pound a nail in with a screwdriver (it is not a good tool for the job).
When you implement a sufficient address space (such as with IPv6) NAT boxes can be replaced by firewalls. This results in better application support, reduced network app development costs, easier troubleshooting and a simpler network design (one global address space).
#