From owner-freebsd-stable  Fri Mar  5  8:58:59 1999
Delivered-To: freebsd-stable@freebsd.org
Received: from horse.supranet.net (horse.supranet.net [205.164.160.8])
	by hub.freebsd.org (Postfix) with ESMTP id D0EF4151C5
	for <FreeBSD-Stable@freebsd.org>; Fri,  5 Mar 1999 08:58:53 -0800 (PST)
	(envelope-from gavinb@supranet.net)
Received: from rat (rat.supranet.net [205.164.160.15])
	by horse.supranet.net (8.9.3/8.9.3) with SMTP id KAA18609
	for <FreeBSD-Stable@freebsd.org>; Fri, 5 Mar 1999 10:58:36 -0600 (CST)
Message-Id: <4.1.19990305105214.00d53630@mail.supranet.net>
X-Sender: gavinb@mail.supranet.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 05 Mar 1999 10:59:38 -0600
To: FreeBSD-Stable@freebsd.org
From: Benjamin Gavin <gavinb@supranet.net>
Subject: Question about Natd/IPFW
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi all,
  It's me again, finally having resolved my problems with NATd and IIS 4.0.
 There was a twofold answer to the problem:

1)  This doesn't really involve FreeBSD, but IIS4 has a bug that it won't
necessarily reply on the same ethernet interface that it receives the
request on.  (Leave it to M$...)

2)  The following two lines prevent the retranslation of the internal IP
when the packets come back out from the web server through the firewall:

$fwcmd add 100 pass all from any to any via lo0
$fwcmd add 200 deny all from any to 127.0.0.0/8

  To test it I ran tcpdump on the external interface of the firewall.  What
I saw when these two rules were in the ipfw configuration was the following:
1)  The request comes into the server, gets redirected through natd to the
internal IP
2)  The reply from the internal machine gets passed through the firewall,
and is received at the requesting host _WITH THE INTERNAL IP NUMBER STILL
ASSIGNED TO THE PACKET_.

  I was doing a tcpdump on both the requesting host and the firewall.
However, by removing these rules, the internal IP is successfully
retranslated and the request is sent to the host with the alias address
attached to the packet.  This only happens to packets that are redirected
using the redirect_port/redirect_address directives to NATd.  Is this a
bug??    Needless to say it was not obvious to me how these two rules could
cause the packets not to be re-aliased.  Can anyone offer an explanation?

Thanks,
Ben Gavin

/--------------------------------------------------------------------------/
  Benjamin Gavin - Senior Consultant

  ***********  NO SPAM!!  ************


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