Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Nov 2001 11:00:32 +0200
From:      Ruslan Ermilov <ru@FreeBSD.ORG>
To:        "Patrick O'Reilly" <patrick@mip.co.za>
Cc:        kendall@jedis.com, freebsd-questions@FreeBSD.ORG
Subject:   Re: An ipfw/nat port forwarding issue
Message-ID:  <20011121110032.F62423@sunbay.com>
In-Reply-To: <NDBBIMKICMDGDMNOOCAIIEDPDPAA.patrick@mip.co.za>
References:  <000a01c1722f$060cb510$f801a8c0@fmepro.com> <NDBBIMKICMDGDMNOOCAIIEDPDPAA.patrick@mip.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 21, 2001 at 07:48:25AM +0200, Patrick O'Reilly wrote:
> > From: Kendall Gifford
> > Sent: 21 November 2001 03:51
> 
> > LAN requests for the external interface come in via the
> > internal interface, pass through ipfw without any natd
> > intervention, and are then foobar try's to service the
> > www port 80 request (because it didn't get forwarded as
> > natd runs on the external interface). Since foobar isn't
> > serving up a www dinner, the client must starve.
> > Am I close? Any suggestions?
> >
> 
> Kendall - I think your summary above is spot-on!  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.
> 
> > The problem is when LAN clients try to access our web
> > server via foobar. Now, normally they are not supposed
> > to as the LAN's primary DNS server (not foobar) returns
> > the local address for the www server. But, sometimes
> > the clients, I assume due to very short time-outs,
> > insist on reverting to secondary DNS (foobar) which
> > gives them foobar's public IP.
> 
> 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?
> 
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.


Cheers,
-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011121110032.F62423>