Hello, I have searched the list but couldn''t find the right answer. I want to drop an established DNAT connection but could not manage it yet. Someone earlier said to bring down the public interfaces, stop shorewall, bring up the public interface and then start shorewall again but this won''t work. I also saw a message from Tom that someone then should unload all iptables modules but have no clue how to do that. I thought I could do iut by taking the file modules and replace loadmodules by rmmod and reverse this list. But if I do that I get several errors that the device is busy. Peter
Peter Lindeman wrote:> Hello, > > I have searched the list but couldn''t find the right answer. I want to > drop an established DNAT connection but could not manage it yet. > Someone earlier said to bring down the public interfaces, stop > shorewall, bring up the public interface and then start shorewall again > but this won''t work. > I also saw a message from Tom that someone then should unload all > iptables modules but have no clue how to do that. I thought I could do > iut by taking the file modules and replace loadmodules by rmmod and > reverse this list. But if I do that I get several errors that the device > is busy.Some of the modules won''t allow you to unload them while they have tracked connections -- Catch 22. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:>> I have searched the list but couldn''t find the right answer. I want to >> drop an established DNAT connection but could not manage it yet. >> Someone earlier said to bring down the public interfaces, stop >> shorewall, bring up the public interface and then start shorewall >> again but this won''t work. >> I also saw a message from Tom that someone then should unload all >> iptables modules but have no clue how to do that. I thought I could do >> iut by taking the file modules and replace loadmodules by rmmod and >> reverse this list. But if I do that I get several errors that the >> device is busy. > > > Some of the modules won''t allow you to unload them while they have > tracked connections -- Catch 22.Hmmm, so basically what I want is not possible at all? Peter
Peter Lindeman wrote:> > > Hmmm, so basically what I want is not possible at all? >If ''lsmod'' shows that there is no dependency on the module you are trying to unload yet it won''t unload, then there is nothing you can do but wait until the module is willing to be unloaded. Or you can reboot. If there are module dependencies then of course the dependent modules must be unloaded first. And if you want to complain any more about the lack of a way to remove an entry from the conntrack table, please do so on the Netfilter Development list where there are people who can do something about it (you can go to the back of the long line of people who have requested that feature). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Wed, 2004-05-26 at 09:46, Tom Eastep wrote:> Peter Lindeman wrote: > > Hello, > > > > I have searched the list but couldn''t find the right answer. I want to > > drop an established DNAT connection but could not manage it yet. > > Someone earlier said to bring down the public interfaces, stop > > shorewall, bring up the public interface and then start shorewall again > > but this won''t work. > > I also saw a message from Tom that someone then should unload all > > iptables modules but have no clue how to do that. I thought I could do > > iut by taking the file modules and replace loadmodules by rmmod and > > reverse this list. But if I do that I get several errors that the device > > is busy. > > Some of the modules won''t allow you to unload them while they have > tracked connections -- Catch 22. > > -TomThis must be why I can do a "shorewall restart" and any netradio broadcasts that are coming in remain unaffected. I remember being singularly impressed by that. :) LX
> > Peter Lindeman wrote: > > > Hello, > > > > > > I have searched the list but couldn''t find the right answer. I want to > > > drop an established DNAT connection but could not manage it yet.Oh no...., Forgive me, but I thought this was clearly possible by setting "shorewall.conf", BLACKLISTNEWONLY=No "1.) BLACKLISTNEWONLY=No -- All incoming packets are checked against the blacklist. New blacklist entries can be used to terminate existing connections." I thought that I could dynamically Blacklist any existing connection simple by doing "shorewall [drop|reject|allow] <ip address>" and the connection would be either handled accordingly. I gather from reading this post that this isn''t possible? I thought that was the hole idea behind dynamic blacklisting. To drop "incoming established connections" at will. I''ve re-read through this thread the documentation and it appears that I must be misunderstanding something huge. Please set me straight. Thanks, Joshua Banks
Joshua Banks wrote:>>>Peter Lindeman wrote: >>> >>>>Hello, >>>> >>>>I have searched the list but couldn''t find the right answer. I want to >>>>drop an established DNAT connection but could not manage it yet. > > > Oh no...., > Forgive me, but I thought this was clearly possible by setting > "shorewall.conf", > BLACKLISTNEWONLY=No > > "1.) BLACKLISTNEWONLY=No -- All incoming packets are checked against the > blacklist. New blacklist entries can be used to terminate existing > connections." > > I thought that I could dynamically Blacklist any existing connection simple > by doing "shorewall [drop|reject|allow] <ip address>" and the connection > would be either handled accordingly. > > I gather from reading this post that this isn''t possible? I thought that was > the hole idea behind dynamic blacklisting. To drop "incoming established > connections" at will. > > I''ve re-read through this thread the documentation and it appears that I > must be misunderstanding something huge. Please set me straight.Either I misunderstood the original poster''s question or you did... My money''s on you.... -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
From: "Tom Eastep"> Either I misunderstood the original poster''s question or you did... > > My money''s on you....Si of relief. :) Thanks Tom. I''ll re-read the thread again thanks. Joshua Banks
Tom Eastep wrote:> Joshua Banks wrote: > >>>> Peter Lindeman wrote: >>>> >>>>> Hello, >>>>> >>>>> I have searched the list but couldn''t find the right answer. I want to >>>>> drop an established DNAT connection but could not manage it yet. >> >> >> >> Oh no...., >> Forgive me, but I thought this was clearly possible by setting >> "shorewall.conf", >> BLACKLISTNEWONLY=No >> >> "1.) BLACKLISTNEWONLY=No -- All incoming packets are checked against the >> blacklist. New blacklist entries can be used to terminate existing >> connections." >> >> I thought that I could dynamically Blacklist any existing connection >> simple >> by doing "shorewall [drop|reject|allow] <ip address>" and the connection >> would be either handled accordingly. >> >> I gather from reading this post that this isn''t possible? I thought >> that was >> the hole idea behind dynamic blacklisting. To drop "incoming established >> connections" at will. >> >> I''ve re-read through this thread the documentation and it appears that I >> must be misunderstanding something huge. Please set me straight. > > > Either I misunderstood the original poster''s question or you did... > > My money''s on you....Blacklisting the remote IP will stop traffic through the connection but it won''t remove the conntrack entry. This is the same reason that the string-match thingy in Patch-O-Matic is considered to be such a bad idea. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
----- Original Message ----- From: "Tom Eastep"> > Either I misunderstood the original poster''s question or you did... > > > > My money''s on you.... > > Blacklisting the remote IP will stop traffic through the connection but > it won''t remove the conntrack entry. This is the same reason that the > string-match thingy in Patch-O-Matic is considered to be such a bad idea.Hmmmm.. Ok .. maybe this is a little over my head. I''m totally up for the research though.. So "shorewall drop|reject <ip address>" doesn''t drop or reset the connection it just drops the traffic within the connection? Again.. sorry.. Just want to make sure I''m hearing you correctly.. I''m clearly missing something obvious here.. Thanks, Joshua Banks
Joshua Banks wrote:> ----- Original Message ----- > From: "Tom Eastep" > >>>Either I misunderstood the original poster''s question or you did... >>> >>>My money''s on you.... >> >>Blacklisting the remote IP will stop traffic through the connection but >>it won''t remove the conntrack entry. This is the same reason that the >>string-match thingy in Patch-O-Matic is considered to be such a bad idea. > > > Hmmmm.. Ok .. maybe this is a little over my head. I''m totally up for the > research though.. So "shorewall drop|reject <ip address>" doesn''t drop or > reset the connection it just drops the traffic within the connection? > Again.. sorry.. Just want to make sure I''m hearing you correctly.. I''m > clearly missing something obvious here.. >Here''s my understanding. When you "drop|reject <IP>" then any traffic *from* IP will be either thrown away (drop) or responded to with an RST (tcp) or an ICMP (other protocols). *AND THAT IS ALL*. For example: a) Traffic *to* the IP is unaffected. b) Tracked connection entries involving IP are unaffected. If dropping or rejecting the traffic causes <IP> to respond with an RST (tcp), then the connection tracking entry will be deleted after a 10 second delay. Otherwise, the entry must time out. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
----- Original Message ----- From: "Tom Eastep"> Here''s my understanding. > > When you "drop|reject <IP>" then any traffic *from* IP will be either > thrown away (drop) or responded to with an RST (tcp) or an ICMP (other > protocols). *AND THAT IS ALL*. For example: > > a) Traffic *to* the IP is unaffected.Ahhhhh. Ok.. Just to clarify... TCP inside of IP per normal... When you say *to* do you mean "back *to* the remote ip, for instance.. Remote ip=*from*.. SYN.... dport 80 > DNAT > internal webserver behind shorewall Loc lan server.. Loc ip=*to* SYN ACK back to Remote ip. Basically the other half of the connection going back to the Remote client that initiated the original connection is unaffected when "shorewall drop|reject <Remote ip address>" is invoked. I mean the TCP traffic is affected but the IP connection remains tracked in Shorewall from the Loc web server back to remote client? .... and then the following can/will happen below?> b) Tracked connection entries involving IP are unaffected. > > If dropping or rejecting the traffic causes <IP> to respond with an RST > (tcp), then the connection tracking entry will be deleted after a 10 > second delay. Otherwise, the entry must time out.Thanks very much Tom.. Time to hook up ethereal and take a looksee. Joshua Banks
> > ----- Original Message ----- > From: "Tom Eastep" >> Here''s my understanding. >> >> When you "drop|reject <IP>" then any traffic *from* IP will be either >> thrown away (drop) or responded to with an RST (tcp) or an ICMP (other >> protocols). *AND THAT IS ALL*. For example: >> >> a) Traffic *to* the IP is unaffected. > > Ahhhhh. Ok.. Just to clarify... TCP inside of IP per normal... When you > say > *to* do you mean "back *to* the remote ip, for instance.. > Remote ip=*from*.. SYN.... dport 80 > DNAT > internal webserver behind > shorewall Loc lan server.. > Loc ip=*to* SYN ACK back to Remote ip. > Basically the other half of the connection going back to the Remote client > that initiated the original connection is unaffected when "shorewall > drop|reject <Remote ip address>" is invoked. I mean the TCP traffic is > affected but the IP connection remains tracked in Shorewall from the LocThe connection remains tracked in Linux netfilter, no Shorewall. To achieve what you want, I suggest trying a combination of preventing new connections with Shorewall and killing established connections with cutter (http://www.lowth.com/cutter/). Maybe to have to call cutter several times to really kill the beast but somehow it should work. Unfortunately this is for TCP only, UDP is much trickier. Simon> web > server back to remote client? .... and then the following can/will happen > below? > >> b) Tracked connection entries involving IP are unaffected. >> >> If dropping or rejecting the traffic causes <IP> to respond with an RST >> (tcp), then the connection tracking entry will be deleted after a 10 >> second delay. Otherwise, the entry must time out. > > Thanks very much Tom.. Time to hook up ethereal and take a looksee. > > Joshua Banks > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm > >
----- Original Message ----- From: "Simon Matter" The connection remains tracked in Linux netfilter, no Shorewall. To achieve what you want, I suggest trying a combination of preventing new connections with Shorewall and killing established connections with cutter (http://www.lowth.com/cutter/). Maybe to have to call cutter several times to really kill the beast but somehow it should work. Unfortunately this is for TCP only, UDP is much trickier. Sweet.. Thanks for reminding me that this is Netfilter and Shorewall is the awesome Front-End to managing and manipulating Netfilters iptables. Thanks also for the link. That indeed rocks. I always assumed that the "shorewall dynamic blacklisting commands" were actually COMpletely severing the connection from existence.. so again.. Shorewall keeps me on my toes..always learning something new. Thanks Tom and Simon, Joshua Banks