Do you think you really need to go over this problem here. This is the way freebsd works presently This is the way a PIX works presently This is not the way linux works presently. This is not the way linksys works presently
If you cannot work with this don't use it. Where is the problem. Personally I don't see the need to Look at this information on this list. If you need to do Some personal research do it somewhere else??? I am happy with this. For my public IP's I don't use NAT I use bridging. As chris mentioned before then you don't have the issue. Alternatively. You could you NAT to sort outbound NATs to internal IPS this works for me in some locations as well.ie if source LAN and destination is public interface:80 to NAT opt1ip:80 These are solutions to a problem if they don't work for you then look on the internet to find out why. Not here please It seems like a case of your problem you sort it out. -----Original Message----- From: Dimitri Rodis [mailto:[EMAIL PROTECTED] Sent: 26 August 2005 08:50 To: Chris Buechler Cc: [email protected] Subject: RE: [pfSense Support] Accessing NATed services from behind the NAT 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
