General Questions

Hello,

I am using m0n0wall 1.3b2 as a router for a test LAN segment.
Mostly I use it for the traffic shaper to imitate WAN link speeds.
The test segment is on the LAN side, and the main network is on
the WAN side.  Firewall rules are set to allow all traffic in both
directions, and the "Enable advanced outbound NAT" option is checked
without having any NAT rules defined to allow all traffic.
I also tested with the traffic shaper disabled to make sure
that was not the cause.

I am trying to send remote commands via "rsh" from Unix servers
(or "rcmd" from SCO/FreeBSD) on the main network to a terminal
on the test LAN.  For each server, I can send only one remote command request, and then any further requests will freeze for several minutes. 
This problem is occuring with servers running AIX, SCO, and Linux.

For example, server A on WAN can send a remote command to one
terminal on the LAN, and further remote commands from server A
to that terminal will lock.  In that time server B on the WAN can send
one remote request to the same LAN terminal with no problem, but
further remote commands from server B will then also lock.

I would not think this would be an issue with m0n0wall, except
that the remote commands work without this problem when using
two Cisco 2501 routers connected back to back.

I just checked the m0n0wall logs, and the Firewall log shows that
it denied the packets on the WAN interface from the server outgoing
port 1023 to the LAN terminal port 514.  It continues this behavior even
if I add a rule specifically allowing that server/port to connect to the client
address/port.  After a time delay it does allow one connection through
and then starts blocking again.

Thanks.
---Hillel

Sounds like a bug in the rsh implementation you're using, or maybe a bug in rsh in general, or maybe a bug in ipfilter's state code. I'm not really familiar with rsh, hell I didn't think anybody used it since the 1990's since it's such a security disaster.

What's happening is related to the state table, which is why you don't see it with a router. Exactly why it's doing it is impossible to say, need more details like complete raw ipfilter logs of the blocked traffic from status.php to be able to tell.

Here are some of the ipfilter log entries for the blocked connections:

Apr 24 08:28:39 retix ipmon[98]: 08:28:39.378409 xl0 @0:13 b 172.16.2.3,1023 -> 172.16.150.212,514 PR tcp len 20 44 -S IN OOW
Apr 24 08:28:40 retix ipmon[98]: 08:28:39.954670 xl0 @0:13 b 172.16.2.3,1023 -> 172.16.150.212,514 PR tcp len 20 44 -S IN OOW
Apr 24 08:28:43 retix ipmon[98]: 08:28:42.955695 xl0 @0:13 b 172.16.2.3,1023 -> 172.16.150.212,514 PR tcp len 20 44 -S IN OOW
Apr 24 08:28:49 retix ipmon[98]: 08:28:48.957870 xl0 @0:13 b 172.16.2.3,1023 -> 172.16.150.212,514 PR tcp len 20 44 -S IN OOW
Apr 24 08:29:01 retix ipmon[98]: 08:29:00.961921 xl0 @0:13 b 172.16.2.3,1023 -> 172.16.150.212,514 PR tcp len 20 44 -S IN OOW


It looks like the infamous "out of window" problem for the automatic rules with "keep state" entries.  The unparsed ipfilter rules show:

# User-defined rules follow
pass in quick from any to any keep state keep frags group 200
pass in quick from any to any keep state group 100

What can be done to fix this?

Thanks.
---Hillel