[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] known issues with 1.2b3
 Date:  Sun, 6 Feb 2005 17:51:26 -0800 (PST)
On Fri, 4 Feb 2005, Jesse Guardiani wrote:

> 2.) lockups on WRAP hardware
>         for some reason 1.2b3 causes lockups on WRAP
>         hardware. I didn't see any resolutions to this
>         in the archive, so I'm guessing this is an
>         ongoing problem.

I wonder if there's something in the WRAP that gets into a state that
requires more than 1ms of processing per tick, thus getting in trouble
with HZ=1000.

On Fri, 4 Feb 2005, Jesse Guardiani wrote:
> Manuel Kasper wrote:
> 
> > I can't comment about the other issues, but here's something:
> > 
> > On 04.02.2005 03:36 -0500, Jesse Guardiani wrote:
> > 
> >> 3.) TCP/IP connection drops
> >>         My SSH connections die after about 2 hours
> >>         under 1.2b3. I don't think this used to happen
> >>         under 1.11. Someone else confirmed that this
> >>         happens to them too. The connection isn't
> >>         denied. It seems like it times out.
> > 
> > That's because as of 1.2b2, the TCP idle timeout for the firewall is
> > 2.5 hours instead of the ipfilter default of 10 days (!) to keep the

Why "(!)"?  I've sometimes kept remote console sessions up for days at a
time. :-)

> > state table from filling up with dead connections. This value can be
> > modified on the advanced setup page, though it is not recommended to
> > do that. So of course if your SSH connection doesn't transfer a
> > single byte for two hours, the ipfilter state table entry is deleted
> > and the connection breaks. Try turning on keep-alive in your SSH
> > client.

Though making a major increase in the allowed number of state entries
*and* a major decrease in the timeout seems like belt-and-suspenders.

IPFilter has code to harvest old state table entries when it gets
"hungry", though perhaps this doesn't work right.  It can't do it
instantly, so at least one packet gets dropped when this happens, but one
would expect it to recover within the TCP initial SYN timeout.  If this
works as intended, there's very little reason to be stingy with the
timeout based on state-table fullness, although general RAM utilization
might be a concern.

IIRC, the problems suspected of being due to state-table exhaustion
related to floods of *incomplete* connections.  There's no reason for an
entry that hasn't reached the ESTABLISHED state to have a timeout of more
than a couple of minutes, so if those entries were lasting longer than
that, it's an IPFilter bug.

The only way to answer such questions for certain is with "ipfstat
-s" and/or "ipfstat -sl".  To insure that the WebGUI is immune to state
table issues, and to avoid "Heisenberg problems" in examining the state
via the WebGUI, it would be better for the anti-lockout rule to use
stateless filtering.  That would of course require putting it earlier than
the TCP catchall block rule.

> > BTW, some commercial firewalls come with a default timeout of 5
> > minutes!

Considering how many commercial firewalls are bought by people who don't
do much on the net besides email and web browsing, it's not hard to see
how vendors can get away with something so ridiculous. :-)

> OK. Fair enough. I just read the sshd_config man page, and while
> TCPKeepAlive is on by default, ClientAliveInterval is 0 by default,
> meaning that no keep alives will be sent. I must have missed that
> before. I thought they were already on by default. Scratch #3.

Note that there are two entirely different kinds of keepalive here.  The
TCP keepalive is done by TCP itself (when enabled by a socket option), and
doesn't send any "real content".  It appears that the default settings
have the keepalive idle interval set to two hours, with a 75-second
interval between unanswered attempts.  Whether IPFilter actually honors
TCP keepalives needs to be checked.

SSH client keepalives are application-layer NOPs that send real TCP data
(and thus are more likely to work), but are only available in SSH V2.

					Fred Wright