I have a "new not syn" packet needed
Wed, 9 Jan 2002 16:13:58 -0200
Ok Patrick(and everybody), but just respond something to me:
If the rule that it causing the FIN packets to be blocked is:
iptables -A FORWARD -p tcp ! --syn -m state --state NEW -j LOG
Are the FIN packet with the state NEW? Shouldn't it be "ESTABLISHED" or
I think that if the FIN packet would finish an existing connection it
couldn't have a NEW state.
> Hi Bruno,
> > I'm still having this problem which is my firewall blocking the FIN
> > sent either from my firewall to the outside world(OUTPUT chain) or in
> > FORWARD chain, from my internal machines to the Internet.
> > Which is the tcpdump command syntax which would better show what is
> > with my connections?
> Pick any internal machine you control. Make sure it does not do anything
> else at that time. Then, on the internal machine, do the thing which
> makes your firewall complain about the FIN stuff (i.e. verify that
> you can reproduce the phenomenon at will). Whatever you do, it will
> be directed to some outside IP address X. I further assume that your
> internal machine is not masqueraded or otherwise NATted, but has
> the official IP address Y. Finally, I assume the internal interface
> of your firewall is eth1, and the external interface is eth0. Now, run
> these two commands on the firewall box, in parallel:
> tcpdump -w /tmp/extern.dmp -i eth0 host X and host Y
> tcpdump -w /tmp/intern.dmp -i eth1 host X and host Y
> Now, at the internal machine, reproduce the problem again. See that you
> again have the FIN related log messages. Wait 20 more seconds, then abort
> the tcpdump commands.
> With "tcpdump -r /tmp/extern.dmp", you can now see the interpreted
> trace on the external interface. You could also use ethereal to read
> that trace file, and send it to the list.
> It will be best if you send your gathered results directly to the
> mailing list - the developers are more frequently reading there.
> best regards