Thanks for your reply.
After seriously digging into the problem, it seems to me that the latest
Redhat linux kernel 2.40.20-13.9 from Redhat updates was the one to be
Somehow it managed to swap an icmp-port-unreachable with a tcp-reset and
tcp-reset with something else that I cannot determine as I am using the
most primitive way of testing connectivity: telnet.
So that explains why I changed the "reject" of common.def to "REJECT",
it suddenly works because a "REJECT" target without modifier means an
icmp-port-unreachable, which my crazy Redhat kernel interprets as a
This problem seems to be introduced into Redhat only in this kernel
update. Previous update 2.40.20-9, and the vanilla 2.40.20-8 that is
distributed through Internet doesn't seem to be affected.
If anyone is using Redhat linux kernel 2.40.20-13.9, watch out!
On Fri, 30 May 2003, Tom Eastep wrote:
> On Sat, 31 May 2003 02:03:52 +0800 (CST), <percy@...> wrote:
> > Hi all,
> > I am a newbie to shorewall and just got 1.4.3a installed on a Redhat 9
> > using iptables 1.2.7a and came across a strange problem - I suppose that
> > REJECT in shorewall is to send a TCP reset. However, somehow it behaves
> > the same way as DROP. This behavior occurs in many places, including a
> > rule in common, policy, as well as rules.
> > I am actually not too familiar with the internals of netfilter or
> > shorewall. But out of curioristy playing detective, I changed some
> > occurrances of "reject" to "REJECT" and it suddenly works as I expected.
> > For example, the AUTH rule in /etc/shorewall/common.def and the
> > "target=reject" lines in /usr/share/shorewall/firewall.
> REJECT (with no modifier) does NOT send an RST -- it returns an ICMP "port
> unreachable" packet. The 'reject' chain (which is created by Shorewall)
> returns a response based on the type of request. What does "shorewall show
> reject" return on your system?