From owner-freebsd-questions Tue Nov 27 17:47:43 2001 Delivered-To: freebsd-questions@freebsd.org Received: from ns1.infowest.com (ns1.infowest.com [204.17.177.10]) by hub.freebsd.org (Postfix) with ESMTP id 37DBD37B417 for ; Tue, 27 Nov 2001 17:47:40 -0800 (PST) Received: from kgifford (www.fmei.com [65.100.240.153]) by ns1.infowest.com (Postfix) with ESMTP id 114012174F for ; Tue, 27 Nov 2001 18:47:39 -0700 (MST) Reply-To: From: "Kendall Gifford" To: Subject: Some natd configuration question(s) Date: Tue, 27 Nov 2001 18:47:38 -0700 Message-ID: <000001c177ae$a9905d70$f801a8c0@fmepro.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A while back I (Kendall Gifford) wrote: >> We have a DSL connection to which a FreeBSD 4.4-Stable box >> is connected called foobar. Foobar is the LAN's NAT-firewall. >> Our web server is inside our LAN and all requests are >> naturally forwarded by natd. The problem is when LAN clients >> try to access our web server via foobar.... [chop] I also mentioned that we run LAN-only DNS so that in normal operation, a LAN web client shouldn't try to access the web site via foobar. On Tuesday [11/20/2001] Patrick O'Reilly responded: > ...natd does run on a psecific interface (specified by the > -n or -a argument to natd), and since the offending packets > are entering 'foobar' via a different interface, natd does not > have an opportunity to do its work. ...[whack]... > I think you need to address this problem on your primary DNS. > Make sure it responds and services your internal clients > reliably. Is the internal DNS server also FreeBSD? No, the DNS server is a Windows machine over which I have no administrative control :-(. It just can't be depended upon to always be up (as is evident by the presence of this whole issue). On Wednesday [11/21/2001] Ruslan Ermilov wrote: > Alternatively, you can run a second copy of natd(8) on your > LAN interface (on the firewall box), and feed it with traffic > from your LAN machines to your public IP spool. That way, > your WWW server running on public IP address will see requests > coming from the NAT machine, and reply packets will undergo > a reverse process, and all should be working as expected. > The rule of thumb: make sure the reply packets go through > the NAT as well. First off, thanks Patrick, Ruslan, and Kjell (not quoted) for the help, and sorry for not acknowledging for so long. I have a second copy of natd running now and I feed it the traffic from my LAN machines trying to reach my public IP interface. I have verified that this second copy of natd is getting the packets, but I'm not sure how to configure natd in this situation. The options to natd that I have tried (and that haven't worked) are: (present in all variations): ] interface xl1 ] port 8670 (the one ipfw diverts to this copy of natd) ] log (have tried various combinations of these options): ] reverse ] redirect_port tcp :80 80 ] proxy_only ] proxy_rule port 80 server :80 I'm just not very sure what some of the settings do and would welcome any suggestions, enlightenment, or direction where to get such extended information. ____________ Kendall Gifford kendall@jedis.com http://kendall.jedis.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message