Site-specific filter rules problem

Site-specific filter rules problem

[Mark Baker]

Hello, All -

I'm just getting started with netfilter, although I understand packet
filtering and have configured other firewalls. This is a very simple
desktop machine firewall that works fine in general, but is giving me
problems with one site in particular that's very important.

My rule set is extremely simple at present:

:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [6:358]
:U804-input - [0:0]
-A INPUT -j U804-input 
-A U804-input -i lo -j ACCEPT 
-A U804-input -p icmp -j ACCEPT 
-A U804-input -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A U804-input -p tcp -m tcp --dport 22 -j ACCEPT 
-A U804-input -j DROP

The one site that gives me problems is an online classroom environment
running Angel LMS.  With the above rules installed changing pages often
takes 15-20 minutes, but will usually work eventually. If I flush the
chains, the site responds normally.

I have packet captures from connections to this site, with and without
firewall rules installed.  I don't see anything that should be blocked
based on these rules - the only thing odd is that when the problem
occurs I get a ton of retransmissions from the server.  Another oddity
in both cases is that virtually every packet coming from the server is
fragmented; but from what I've read, connection tracking (which is
running on this machine) should completely reassemble fragmented packets
before delivery to the filter table.  Still, could fragmentation be the
problem?

What little I know about the server end is that it is running the Angel
Learning Management System (LMS) on IIS.  I don't yet know the path MTU,
but my local machine and router are both set to 1500, which is what I
would normally use for a high-speed connection.

Any ideas appreciated.

Thanks,
Mark Baker

Re: Site-specific filter rules problem

[Grant Taylor]

On 05/25/08 02:55, Mark Baker wrote:
> I have packet captures from connections to this site, with and 
> without firewall rules installed.  I don't see anything that should 
> be blocked based on these rules - the only thing odd is that when the 
> problem occurs I get a ton of retransmissions from the server. 
> Another oddity in both cases is that virtually every packet coming 
> from the server is fragmented; but from what I've read, connection 
> tracking (which is running on this machine) should completely 
> reassemble fragmented packets before delivery to the filter table. 
> Still, could fragmentation be the problem?

Based on the retransmissions, it sounds like something is expecting to 
get something through and have it acknowledged that is not.

I'd look at what is being re-transmitted and see if it needs to get 
through and / or if there is an unacknowledged reply that is being blocked.



Grant. . . .

Re: Site-specific filter rules problem

[Mark Baker]

On Tue, 2008-05-27 at 09:29 -0500, Grant Taylor wrote:
> On 05/25/08 02:55, Mark Baker wrote:
> > I have packet captures from connections to this site, with and 
> > without firewall rules installed.  I don't see anything that should 
> > be blocked based on these rules - the only thing odd is that when the 
> > problem occurs I get a ton of retransmissions from the server. 
> > Another oddity in both cases is that virtually every packet coming 
> > from the server is fragmented; but from what I've read, connection 
> > tracking (which is running on this machine) should completely 
> > reassemble fragmented packets before delivery to the filter table. 
> > Still, could fragmentation be the problem?
> 
> Based on the retransmissions, it sounds like something is expecting to 
> get something through and have it acknowledged that is not.
> 
> I'd look at what is being re-transmitted and see if it needs to get 
> through and / or if there is an unacknowledged reply that is being blocked.
> 
> 
> 
> Grant. . . .
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks for the advice, Grant.  Keeping in mind that I'm only having this
problem with one site and therefore it must be doing something
differently, I did a little more playing and found out I could eliminate
the problem by adding the following rule after my state rule, like this:

$IPT -t filter -A U804-input -m state --state RELATED,ESTABLISHED -j
ACCEPT

$IPT -t filter -A U804-input -s $ANGELIP -p tcp -m tcp --sport 80
--dport 1024:65535 ! --syn -j LOG

$IPT -t filter -A U804-input -s $ANGELIP -p tcp -m tcp --sport 80
--dport 1024:65535 ! --syn -j ACCEPT

After adding the next 2nd and 3rd rules above, I found that huge numbers
of packets were getting past my state rule, but it cured the problem.
When I compare the logged packets to /proc/net/nf_conntrack, though, I
find that the sockets identified in the missed packets matched
established connections listed in nf_conntrack, so I'm still not sure
why they were being missed. 

I played around with it a bit more, and found that if I set
nf_conntrack_tcp_be_liberal=1, virtually everything is accepted by my
state rule (although by the end of the session with the problem site, 3
out of about 3500 packets had still gotten through somehow).  The only
problem is, I don't fully understand the ramifications of that setting.
I spent a lot of time searching, but have found little information on
the nf_conntrack settings in /proc/sys/net/netfilter.

Can anyone help me understand exactly what nf_conntrack_tcp_be_liberal
does?  Also, what about nf_conntrack_tcp_loose?  If anyone can tell me
where to find documentation on the nf_conntrack parameters, that would
be even better.

Thanks,
Mark

Re: Site-specific filter rules problem

[Grant Taylor]

On 05/29/08 00:02, Mark Baker wrote:
> Thanks for the advice, Grant.  Keeping in mind that I'm only having 
> this problem with one site and therefore it must be doing something 
> differently, I did a little more playing and found out I could 
> eliminate the problem by adding the following rule after my state 
> rule, like this:

You are welcome.  I'm glad that you got things working.

<snip>

> After adding the next 2nd and 3rd rules above, I found that huge 
> numbers of packets were getting past my state rule, but it cured the 
> problem. When I compare the logged packets to /proc/net/nf_conntrack, 
> though, I find that the sockets identified in the missed packets 
> matched established connections listed in nf_conntrack, so I'm still 
> not sure why they were being missed.

It might be worth submitting a new post to the mailing list (new thread 
rather than a reply to this one) clearly stating what you were seeing in 
your conntrack tables.  Also, include as many relevant logs and 
conntrack entries as possible.  You may want to consider sniffing some 
traffic and including that as well.



Grant. . . .