From nobody@FreeBSD.org  Tue May  2 15:28:48 2000
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 54A7C37C068
	for <freebsd-gnats-submit@FreeBSD.org>; Tue,  2 May 2000 15:28:47 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id PAA40429;
	Tue, 2 May 2000 15:28:47 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Message-Id: <200005022228.PAA40429@freefall.freebsd.org>
Date: Tue, 2 May 2000 15:28:47 -0700 (PDT)
From: goran.lowkrantz@infologigruppen.se
Sender: nobody@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org
Subject: NATD diverts DMZ packets to firewall host
X-Send-Pr-Version: www-1.0

>Number:         18354
>Category:       bin
>Synopsis:       NATD diverts DMZ packets to firewall host
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue May  2 15:30:01 PDT 2000
>Closed-Date:    Thu May 11 00:55:05 PDT 2000
>Last-Modified:  Thu May 11 00:55:27 PDT 2000
>Originator:     Goran Lowkrantz
>Release:        4.0-STABLE
>Organization:
Infologigruppen Norr AB
>Environment:
FreeBSD ns2.infologigruppen.se 4.0-STABLE FreeBSD 4.0-STABLE #0: Tue May  2 11:08:55 CEST 2000     root@ns2.infologigruppen.se:/usr/src/sys/compile/BIFROST  i386

>Description:
After upgrade from 3.4-STABLE to 4.0-STABLE, a firewall with attached DMZ started to act funny. All incomming data addressed to the DMZ was sent to the local firewall host.

Configuration

 Internet
    |
    |xl0 - 212.214.163.69/26
+---+---+xl1   +-----+
|  FW1  +------+ DMZ | - 212.214.162.32/28
+---+---+      +-----+
    |xl2 - 192.168.99.1/30
    |
    |de2 - 192.168.99.2/30
+---+---+
|  FW2  |
+---+---+
    |
    |
Internal
RFC 1918 net

After testing I found that this behavior was coupled with starting of natd. As long as the divert rule was missing in the ipfw ruleset the data flowed to the DMZ as expected. But as soon as the divert rule was enabled, no more data to the DMZ, all sent to FW host.
Natd was started as 
natd -f /etc/natd.conf -a 212.214.163.69

Content fo natd.conf:
log yes
log_denied yes
use_sockets yes
same_ports yes
unregistered_only yes

>How-To-Repeat:
Three NIC setup for DMZ, basic natd setup and start with any firewall type, have tested with open and had same problem.
>Fix:
Add a skip rule to the ipfw ruleset that jumps the divert rule for data to the DMZ network.

00098 skipto 100 ip from any to 212.214.162.32/28
00099 divert 8668 ip from any to any via 212.214.163.69
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8


>Release-Note:
>Audit-Trail:

From: Brian Somers <brian@Awfulhak.org>
To: goran.lowkrantz@infologigruppen.se
Cc: freebsd-gnats-submit@FreeBSD.org,
	Brian Somers <brian@awfulhak.org>, Ruslan Ermilov <ru@FreeBSD.org>,
	Charles Mott <cmott@scientech.com>, Eivind Eklund <perhaps@yes.no>,
	Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host 
Date: Tue, 09 May 2000 23:41:01 +0100

 > >Number:         18354
 > >Category:       bin
 > >Synopsis:       NATD diverts DMZ packets to firewall host
 
 This is happening because I changed the libalias(3) default so that 
 it drops packets from outside to inside on the gateway by default 
 rather than passing them into the (private) internal network.  This 
 behaviour can be altered using PacketAliasSetTarget().  IMHO this is 
 what people expect and is what the documentation indicated was the 
 intention.
 
 When I sent a patch to Ruslan (cc'd) adding a -t option to natd, he 
 pointed out that natd's documentation clearly doesn't expect this to 
 happen.
 
 We decided to ask about the original intentions and decide what to do 
 based on the outcome, but haven't received a reply from Charles (cc'd 
 as a gentle poke) yet.
 
 So, this is in limbo.  At the moment, there's no way to get the old 
 behaviour (maybe we should add the -t switch in the interim - Ruslan, 
 have you still got that patch?  Or if you don't want to do that, 
 perhaps we should just do a PacketAliasSetTarget(INADDR_ANY) in 
 natd.c for now).
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
 
 
 

From: Charles Mott <cmott@scientech.com>
To: Brian Somers <brian@Awfulhak.org>
Cc: goran.lowkrantz@infologigruppen.se,
	freebsd-gnats-submit@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host 
Date: Wed, 10 May 2000 00:38:36 -0600 (MDT)

 > We decided to ask about the original intentions and decide what to do 
 > based on the outcome, but haven't received a reply from Charles (cc'd 
 > as a gentle poke) yet.
 
 The original intention was that libalias would be cognizant
 of certain protocols (tcp, udp, icmp to start out with) and
 not alter or drop any other protocols.  My opinion at the time
 was that ipfw rules should deal with other protocols.
 
 However, it appears that libalias is being generalized to
 handle arbitrary protocols, and my original thinking may no
 longer be appropriate.
 
 My suggestion is that incoming packets for arbitrary
 protocols (and not associated with an static redirect rules
 or dynamic associations) be dropped if the PKT_ALIAS_DENY_INCOMING
 bit is set.
 
 Charles Mott
 
 

From: "Lowkrantz, Goran" <Goran.Lowkrantz@infologigruppen.se>
To: "'Brian Somers'" <brian@Awfulhak.org>
Cc: freebsd-gnats-submit@FreeBSD.org,
	Ruslan Ermilov <ru@FreeBSD.org>, Charles Mott <cmott@scientech.com>,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: RE: bin/18354: NATD diverts DMZ packets to firewall host 
Date: Wed, 10 May 2000 08:40:43 +0200

 OK. I understand. But I can't read this behavior from natd(8), as the 3d
 para don't mension what happens if no match is found or the IP isn't that of
 the firewall IF. If the current behavior is the intended, then it should be
 documented. And as it's a change in behavior, somthing should be said about
 it in the release notes. Was this patch given a HEADS UP?
 
 May I suggest somthing like this for natd(8)?
 
 Description - add to 3d para
 
 If no entry is found or the target IP is not the current machine, the packet
 is modified to the IP number of the current machine.
 
 Cheers,
 	GLZ
 
 > -----Original Message-----
 > From: Brian Somers [mailto:brian@Awfulhak.org]
 > Sent: Wednesday, May 10, 2000 12:41 AM
 > To: goran.lowkrantz@infologigruppen.se
 > Cc: freebsd-gnats-submit@FreeBSD.org; Brian Somers; Ruslan Ermilov;
 > Charles Mott; Eivind Eklund; Ari Suutari
 > Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host 
 > 
 > 
 > > >Number:         18354
 > > >Category:       bin
 > > >Synopsis:       NATD diverts DMZ packets to firewall host
 > 
 > This is happening because I changed the libalias(3) default so that 
 > it drops packets from outside to inside on the gateway by default 
 > rather than passing them into the (private) internal network.  This 
 > behaviour can be altered using PacketAliasSetTarget().  IMHO this is 
 > what people expect and is what the documentation indicated was the 
 > intention.
 > 
 > When I sent a patch to Ruslan (cc'd) adding a -t option to natd, he 
 > pointed out that natd's documentation clearly doesn't expect this to 
 > happen.
 > 
 > We decided to ask about the original intentions and decide what to do 
 > based on the outcome, but haven't received a reply from Charles (cc'd 
 > as a gentle poke) yet.
 > 
 > So, this is in limbo.  At the moment, there's no way to get the old 
 > behaviour (maybe we should add the -t switch in the interim - Ruslan, 
 > have you still got that patch?  Or if you don't want to do that, 
 > perhaps we should just do a PacketAliasSetTarget(INADDR_ANY) in 
 > natd.c for now).
 > -- 
 > Brian <brian@Awfulhak.org>                        
 > <brian@[uk.]FreeBSD.org>
 >       <http://www.Awfulhak.org>                   
 > <brian@[uk.]OpenBSD.org>
 > Don't _EVER_ lose your sense of humour !
 > 
 > 
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Charles Mott <cmott@scientech.com>
Cc: Brian Somers <brian@Awfulhak.org>,
	goran.lowkrantz@infologigruppen.se, freebsd-gnats-submit@FreeBSD.org,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host
Date: Wed, 10 May 2000 13:57:51 +0300

 On Wed, May 10, 2000 at 12:38:36AM -0600, Charles Mott wrote:
 > > We decided to ask about the original intentions and decide what to do 
 > > based on the outcome, but haven't received a reply from Charles (cc'd 
 > > as a gentle poke) yet.
 > 
 > The original intention was that libalias would be cognizant
 > of certain protocols (tcp, udp, icmp to start out with) and
 > not alter or drop any other protocols.  My opinion at the time
 > was that ipfw rules should deal with other protocols.
 > 
 > However, it appears that libalias is being generalized to
 > handle arbitrary protocols, and my original thinking may no
 > longer be appropriate.
 > 
 > My suggestion is that incoming packets for arbitrary
 > protocols (and not associated with an static redirect rules
 > or dynamic associations) be dropped if the PKT_ALIAS_DENY_INCOMING
 > bit is set.
 > 
 The question here is what to do if PKT_ALIAS_DENY_INCOMING is NOT SET!
 My opinion is that it should not be altered by libalias(3) at all.
 As of current, it is redirected (by default) to aliasAddress.
 
 As of PKT_ALIAS_DENY_INCOMING, is honored for TCP/UDP and generic proto
 packets.
 
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Brian Somers <brian@Awfulhak.org>
Cc: goran.lowkrantz@infologigruppen.se,
	freebsd-gnats-submit@FreeBSD.org, Charles Mott <cmott@scientech.com>,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host
Date: Wed, 10 May 2000 13:59:09 +0300

 On Tue, May 09, 2000 at 11:41:01PM +0100, Brian Somers wrote:
 > > >Number:         18354
 > > >Category:       bin
 > > >Synopsis:       NATD diverts DMZ packets to firewall host
 > 
 > This is happening because I changed the libalias(3) default so that 
 > it drops packets from outside to inside on the gateway by default 
 > rather than passing them into the (private) internal network.  This 
 > behaviour can be altered using PacketAliasSetTarget().  IMHO this is 
 > what people expect and is what the documentation indicated was the 
 > intention.
 > 
 > When I sent a patch to Ruslan (cc'd) adding a -t option to natd, he 
 > pointed out that natd's documentation clearly doesn't expect this to 
 > happen.
 > 
 > We decided to ask about the original intentions and decide what to do 
 > based on the outcome, but haven't received a reply from Charles (cc'd 
 > as a gentle poke) yet.
 > 
 But have managed to MFC the libalias(3) bits :)
 
 > So, this is in limbo.  At the moment, there's no way to get the old 
 > behaviour (maybe we should add the -t switch in the interim - Ruslan, 
 > have you still got that patch?  Or if you don't want to do that, 
 > perhaps we should just do a PacketAliasSetTarget(INADDR_ANY) in 
 > natd.c for now).
 > 
 I will add a PacketAliasSetTarget(INADDR_ANY) call today.
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: "Lowkrantz, Goran" <Goran.Lowkrantz@infologigruppen.se>
Cc: "'Brian Somers'" <brian@Awfulhak.org>,
	freebsd-gnats-submit@FreeBSD.org, Charles Mott <cmott@scientech.com>,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host
Date: Wed, 10 May 2000 14:06:24 +0300

 On Wed, May 10, 2000 at 08:40:43AM +0200, Lowkrantz, Goran wrote:
 > 
 > OK. I understand. But I can't read this behavior from natd(8), as the 3d
 > para don't mension what happens if no match is found or the IP isn't that of
 > the firewall IF. If the current behavior is the intended, then it should be
 > documented. And as it's a change in behavior, somthing should be said about
 > it in the release notes. Was this patch given a HEADS UP?
 > 
 > May I suggest somthing like this for natd(8)?
 > 
 > Description - add to 3d para
 > 
 > If no entry is found or the target IP is not the current machine, the packet
 > is modified to the IP number of the current machine.
 > 
 The correct behaviour is already documented (see the -a option's description):
 
 : If no other action can be made, and if -deny_incoming is not specified,
 : the packet is delivered to the local machine and port as specified in
 : the packet.
 
 I will restore this behaviour in a day or two.
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 

From: Charles Mott <cmott@scientech.com>
To: Ruslan Ermilov <ru@FreeBSD.org>
Cc: Brian Somers <brian@Awfulhak.org>,
	goran.lowkrantz@infologigruppen.se, freebsd-gnats-submit@FreeBSD.org,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host
Date: Wed, 10 May 2000 09:22:39 -0600 (MDT)

 On Wed, 10 May 2000, Ruslan Ermilov wrote:
 [..]
 > The question here is what to do if PKT_ALIAS_DENY_INCOMING is NOT SET!
 > My opinion is that it should not be altered by libalias(3) at all.
 > As of current, it is redirected (by default) to aliasAddress.
 
 I agree with your opinion.
 
 

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Charles Mott <cmott@scientech.com>
Cc: Brian Somers <brian@Awfulhak.org>,
	goran.lowkrantz@infologigruppen.se, freebsd-gnats-submit@FreeBSD.org,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host
Date: Wed, 10 May 2000 18:52:19 +0300

 --CE+1k2dSO48ffgeK
 Content-Type: text/plain; charset=us-ascii
 
 On Wed, May 10, 2000 at 09:22:39AM -0600, Charles Mott wrote:
 > On Wed, 10 May 2000, Ruslan Ermilov wrote:
 > [..]
 > > The question here is what to do if PKT_ALIAS_DENY_INCOMING is NOT SET!
 > > My opinion is that it should not be altered by libalias(3) at all.
 > > As of current, it is redirected (by default) to aliasAddress.
 > 
 > I agree with your opinion.
 > 
 Please, Brian, apply the following patch and close this PR.
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --CE+1k2dSO48ffgeK
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=p
 
 Index: alias_db.c
 ===================================================================
 RCS file: /usr/FreeBSD-CVS/src/lib/libalias/alias_db.c,v
 retrieving revision 1.29
 diff -u -p -r1.29 alias_db.c
 --- alias_db.c	2000/04/28 13:44:48	1.29
 +++ alias_db.c	2000/05/10 15:48:46
 @@ -2284,7 +2284,7 @@ PacketAliasInit(void)
      }
  
      aliasAddress.s_addr = INADDR_ANY;
 -    targetAddress.s_addr = INADDR_NONE;
 +    targetAddress.s_addr = INADDR_ANY;
  
      icmpLinkCount = 0;
      udpLinkCount = 0;
 Index: libalias.3
 ===================================================================
 RCS file: /usr/FreeBSD-CVS/src/lib/libalias/libalias.3,v
 retrieving revision 1.30
 diff -u -p -r1.30 libalias.3
 --- libalias.3	2000/04/28 13:44:49	1.30
 +++ libalias.3	2000/05/10 15:50:54
 @@ -784,12 +784,12 @@ arrives at the host machine, it will be 
  call to
  .Fn PacketAliasSetTarget .
  .Pp
 -If this function is not called, or is called with an
 +If this function is called with an
  .Dv INADDR_NONE
  address argument, then all new incoming packets go to the address set by
  .Fn PacketAliasSetAddress .
  .Pp
 -If this function is called with an
 +If this function is not called, or is called with an
  .Dv INADDR_ANY
  address argument, then all new incoming packets go to the address specified
  in the packet.
 
 --CE+1k2dSO48ffgeK--
 

From: Brian Somers <brian@Awfulhak.org>
To: Charles Mott <cmott@scientech.com>
Cc: Ruslan Ermilov <ru@FreeBSD.org>,
	Brian Somers <brian@Awfulhak.org>,
	goran.lowkrantz@infologigruppen.se, freebsd-gnats-submit@FreeBSD.org,
	Eivind Eklund <perhaps@yes.no>, Ari Suutari <ari@suutari.iki.fi>
Subject: Re: bin/18354: NATD diverts DMZ packets to firewall host 
Date: Wed, 10 May 2000 21:55:30 +0100

 > On Wed, 10 May 2000, Ruslan Ermilov wrote:
 > [..]
 > > The question here is what to do if PKT_ALIAS_DENY_INCOMING is NOT SET!
 > > My opinion is that it should not be altered by libalias(3) at all.
 > > As of current, it is redirected (by default) to aliasAddress.
 > 
 > I agree with your opinion.
 
 Ok, if this was the intention, I'll change the default back to 
 PacketAliasSetTarget(INADDR_ANY)
 
 [ahhem... sorry Ruslan !]
 
 Ruslan, you therefore shouldn't need to do this in the natd code as 
 the default will return to what it used to be.  How about adding my 
 -t patch so that natd's behaviour can be controlled anyway ?
 
 Cheers.
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: brian 
State-Changed-When: Thu May 11 00:55:05 PDT 2000 
State-Changed-Why:  
The libalias default (to pass packets through) has been restored 
>Unformatted:
