Shorewall users - Aug 2003 - Clearing the state tables in Redhat Linux V9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gents,

I am still having a random problem with PPTP/PoPToP wherein I get a
GRE (IP 47) packet from the remote server to the external interface,
before one from the inside gets through and added to the state tables
from the inside client. This causes the firewall to reject the
packet, and kills the PPTP session.

My problem is that this rejected (Unreplied) connection then stays in
the state table (shorewall show connections) for 10 minutes or so,
preventing me from trying the connection again until it''s removed.

I try a "shorewall clear" and "shorewall reset", but this
does not
clear this connection state table. I have looked on the Redhat site
for a native command to do this, and am not having much luck.

So, other than rebooting, is there a way to clear out the state table
in Redhat Linux V9 via the CLI?


				Thanks,


				Joe



-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP0YdeS/qPRZR5h9wEQKMUwCfaMbDd9xmQ9d95uyr6M9OgdPxz7YAoNht
IF+/8nfUTJsYKf0SPqsUdwLl
=P3+Z
-----END PGP SIGNATURE-----

On Fri, 2003-08-22 at 06:41, H&K4ME wrote:
> 
> So, other than rebooting, is there a way to clear out the state table
> in Redhat Linux V9 via the CLI?
> 
The only way I know of is to remove modules until your are finally able
to remove ip_conntrack

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 22/08/2003 6:48 AM -0700, Tom Eastep wrote:
>> So, other than rebooting, is there a way to clear out the state table
>> in Redhat Linux V9 via the CLI?
>>
>
> The only way I know of is to remove modules until your are finally able
> to remove ip_conntrack
Hmm, I wonder if this is related to a problem I''m having. What happens
is I
have a machine using a service like MSN Messenger. I then decide to add 
their MAC address to /etc/shorewall/maclist (maclist is also enabled for 
the interface in /etc/shorewall/interfaces), and I restart shorewall. They 
seem to get blocked for any new connections, but not for the current 
established connections (so they can keep on chatting until they 
disconnect).

Is this because of the ip_conntrack state tables?

Gonzalo

On Fri, 2003-08-22 at 06:55, Gonzalo Servat wrote:
> 
> Is this because of the ip_conntrack state tables?
> 
I wouldn''t think so...

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Fri, 2003-08-22 at 06:48, Tom Eastep wrote:
> On Fri, 2003-08-22 at 06:41, H&K4ME wrote:
> 
> > 
> > So, other than rebooting, is there a way to clear out the state table
> > in Redhat Linux V9 via the CLI?
> > 
> 
> The only way I know of is to remove modules until your are finally able
> to remove ip_conntrack
> 
You will of course need to "shorewall clear" before you can begin
removing modules.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Fri, 2003-08-22 at 06:58, Tom Eastep wrote:
> On Fri, 2003-08-22 at 06:55, Gonzalo Servat wrote:
> 
> > 
> > Is this because of the ip_conntrack state tables?
> > 
> 
> I wouldn''t think so...
I reread your post and now understand what you were saying. I though you
were objecting to the fact that new connections were rejected when what
you were actually concerned about was the fact that existing connections
continue to work.

You are correct that this is related to connection tracking state. With
a large list of MAC addresses to filter, MAC filtering would be quite
expensive if it were done on every incoming packet. To reduce the
expense, I therefore only check MAC addresses on new connection
attempts.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 22/08/2003 7:09 AM -0700, Tom Eastep wrote:
> I reread your post and now understand what you were saying. I though you
> were objecting to the fact that new connections were rejected when what
> you were actually concerned about was the fact that existing connections
> continue to work.
That''s correct.
> You are correct that this is related to connection tracking state. With
> a large list of MAC addresses to filter, MAC filtering would be quite
> expensive if it were done on every incoming packet. To reduce the
> expense, I therefore only check MAC addresses on new connection
> attempts.
There''s only 10 odd MAC addresses. I''m not sure what you mean
by only
checking MAC addresses on new connection attempts.

Can you think of any way I can immediately cut off any access from a 
particular MAC address other than rebooting? I noticed you suggested 
removing all modules until you can get rid of the ip_conntrack module, but 
that wouldn''t work well from a script :)

Regards,
Gonzalo

On Fri, 2003-08-22 at 07:20, Gonzalo Servat wrote:
> 
> Can you think of any way I can immediately cut off any access from a 
> particular MAC address other than rebooting?
Yes. Run iptables directly to insert a rule blocking the MAC address
> I noticed you suggested 
> removing all modules until you can get rid of the ip_conntrack module, but 
> that wouldn''t work well from a script :)
> 
I don''t see why not -- you should always have the same netfilter
modules
loaded, no? And the order in which you have to remove them is
deterministic (you can determine it from the output of ''lsmod''
which
shows module dependencies).

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Fri, 2003-08-22 at 07:26, Tom Eastep wrote:
> 
> Yes. Run iptables directly to insert a rule blocking the MAC address
Or add the address to maclist, restart Shorewall then use
''cutter''
(http://www.lowth.com/cutter) to terminate the existing connections from
the associated IP address.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 22/08/2003 7:26 AM -0700, Tom Eastep wrote:
> Yes. Run iptables directly to insert a rule blocking the MAC address
That''s an idea. I guess this would be inserted in the dynamic chain,
right?
> I don''t see why not -- you should always have the same netfilter
modules
> loaded, no? And the order in which you have to remove them is
> deterministic (you can determine it from the output of
''lsmod'' which
> shows module dependencies).
I just figured if there were any rules still using the conntrack module it 
would complain and say it''s busy. If you think it should remove itself 
cleanly then ok, however, I like option 1 (above) better) :)

Thanks Tom,
Gonzalo

On Fri, 2003-08-22 at 07:33, Gonzalo Servat wrote:
> On 22/08/2003 7:26 AM -0700, Tom Eastep wrote:
> 
> > Yes. Run iptables directly to insert a rule blocking the MAC address
> 
> That''s an idea. I guess this would be inserted in the dynamic
chain, right?
Yes -- although it would get lost each time you did a restart or
refresh.
> 
> > I don''t see why not -- you should always have the same
netfilter modules
> > loaded, no? And the order in which you have to remove them is
> > deterministic (you can determine it from the output of
''lsmod'' which
> > shows module dependencies).
> 
> I just figured if there were any rules still using the conntrack module it 
> would complain and say it''s busy. If you think it should remove
itself
> cleanly then ok, however, I like option 1 (above) better) :)
You have to "shorewall clear" first as I pointed out in an earlier
post.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On 22/08/2003 7:44 AM -0700, Tom Eastep wrote:
>> That''s an idea. I guess this would be inserted in the dynamic
chain,
>> right?
>
> Yes -- although it would get lost each time you did a restart or
> refresh.
Yep, true. I just read'' your previous post about cutter. I like that 
solution even better. :)
>> I just figured if there were any rules still using the conntrack module
>> it  would complain and say it''s busy. If you think it should
remove
>> itself  cleanly then ok, however, I like option 1 (above) better) :)
>
> You have to "shorewall clear" first as I pointed out in an
earlier post.
Ah yes, to remove all the rules and free the module. Gotcha.

Thanks for your help.

Gonzalo