I'm not sure I follow what you mean by "Put them off a routed public IP'ed interface to solve this."
At one point, we had 2 interfaces per machine, 1 public and 1 private. The problem with that was that the use of our IP space was extremely ineffecient, not to mention that firewalling Windows 2000 and Windows 2003 Servers is a joke when you have multiple IPs on the same public interface -- (as in, RRAS has issues with this working sporadically, and we have had machines get PWNED because of it). We've had zero problems with the NAT setup, made MUCH better use of the IP space, and the new setups are MUCH simpler. The *only* consequence of this is the need for screwing around with DNS so that these things can actually communicate with each other in the internal network, and boy is it a pain. And yes, I do realize that all of these high end firewalls don't do this-- I conceded that in the first email. But I just fail to see why such complex devices cannot be designed to communicate with *themselves*--- can a machine with an ip address of 192.168.0.1 not make a tcp connection to itself with a source port of 10000 and a destination port of 80? Sure it can! Why is this such a difficult thing to accomplish on a device that also performs NAT? I realize that a simple concept does not necessarily translate into "simple code" (I do possess a 4 year BS degree in Computer Science, so I do have an appreciation for the gravity of that statement)-- and I have never written *actual* code for anything even resembling a router/NAT device (only pseudo code), but it just doesn't occur to me that the code to make this work would be that incredibly complex, but rather simple-- probably simpler than the code in the PIX that takes apart the TCP and UDP port 53 packets and recreates the response packets that contain the internal IPs instead of the external ones. Am I incorrect or out of line here? I'm just looking for an answer other than "well, the cisco's don't do it, so don't expect it out of (insert device/firewall here)". This is not meant to be argumentative-- I am trying to _understand_ why. WHY WHY WHY?!?!? :) Dimitri Rodis Integrita Systems LLC -----Original Message----- From: Chris Buechler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 25, 2005 11:18 PM Cc: [email protected] Subject: Re: [pfSense Support] Accessing NATed services from behind the NAT On 8/26/05, Dimitri Rodis <[EMAIL PROTECTED]> wrote: > Put it this way: > > A $60 linksys router can do this (WRT54G with stock firmware, for > example)... Why can't these expensive ones do it? real simple - there's a HUGE difference between doing it for systems that only support one public IP and doing it for ones that support limitless ones. Big difference between something that supports all kinds of NAT, and something that butchers the term "DMZ" in everyone's head as port forwarding, its only real NAT support. (I'm a Cisco fan in general, but screw them for buying a company that's done something so stupid) If it were a simple, easy fix that Linksys magically came up with, Cisco would have yanked it from its new little brother company and put it in the PIX. Even the latest, greatest brand spanking new PIX OS 7 doesn't support that. It does do automatic DNS translation though, if the DNS queries traverse the PIX, so it has its ways of eliminating the problem for DNS names. It's something we'll see eventually. But in the case of a real hosting environment, you probably shouldn't be running NAT to your servers anyway. Put them off a routed public IP'ed interface to solve this. or use your beloved Linksys. ;) -cmb --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
