Bug 18354
| Summary: | NATD diverts DMZ packets to firewall host | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | goran.lowkrantz <goran.lowkrantz> | ||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.0-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
> >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 ! > 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
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 !
>
>
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 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 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 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.
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 > 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 The libalias default (to pass packets through) has been restored |
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 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 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.