On 26/05/07, Tom Eastep <[EMAIL PROTECTED]> wrote: > A couple of things. > > a) You are using the RATE LIMIT column of the rules file to limit SSH. > That is *not* recommended. Rather, we prefer the 'Limit' built-in > action. The former limits the total number of connections from all > sources while the latter is per-IP. So your observation that there was > nothing in /proc/.../ipt_recent is correct; with your ruleset, there > will *never* be anything there. >
Ok. so, acting on this piece of information alone, I changed the ssh rule to read Limit:info:SSHA,3,60 net $FW tcp 22 That alone did not help the situation in that when I try and scp from the server the scp stalls. If I stop the scp (Ctrl-C) and then repeat the command, no connection is allowed and shorewall on the server logs that it is dropping the packets from my local machine: May 26 21:41:20 withnail kernel: Shorewall:SSHA:DROP:IN=eth0 OUT= MAC=00:19:b9:00:c2:49:00:d0:79:95:98:00:08:00 SRC=90.193.1 82.62 DST=128.40.2.35 LEN=72 TOS=0x00 PREC=0x00 TTL=51 ID=17706 DF PROTO=TCP SPT=34948 DPT=22 WINDOW=3555 RES=0x00 ACK FIN U RGP=0 Of course, these two commands, which should equate to only two connections, should not be triggering the limit of (3,60) to be kicking in. This behaviour is reproducible. > b) You are getting a lot of INVALID state packets. You might try adding > this to your /etc/shorewall/init file: > > echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal > Next I did this (in combination with the change above), and everything works just as it should. I tried one other thing - I reverted this last change (echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal) and turned off tcp window scaling on the server (i.e. echo 0 > /proc/sys/net/ipv4/tcp_window_scaling). That also made everything work as it should, with no stalling. So, Tom, it seems you're correct in your analysis. [Aside: Just for kicks, I reverted to the original rate limited ssh rule, and that too works as expected if I do echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal.] So if I understand you (Tom) correctly, this is an issue with the network the server is on, or the firewall it is behind that is causing problems with certain server firewall configurations? [Just in case that's a confusing sentence, here we have been debugging a shorewall generated firewall, but the machine that firewall is on is behind a LAN firewall allowing ssh connections through to the server in question] I realize at this point it is probably clear that this is no bug with shorewall, but I wonder if you might have any suggestion about how I would go about finding what is causing all of those INVALID packets. Thanks to Tom, Andrew, Brian, Roberto and Simon for your suggestions, it really has been much appreciated. jonathan. > -Tom > -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ [EMAIL PROTECTED] > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Shorewall-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
