AW: AW: tcp rst instead of DROP

[Philipp Snizek]

> > > On the same track though, I got a question about REJECT. If I
> > > didn't use the
> > > - --reject-with option, would the REJECT target automatically
> > > know what type of
> > > response to send back? Ie, if I set up a -P FORWARD
> REJECT, would it
> > > automatically reply with a RST to TCP connections and the
> > > correct icmp for
> > > udp connections etc?
> >
> > That would have been my next q.
> > I think we don't have to worry about udp. As a protocol
> that is connectionless and unreliable it
> > does not expect an answer back the way tcp does.
>
> -j REJECT without --reject-with answers with an icmp packet,
> whatever the
> rejected packet is.

Yes, true, but the question is how a not firewalled but closed udp port
would react on a request. Does it send back an icmp port unreachable via IP
or does the sending host wait until time-out error occurs? I did some
testing yesterday with win2k networkmonitor and I never saw any icmp packet
coming back from the udp packets receiving host. Thus, I say we don't have
to worry to -j DROP UDP protocol. It's the same as if the port was closed
but not firewalled. But I'm not 100% sure about whether I'm missing
something.

> --reject-with tcp-reset is only valid for tcp-packets, i.e.
> in combination
> with "-p tcp" - if you want rst for tcp-connections and icmp
> for udp/icmp,
> just use two lines, for example:



> 	-p tcp -j REJECT --reject-with tcp-reset
> 	-j REJECT

But then goal would be not sending back dest unreach host/net prohibited
which again would betray the firewall. Then there would have to be an answer
like icmp dest unreach port unreachable.

Philipp