[ previous ] [ next ] [ threads ]
 From:  Chris Buechler <cbuechler at gmail dot com>
 To:  Ernie Zingleman <ks4q at zingleman dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Firewall Problem with Telnet
 Date:  Tue, 21 Dec 2004 19:05:52 -0500
On Tue, 21 Dec 2004 18:07:21 -0500, Ernie Zingleman <ks4q at zingleman dot com> wrote:
> As far as the incoming port numbers, I thought it was weird in the setup of
> m0n0wall in that I could not select "Any" for incoming ports.  

Assuming you're talking about the NAT rule, the incoming port number
is the incoming destination port.  The firewall rule, if auto-added,
will permit any source port.

> It made me
> select 'telnet' although perhaps any is what ends up in the actual rules.  

Telnet for dst port, any for src port is what it'll add.  

You didn't say if you were having any problems, but if not just ignore
it.  The @0:17 means rule 17 in group 0 as shown in /status.php is
what's dropping the traffic.  Knowing which rule that is might help us
a little more.  My guess is it's retransmitted and/or last packets not
hitting the state of the connection in process, as described in the
ipfilter howto:

"Due to the often laggy nature of the Internet, sometimes packets will
be regenerated. Sometimes, you'll get two copies of the same packet,
and your state rule which keeps track of sequence numbers will have
already seen this packet, so it will assume that the packet is part of
a different connection. Eventually this packet will run into a real
rule and have to be dealt with. You'll often see the last packet of a
session being closed get logged because the keep state code has
already torn down the connection before the last packet has had a
chance to make it to your firewall. This is normal, do not be