Shorewall devel - Aug 2003 - Restart and lost connections

Perhaps some of you out there in shorewall land can inspire some light 
on this.  I''m a tad stumped.  (I''m just praying its not a
"hey stupid"
due to the fact I''ve been reading and re-reading the RTFM for the last
3
days.)

I have a two interface system.  Running shorewall 1.4.6b.  Redhat 9.0 
latest patches.

Eth0 goes out to the DSL and Eth1 is internal.  My 
shorewall/routestopped file says

#INTERFACE      HOST(S)
eth1            -

On a machine that''s run off of eth1 I have the following connections:

ssh to external host
IRC connection to irc.freenode.org
ICQ connection

When I do a "shorewall restart" I loose those three connections and
they
get reset.  Its my understanding that routestopped entries should keep 
any connection that''s there open.  Any thoughts on what I''m
doing wrong?

Thanks
ian

On Mon, 18 Aug 2003, ian wrote:
>
> When I do a "shorewall restart" I loose those three connections
and they
> get reset.  Its my understanding that routestopped entries should keep
> any connection that''s there open.  Any thoughts on what
I''m doing wrong?
>
"routestopped" has nothing to do with the behavior of "shorewall
restart"
and you should never loose connections doing a simple restart.

"routestopped" only takes effect after "shorewall stop" and
requires that
all hosts involved in connections be listed in "routestopped" in order
for
the connection to continue working.

Are you using any of the extension scripts and if so, what commands do you
have in them?

-Tom

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

Nope.. No restart scripts.  My current scripts are just straight up 
modified scripts of masq, rules, interfaces, maclist etc.

ian


Tom Eastep wrote:
> On Mon, 18 Aug 2003, ian wrote:
> 
> 
>>When I do a "shorewall restart" I loose those three
connections and they
>>get reset.  Its my understanding that routestopped entries should keep
>>any connection that''s there open.  Any thoughts on what
I''m doing wrong?
>>
> 
> 
> "routestopped" has nothing to do with the behavior of
"shorewall restart"
> and you should never loose connections doing a simple restart.
> 
> "routestopped" only takes effect after "shorewall stop"
and requires that
> all hosts involved in connections be listed in "routestopped" in
order for
> the connection to continue working.
> 
> Are you using any of the extension scripts and if so, what commands do you
> have in them?
> 
> -Tom
> 
> Tom Eastep    \ Shorewall - iptables made easy
> Shoreline,     \ http://shorewall.net
> Washington USA  \ teastep@shorewall.net
> _______________________________________________
> Shorewall-users mailing list
> Post: Shorewall-users@lists.shorewall.net
> Subscribe/Unsubscribe:
http://lists.shorewall.net/mailman/listinfo/shorewall-users
> Support: http://www.shorewall.net/support.htm
> FAQ: http://www.shorewall.net/FAQ.htm

On Tue, 2003-08-19 at 05:30, ian wrote:
> Here are my scripts.
> 
I haven''t a clue -- Shorewall enables existing connections while it is
restarting. While there might be timeouts during the period from when
Shorewall begins the restart process until it has enabled existing
connections, there should never be rejects (which would cause resets)
and the timeouts would only be noticeable if you had a very slow
firewall box.

Since I do most of my testing on my own firewall, I do LOTS of
"shorewall restart"s and I don''t recall ever having lost a
connection on
a successful restart.

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

On Tue, 2003-08-19 at 06:52, Tom Eastep wrote:
> On Tue, 2003-08-19 at 05:30, ian wrote:
> > Here are my scripts.
> > 
> 
> I haven''t a clue -- Shorewall enables existing connections while
it is
> restarting. While there might be timeouts during the period from when
> Shorewall begins the restart process until it has enabled existing
> connections, there should never be rejects (which would cause resets)
> and the timeouts would only be noticeable if you had a very slow
> firewall box.
> 
> Since I do most of my testing on my own firewall, I do LOTS of
> "shorewall restart"s and I don''t recall ever having lost
a connection on
> a successful restart.
> 
As a stab in the dark, please try disabling MAC verification on eth1 and
see if you still have the problem.
 
-Tom

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

Hello all

This post will seem like it comes from way out in left field (in truth,
it does), but bear with me...there is a point to it  :)

Also, before you tell me to post it to the netfilter lists, give it a
read and plz gimme your thoughts on it so I can better understand the
(as yet unseen by me) gotchas of what I''m proposing.

Another way of keeping open connections is using iptables-restore to set
the iptables rules.  From my understanding, this is about as atomic a
rules change as can be done (short of using the iptables command
directly, which is not the point if we''re using shorewall).

So the question then becomes: how to generate a valid iptables-save dump
WITHOUT actually going to the kernel to alter the currently-running
rules manually?  In shorewall''s case, how to alter the
currently-running
ruleset without having to wipe it clean and rebuilding it from scratch?

In short: how can we alter a set of rules, and have them be updated into
the running kernel as atomically as possible (i.e., replace the running
kernel''s iptables ruleset by a new one as atomically as possible)?

My answer to this is simple, but as yet non-existant and the point of my
post :) :

Someone (me, you, anyone?) would write an "iptables-sim" daemon that
listens on a named pipe, socket, whatever and we could give it the
commands and format that we would issue normally as iptables, and at the
end we could do an iptables-sim --dump (or something) and get the
iptables-save-equivalent output (packet counters set to zero of course),
and thus apply that onto the kernel via iptables-restore.

Of course - who will write such a thing?   :)

I''m willing to take a crack at it, but I''d need some input
from more
netfilter-experienced guys out there to hint me as to where the
code-parsers are, and how to mimic the in-kernel data that I won''t have
available in userspace.

My view of how this could work is as follows:

$ mkfifo /tmp/iptables-in
$ iptables-sim < /tmp/iptables-in > /tmp/iptables-rules &

$ cat <<EOF >/tmp/iptables-in
-t filter -A INPUT -m tcp --dport 80 --dst $B -j ACCEPT
-t nat -A DNAT --dst $B --to-destination $C
...
...
EOF
$ iptables-restore < /tmp/iptables-rules

Thus, all shorewall would need to do is generate the command-line
arguments for the rules (as if they would be sent to iptables), and
"echo" each one in order to the input pipe.  At the end of shorewall,
when the rules have been applied and the new table set is ready, we
execute the equivalent of the last command to apply the rules to the
running kernel.

If we really want icing to the cake, then a better way could be:

$ iptables-sim-daemon &
$ iptables-sim -t filter -A INPUT ....
$ iptables-sim -t nat -A DNAT ....
...
...
$ iptables-sim --dump | iptables-restore

And we could use the same input-validation code from the iptables
command to report errors, etc, and keep the overall workings of
shorewall intact.

What do you guys think?  Has this already been tried?  Do you see this
as feasible?

I''m sure it would be a pretty bit of work - just implementing the
in-memory tables could be a PITA, but given the fact that linux is more
and more being used for firewalling, this would add much-needed
robustness and simplicity to iptables management, as a user can now play
with tables and only apply those changes when he/she thinks they''re
good
to go.

Opinions? Praises? Flames? All are welcome  :)

Best

-- 
==========================================================* Diego Rivera        
*
*                                                         *
* "The Disease: Windows, the cure: Linux"                 *
*                                                         *
* E-mail: lrivera<AT>racsa<DOT>co<DOT>cr                  *
* Replace: <AT>=''@'', <DOT>=''.''  
*
*                                                         *
* GPG: BE59 5469 C696 C80D FF5C  5926 0B36 F8FF DA98 62AD *
* GPG Public Key avaliable at: http://pgp.mit.edu         *
==========================================================-------------- next
part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030819/959fbad2/attachment.bin

On Tue, 2003-08-19 at 12:28, Diego Rivera wrote:
> Hello all
> 
> This post will seem like it comes from way out in left field (in truth,
> it does), but bear with me...there is a point to it  :)
Especially since you hijacked another thread to post something on the
Users list that would have been more appropriate on the Development
list. I''ve copied my reply to that list where I would appreciate any
further discussion taking place.
> 
> So the question then becomes: how to generate a valid iptables-save dump
> WITHOUT actually going to the kernel to alter the currently-running
> rules manually?  In shorewall''s case, how to alter the
currently-running
> ruleset without having to wipe it clean and rebuilding it from scratch?
> 
> In short: how can we alter a set of rules, and have them be updated into
> the running kernel as atomically as possible (i.e., replace the running
> kernel''s iptables ruleset by a new one as atomically as possible)?
> 
> My answer to this is simple, but as yet non-existant and the point of my
> post :) :
> 
> Someone (me, you, anyone?) would write an "iptables-sim" daemon
that
> listens on a named pipe, socket, whatever and we could give it the
> commands and format that we would issue normally as iptables, and at the
> end we could do an iptables-sim --dump (or something) and get the
> iptables-save-equivalent output (packet counters set to zero of course),
> and thus apply that onto the kernel via iptables-restore.
Which wipes the current ruleset clean and rebuilds it from scratch
AFAIK.
> 
> Of course - who will write such a thing?   :)
> 
> I''m willing to take a crack at it, but I''d need some
input from more
> netfilter-experienced guys out there to hint me as to where the
> code-parsers are, and how to mimic the in-kernel data that I won''t
have
> available in userspace.
> 
> My view of how this could work is as follows:
> 
> $ mkfifo /tmp/iptables-in
> $ iptables-sim < /tmp/iptables-in > /tmp/iptables-rules &
> 
> $ cat <<EOF >/tmp/iptables-in
> -t filter -A INPUT -m tcp --dport 80 --dst $B -j ACCEPT
> -t nat -A DNAT --dst $B --to-destination $C
> ...
> ...
> EOF
> $ iptables-restore < /tmp/iptables-rules
> 
> Thus, all shorewall would need to do is generate the command-line
> arguments for the rules (as if they would be sent to iptables), and
> "echo" each one in order to the input pipe.
And the "arp", "ip" and "echo" commands that
Shorewall generates would
just go on the floor? 

Another problem is that Shorewall uses utility programs to interrogate
the current environment in order to determine what commands to execute. 

And Shorewall saves state in /var/lib/shorewall for use during
"shorewall refresh" and "shorewall restart".
>  At the end of shorewall,
> when the rules have been applied and the new table set is ready, we
> execute the equivalent of the last command to apply the rules to the
> running kernel.
We still have to take care of all of the Shorewall-generated commands
other than ''iptables'' and understand how to save the state for
"refresh"
and "restart".
> 
> If we really want icing to the cake, then a better way could be:
> 
> $ iptables-sim-daemon &
> $ iptables-sim -t filter -A INPUT ....
> $ iptables-sim -t nat -A DNAT ....
> ...
> ...
> $ iptables-sim --dump | iptables-restore
> 
Or simply have Shorewall generate the iptables-save formatted file to
start with. While this wouldn''t give you as warm and fuzzy a feeling as
running the rules through a simulator, the following should be pretty
fast:

   <$f holds the name of the save file>

	iptables-save > /tmp/shorewall-save-$$

	if iptables-restore < $f ; then
		<execute the ''ip'', ''tc'', etc commands
and
		 save state>
	else
		iptables-restore < /tmp/shorewall-save-$$
	fi	

The main problem that I see with the iptables-sim idea is that it would
be an absolute PITA to maintain. I can hear the whining and moaning from
the Patch-O-Matic crowd already because their favorite P-O-M patch du
jour isn''t in iptables-sim. And no matter how careful you are building
iptables-sim, someone will always be finding cases where it doesn''t
behave like the real thing.

For Shorewall, the order in which things are done would have to be
radically altered since none of the "non-iptables" configuration could
be done until after the iptables-restore had completed. And state
couldn''t be saved until then either.

And I have absolutely no idea how to do the chain-specific extension
scripts that Shorewall supports today; I suspect that it is not
possible.

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

On Tue, 2003-08-19 at 13:55, Tom Eastep wrote:
> 
> And I have absolutely no idea how to do the chain-specific extension
> scripts that Shorewall supports today; I suspect that it is not
> possible.
> 
I''ve thought about these some more and believe that they can be done
but
there will be restrictions on what the user can do in the scripts
(because they would run when the save file was created and not when the
actual [re]start was done.

Another problem with the iptables-sim idea is that it would probably not
fly with the Bering crowd since it would be another (presumably large)
package that would have to be loaded to run Shorewall. And no -- I
wouldn''t consider allowing Shorewall to run in either
"iptables-sim"
mode or its current mode. It''s hard enough to get it right with only
one
mode to worry about.

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

On Tue, 2003-08-19 at 15:31, Diego Rivera wrote:
> 
> Yes, but is less expensive time-wise than running iptables multiple
> times.
> 
> In my case this is important, as VRRP is being used - in my setup, and
> failure detection is time-sensitive.  Therefore, "shorewall
restart"
> inevitably triggered a node failover while iptables-restore didn''t
> because shorewall restart took 10 seconds to execute (lotta rules) while
> iptables-restore took under 1 second.
> 
> It''s my understanding that iptables-restore builds the tables in
memory
> (from ppl''s comments and looking at the code), then issues an
> "iptc_commit()" call which causes the table to be
"flashed" onto the
> running kernel - thus affecting the changes to that particular table
> "atomically" (if the term even applies).
> 
> Generating the tables is not the "problem" - the
"problem" is the time
> it takes for the tables to be complete and become active. 
> iptables-restore just takes much less time to complete even for very
> large tables.
Nod.
> 
> > And the "arp", "ip" and "echo" commands
that Shorewall generates would
> > just go on the floor? 
> 
> Not really - my view was more like shorewall would echo all the iptables
> commands to be run into a file, and at the very end (after all is said
> and done) issue the commands to the "simulator" and apply the
resulting
> file, but you hit the nail on the head with this next one.
> 
> Perhaps queue them to a temp file as they''re generated and run
them just
> after the new table setup is "flashed" in?  (more on that
additional
> lunacy below)
I think that by radically re-ordering how things are done in Shorewall,
these can be left until last. 
> 
> > 
> > Another problem is that Shorewall uses utility programs to interrogate
> > the current environment in order to determine what commands to
execute.
> > 
> > And Shorewall saves state in /var/lib/shorewall for use during
> > "shorewall refresh" and "shorewall restart".
> 
> I was not aware of this state that was saved.  I''ll have to look
at this
> and factor it in.
> 
> > We still have to take care of all of the Shorewall-generated commands
> > other than ''iptables'' and understand how to save the
state for "refresh"
> > and "restart".
Yes -- again I think that these must all be moved to after the iptables
rules have been instantiated.
> 
> Judging from your next portion, I assume that these commands are NOT
> dependent of the state of the netfilter tables - except maybe the exit
> status from the iptables command itself?  Please correct me if I''m
wrong
> in thinking that.
The state that would be interrogated in my implementation would be a lot
more current than might be the case in yours. With yours, the
iptables-save file could have been created two weeks ago; with mine, it
would be within the last minute or so. Big difference.
> 
> > Or simply have Shorewall generate the iptables-save formatted file to
> > start with. While this wouldn''t give you as warm and fuzzy a
feeling as
> > running the rules through a simulator, the following should be pretty
> > fast:
> > 
> >    <$f holds the name of the save file>
> > 
> > 	iptables-save > /tmp/shorewall-save-$$
> > 
> > 	if iptables-restore < $f ; then
> > 		<execute the ''ip'', ''tc'', etc
commands and
> > 		 save state>
> > 	else
> > 		iptables-restore < /tmp/shorewall-save-$$
> > 	fi	
> 
> You''re right - this is a much simpler approach.  The way
I''ve looked at
> the iptables-save command is that each rule (except chain definitions
> and some other "special" lines) is dumped as a valid iptables
command -
> thus shorewall could easily generate it out of the box.
> 
> There''s two particularities though:
> 
> - Table boundaries are marked with ''^*table$'' and
''^COMMIT$''
> 
> - Chains are first listed (sorted alphabetically), then dumped (in same
> order as they were listed), and the file doesn''t work unless this
is so.
> 
> The rules themselves are dumped as expected - in the order they are
> listed within each chain.  I''m not sure if shorewall does specific
> ordering (i.e., insert before or after), so gimme a hint here plz.  I
> think it just does some deletes at the end, but not sure if this is all
> the out-of-order rules manipulation that is done.
Most of the out-of-order rules manipulation occurs during "shorewall
add".
> 
> > The main problem that I see with the iptables-sim idea is that it
would
> > be an absolute PITA to maintain. I can hear the whining and moaning
from
> > the Patch-O-Matic crowd already because their favorite P-O-M patch du
> > jour isn''t in iptables-sim. And no matter how careful you are
building
> > iptables-sim, someone will always be finding cases where it
doesn''t
> > behave like the real thing.
> 
> I agree, which is why I''m only thinking in terms of something
small,
> simple and easy to maintain that would:
> 
> a) perform basic validation of iptables command lines as valid/invalid
> (regardless of the current state of the kernel tables).
> 
> b) Allow the generation of an iptables-save dump so that
> iptables-restore can be used.
> 
> c) Mimick the *expected* behavior of iptables assuming everything is
> fine and dandy (the iptables-restore command will happily fail
> completely if an error is found, and we could fall back to the previous
> configuration via the mechanism you describe above).
> 
> And there''s always the standard open-source "stuff-it"
response: it''s
> free and you have the source, add the patch or fix the behavior that
> annoys you :)
That horse can only be ridden so far though...
> 
> > For Shorewall, the order in which things are done would have to be
> > radically altered since none of the "non-iptables"
configuration could
> > be done until after the iptables-restore had completed. And state
> > couldn''t be saved until then either.
> 
> As for the non-iptables stuff, yes - but as I said (and you concurred by
> your reply) there''s the possibility of queueing (i.e. echo
$command >>
> tmpfile) them to be executed at that time.
> 
> As for the state, I don''t know much about it yet so I''ll
have to do some
> more reading to get to know it better and have a clearer view of the
> lunacy I propose :).  Perhaps temping the state and then (at the end)
> replacing the existing state with the newly-created (temp''d) one?
I would have to do an inventory of what''s there as well. Those parts of
Shorewall that haven changed in a year or so are rather fuzzy to me :-)
> 
> I think you see some value in doing this, so let''s see if it
really is
> feasible, and how much work it would entail.  As I said, I''m more
than
> willing to take it on.
I''ll throw out another idea.

a) Enhance "shorewall save" to invoke "iptables-save".
b) Reorder how Shorewall starts as we''ve been talking about so that it
can take advantage of a iptables-save file if one exists. 
c) Implement a "shorewall [re]start !" option which ignores the
iptables-save file.

I think this is a lot easier than either of the other proposals. It
still requires that those commands that are dependent on the current
state to be handled somehow. But that''s only one problem whereas the
other proposals have more difficult ones I think.
> 
> And last but by all means most: Thanks for the quick replies Tom!
You''re welcome.

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

On Tue, 19 Aug 2003, Diego Rivera wrote:
> On Tue, 2003-08-19 at 17:04, Tom Eastep wrote:
> > On Tue, 2003-08-19 at 15:31, Diego Rivera wrote:
> > I think that by radically re-ordering how things are done in
Shorewall,
> > these can be left until last.
>
> I''ll have to look at the whole of the shorewall start and where
these
> commands are called to see if this reordering is truly necessary - but
> for now I''ll take your word for it and assume that it is.
>
If you execute them in line then can''t instantiate the iptables-save
file,
what do you do?
> > The state that would be interrogated in my implementation would be a
lot
> > more current than might be the case in yours. With yours, the
> > iptables-save file could have been created two weeks ago; with mine,
it
> > would be within the last minute or so. Big difference.
>
> Actually, what I propose is generating the iptables-save file every time
> (and possibly saving a backup beforehand just to be safe in case an
> error comes along), so there wouldn''t be an issue with stale state
since
> the state would be as current as the lastly applied dump file.
>
> Does that make sense?
>
Ok -- that''s roughly equivalent to my last proposal.
> >
> > Most of the out-of-order rules manipulation occurs during
"shorewall
> > add".
>
> And I assume this portion draws heavily from the saved state to know
> where things need to be added.
Yes.
> Quite right!
>
> > I would have to do an inventory of what''s there as well.
Those parts of
> > Shorewall that haven changed in a year or so are rather fuzzy to me
:-)
> >
>
> I''ll get going on this send it to you so you can compare notes and
> correct me where I''m wrong.
>
Seems fair.
> > I''ll throw out another idea.
> >
> > a) Enhance "shorewall save" to invoke
"iptables-save".
> > b) Reorder how Shorewall starts as we''ve been talking about
so that it
> > can take advantage of a iptables-save file if one exists.
> > c) Implement a "shorewall [re]start !" option which ignores
the
> > iptables-save file.
> >
> > I think this is a lot easier than either of the other proposals. It
> > still requires that those commands that are dependent on the current
> > state to be handled somehow. But that''s only one problem
whereas the
> > other proposals have more difficult ones I think.
>
> That makes sense - I''ll certainly keep this in mind as one of the
main
> options.  This for sure seems less work than any of the others, and is
> certainly less impacting to shorewall.
>
I agree.

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

Tom Eastep wrote:
> On Tue, 2003-08-19 at 06:52, Tom Eastep wrote:
> 
>>On Tue, 2003-08-19 at 05:30, ian wrote:
>>
>>>Here are my scripts.
>>>
>>
>>I haven''t a clue -- Shorewall enables existing connections
while it is
>>restarting. While there might be timeouts during the period from when
>>Shorewall begins the restart process until it has enabled existing
>>connections, there should never be rejects (which would cause resets)
>>and the timeouts would only be noticeable if you had a very slow
>>firewall box.
>>
>>Since I do most of my testing on my own firewall, I do LOTS of
>>"shorewall restart"s and I don''t recall ever having
lost a connection on
>>a successful restart.
>>
> 
> 
> As a stab in the dark, please try disabling MAC verification on eth1 and
> see if you still have the problem.
Tried that.. Didn''t make any change.

I just noticed I''m getting a ton of messages in the log after said 
restart that say Shorewall:newnotsyn:DROP.  So I turned newnotsyn off 
and now I can restart with abandon and I don''t loose my connections.

Hmm.. I wonder if ip_conntrack is getting reset after a shorewall 
restart and that would make the system forget about known connections.

Thoughts?

ian

p.s. Thanks for the time tom & other folks out there.  It helped me get 
it figured out.

On Wed, 2003-08-20 at 08:36, ian wrote:
> > 
> > As a stab in the dark, please try disabling MAC verification on eth1
and
> > see if you still have the problem.
> 
> Tried that.. Didn''t make any change.
> 
> I just noticed I''m getting a ton of messages in the log after said
> restart that say Shorewall:newnotsyn:DROP.  So I turned newnotsyn off 
> and now I can restart with abandon and I don''t loose my
connections.
> 
> Hmm.. I wonder if ip_conntrack is getting reset after a shorewall 
> restart and that would make the system forget about known connections.
> 
> Thoughts?
> 
There''s no way to reset ip_conntrack short of removing the module.

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

On Wed, 2003-08-20 at 09:01, Tom Eastep wrote:
> > I just noticed I''m getting a ton of messages in the log after
said
> > restart that say Shorewall:newnotsyn:DROP.  So I turned newnotsyn off 
> > and now I can restart with abandon and I don''t loose my
connections.
> > 
> > Hmm.. I wonder if ip_conntrack is getting reset after a shorewall 
> > restart and that would make the system forget about known connections.
> > 
> > Thoughts?
> > 
> 
> There''s no way to reset ip_conntrack short of removing the module.
> 
And BTW -- I personally have NEWNOTSYN=Yes. I think NEWNOTSYN=No is a
PITA...

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

On Wed, 2003-08-20 at 09:01, Tom Eastep wrote:
> On Wed, 2003-08-20 at 08:36, ian wrote:
> 
> > > 
> > > As a stab in the dark, please try disabling MAC verification on
eth1 and
> > > see if you still have the problem.
> > 
> > Tried that.. Didn''t make any change.
> > 
> > I just noticed I''m getting a ton of messages in the log after
said
> > restart that say Shorewall:newnotsyn:DROP.  So I turned newnotsyn off 
> > and now I can restart with abandon and I don''t loose my
connections.
> > 
> > Hmm.. I wonder if ip_conntrack is getting reset after a shorewall 
> > restart and that would make the system forget about known connections.
> > 
> > Thoughts?
> > 
> 
> There''s no way to reset ip_conntrack short of removing the module.
> 
Ian,

Anything more to report on this?

I''m using the ''newnotsyn'' on all of my internal
interfaces (eth[1-3])
but I have the following in /etc/shorewall/newnotsyn:

for interface in `find_interfaces_by_option newnotsyn`; do
    run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags ACK ACK
-j ACCEPT
    run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags RST RST
-j ACCEPT
    run_iptables -D newnotsyn -i $interface -p tcp --tcp-flags FIN FIN
-j ACCEPT
done
 
run_iptables -A newnotsyn -p tcp --tcp-flags ACK ACK -j ACCEPT
run_iptables -A newnotsyn -p tcp --tcp-flags RST RST -j ACCEPT
run_iptables -A newnotsyn -p tcp --tcp-flags FIN FIN -j ACCEPT

In other words, I accept ACK, RST and FIN from all interfaces, not just
those with the ''newnotsyn''. Seems to work much smoother.

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

On Thu, 2003-08-21 at 10:53, Tom Eastep wrote:
> 
> I''m using the ''newnotsyn'' on all of my internal
interfaces (eth[1-3])
> but I have the following in /etc/shorewall/newnotsyn:
> 
I realize that this conflicts with my pronouncement the other day that I
use NEWNOTSYN=Yes. I had forgotten that I had switched to NEWNOTSYN=No
and the ''newnotsyn'' interface option at the time that I
implemented that
option.

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

Hohoho..

So what should I test it as then?

shorewall.conf: NEWNOTSYN=No
&
interfaces: newnotsyn on which interfaces?

ian



Tom Eastep wrote:
> On Thu, 2003-08-21 at 10:53, Tom Eastep wrote:
> 
> 
>>I''m using the ''newnotsyn'' on all of my
internal interfaces (eth[1-3])
>>but I have the following in /etc/shorewall/newnotsyn:
>>
> 
> 
> I realize that this conflicts with my pronouncement the other day that I
> use NEWNOTSYN=Yes. I had forgotten that I had switched to NEWNOTSYN=No
> and the ''newnotsyn'' interface option at the time that I
implemented that
> option.
> 
> -Tom

On Fri, 2003-08-22 at 12:31, ian wrote:
> Hohoho..
> 
> So what should I test it as then?
> 
> shorewall.conf: NEWNOTSYN=No
> &
> interfaces: newnotsyn on which interfaces?
Your internal ones I would think. It will be interesting to see if you
also need the hack that I have in /etc/shorewall/newnotsyn...

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