* Reset conntrack...
@ 2004-12-02 22:09 Sven Anders
2004-12-02 23:24 ` Richard
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Sven Anders @ 2004-12-02 22:09 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
Is it possible to reset the conntrack list or set any entry to the state NEW to force
a recheck against new filter rules?
The problem is:
~ If I set the (new) filtering rules with the target DROP, I want old
~ (existing) connections to be dropped immediatly.
~ The global rule '--state RELATED,ESTABLISHED' I set would still allow them...
Regards
~ Sven
- --
~ Sven Anders <anders@anduras.de>
~ ANDURAS service solutions AG
~ Innstraße 71 - 94036 Passau - Germany
~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h
QzBcNjCwn8da+HnPIaGjH+M=
=cVzY
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 12+ messages in thread* RE: Reset conntrack... 2004-12-02 22:09 Reset conntrack Sven Anders @ 2004-12-02 23:24 ` Richard 2004-12-03 6:08 ` Patrick Schaaf ` (2 subsequent siblings) 3 siblings, 0 replies; 12+ messages in thread From: Richard @ 2004-12-02 23:24 UTC (permalink / raw) To: 'Sven Anders', netfilter-devel > > Hello! > > Is it possible to reset the conntrack list or set any entry to the state > NEW to force > a recheck against new filter rules? > > The problem is: > > ~ If I set the (new) filtering rules with the target DROP, I want old > ~ (existing) connections to be dropped immediatly. > ~ The global rule '--state RELATED,ESTABLISHED' I set would still allow > them... > I am in the process to write a TARGET which sets the conntrack expire value. I am not sure if you set it to zero will immediately drop the connection. But at least you can set it to 1 and let it drop in 1 second. https://lists.netfilter.org/pipermail/netfilter-devel/2004-December/017582.h tml Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-02 22:09 Reset conntrack Sven Anders 2004-12-02 23:24 ` Richard @ 2004-12-03 6:08 ` Patrick Schaaf 2004-12-03 11:11 ` Sven Anders 2004-12-03 11:43 ` Yutaka Kondo 2004-12-04 14:44 ` Henrik Nordstrom 3 siblings, 1 reply; 12+ messages in thread From: Patrick Schaaf @ 2004-12-03 6:08 UTC (permalink / raw) To: Sven Anders; +Cc: netfilter-devel > Is it possible to reset the conntrack list or set any entry to the state > NEW to force a recheck against new filter rules? > ~ If I set the (new) filtering rules with the target DROP, I want old > ~ (existing) connections to be dropped immediatly. Consider using REJECT. This has two advantages: it gives the end systems you are now blocking a chance at state cleanup (instead of needlessly wasting memory and CPU resources on a connection that you now elect to forbit). But, the greater advantage: the packets that the end systems exchange in response to the connection teardown, are JUST what you need to get rid of their conntracks. Of course, one could do what you requested. Maybe even without coding. I wouldn't know. Maybe others. best regards Patrick ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 6:08 ` Patrick Schaaf @ 2004-12-03 11:11 ` Sven Anders 2004-12-03 16:07 ` Phil Oester ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Sven Anders @ 2004-12-03 11:11 UTC (permalink / raw) To: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 2273 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patrick Schaaf wrote: |>Is it possible to reset the conntrack list or set any entry to the state |>NEW to force a recheck against new filter rules? |>~ If I set the (new) filtering rules with the target DROP, I want old |>~ (existing) connections to be dropped immediatly. | | | Consider using REJECT. This has two advantages: it gives the end | systems you are now blocking a chance at state cleanup (instead of | needlessly wasting memory and CPU resources on a connection that you | now elect to forbit). But, the greater advantage: the packets that | the end systems exchange in response to the connection teardown, | are JUST what you need to get rid of their conntracks. This is not exactly what I'm meant... Consider the following scenario: ~ 1. Set firewall rules ~ with: ~ a) ACCEPT on all --state RELATED,ESTABLISHED ~ b) with ACCEPT on ports 22 and 80 ~ 2. Remote client creates connection through the firewall ~ on the port 80 (CONNTRACK state is: NEW) ~ It will be allowed due to the ACCEPT policy... ~ 3. Server answers and connection CONNTRACK state will be changed ~ to ESTABLISHED ~ 4. Set new firewall rules: ~ Changed b) to only allow port 22 ~ 5. The connection to port 80 will continue to exists, because ~ it CONNTRACK state did not change and we have rule a)... Possible solutions: ~ 1) Recheck all CONNTRACK entries against the new firewall rules. ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to ~ NEW, to force the recheck. Is there any way to accomplish this? Regards ~ Sven - -- ~ Sven Anders <anders@anduras.de> ~ ANDURAS service solutions AG ~ Innstraße 71 - 94036 Passau - Germany ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBsEnF5lKZ7Feg4EcRAuGSAJ9CcGazy29uLg3OYVyf86UZHDZ8dwCdF7do ufAoHMfOh0O7qe+s3jYbwQI= =5R7c -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 11:11 ` Sven Anders @ 2004-12-03 16:07 ` Phil Oester 2004-12-03 21:07 ` Carl-Daniel Hailfinger 2004-12-04 14:51 ` Henrik Nordstrom 2 siblings, 0 replies; 12+ messages in thread From: Phil Oester @ 2004-12-03 16:07 UTC (permalink / raw) To: Sven Anders; +Cc: netfilter-devel On Fri, Dec 03, 2004 at 12:11:01PM +0100, Sven Anders wrote: > Possible solutions: > > ~ 1) Recheck all CONNTRACK entries against the new firewall rules. > > ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to > ~ NEW, to force the recheck. > > Is there any way to accomplish this? Make iptables modular, and unload/reload the conntrack module everytime you change your rules. Not pretty, but without hacking the code, the only way to achieve your objective. Phil ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 11:11 ` Sven Anders 2004-12-03 16:07 ` Phil Oester @ 2004-12-03 21:07 ` Carl-Daniel Hailfinger 2004-12-08 11:20 ` Sven Anders 2004-12-04 14:51 ` Henrik Nordstrom 2 siblings, 1 reply; 12+ messages in thread From: Carl-Daniel Hailfinger @ 2004-12-03 21:07 UTC (permalink / raw) To: netfilter-devel Sven Anders schrieb: > Patrick Schaaf wrote: > |>Is it possible to reset the conntrack list or set any entry to the state > |>NEW to force a recheck against new filter rules? > |>~ If I set the (new) filtering rules with the target DROP, I want old > |>~ (existing) connections to be dropped immediatly. > | > | > | Consider using REJECT. This has two advantages: it gives the end > | systems you are now blocking a chance at state cleanup (instead of > | needlessly wasting memory and CPU resources on a connection that you > | now elect to forbit). But, the greater advantage: the packets that > | the end systems exchange in response to the connection teardown, > | are JUST what you need to get rid of their conntracks. > > This is not exactly what I'm meant... > > Consider the following scenario: > > ~ 1. Set firewall rules > ~ with: > ~ a) ACCEPT on all --state RELATED,ESTABLISHED > ~ b) with ACCEPT on ports 22 and 80 > > ~ 2. Remote client creates connection through the firewall > ~ on the port 80 (CONNTRACK state is: NEW) > ~ It will be allowed due to the ACCEPT policy... > > ~ 3. Server answers and connection CONNTRACK state will be changed > ~ to ESTABLISHED > > ~ 4. Set new firewall rules: > ~ Changed b) to only allow port 22 > > ~ 5. The connection to port 80 will continue to exists, because > ~ it CONNTRACK state did not change and we have rule a)... > > Possible solutions: > > ~ 1) Recheck all CONNTRACK entries against the new firewall rules. > > ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to > ~ NEW, to force the recheck. Why so complicated? Insert a rule which rejects connections to port 80 before rule a). That way any packet coming to you on port 80 will cause a reset, tearing down the connection and the problem is solved. The only disadvantage is that your machine may continue sending data until it requires an ack of the remote side to continue. That ack will then cause teardown, too. If that is not good enough, consider adding a reject rule for source port 80 in your OUTPUT table. This will cause any connection which is now forbidden to be teared down once either side wants to send any data. > Is there any way to accomplish this? Yes. (Well, it forces you to add an explicit REJECT rule for every ACCEPT rule you remove, but that is less complicated than patching the kernel.) Regards, Carl-Daniel -- http://www.hailfinger.org/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 21:07 ` Carl-Daniel Hailfinger @ 2004-12-08 11:20 ` Sven Anders 2004-12-08 15:32 ` Henrik Nordstrom 0 siblings, 1 reply; 12+ messages in thread From: Sven Anders @ 2004-12-08 11:20 UTC (permalink / raw) To: netfilter-devel [-- Attachment #1: Type: text/plain, Size: 3412 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carl-Daniel Hailfinger wrote: | Sven Anders schrieb: | |>Patrick Schaaf wrote: |>|>Is it possible to reset the conntrack list or set any entry to the state |>|>NEW to force a recheck against new filter rules? |>|>~ If I set the (new) filtering rules with the target DROP, I want old |>|>~ (existing) connections to be dropped immediatly. |>| |>| |>| Consider using REJECT. This has two advantages: it gives the end |>| systems you are now blocking a chance at state cleanup (instead of |>| needlessly wasting memory and CPU resources on a connection that you |>| now elect to forbit). But, the greater advantage: the packets that |>| the end systems exchange in response to the connection teardown, |>| are JUST what you need to get rid of their conntracks. |> |>This is not exactly what I'm meant... |> |>Consider the following scenario: |> |>~ 1. Set firewall rules |>~ with: |>~ a) ACCEPT on all --state RELATED,ESTABLISHED |>~ b) with ACCEPT on ports 22 and 80 |> |>~ 2. Remote client creates connection through the firewall |>~ on the port 80 (CONNTRACK state is: NEW) |>~ It will be allowed due to the ACCEPT policy... |> |>~ 3. Server answers and connection CONNTRACK state will be changed |>~ to ESTABLISHED |> |>~ 4. Set new firewall rules: |>~ Changed b) to only allow port 22 |> |>~ 5. The connection to port 80 will continue to exists, because |>~ it CONNTRACK state did not change and we have rule a)... |> |>Possible solutions: |> |>~ 1) Recheck all CONNTRACK entries against the new firewall rules. |> |>~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to |>~ NEW, to force the recheck. | | | Why so complicated? Insert a rule which rejects connections to port 80 | before rule a). That way any packet coming to you on port 80 will cause | a reset, tearing down the connection and the problem is solved. The only | disadvantage is that your machine may continue sending data until it | requires an ack of the remote side to continue. That ack will then cause | teardown, too. If that is not good enough, consider adding a reject | rule for source port 80 in your OUTPUT table. | This will cause any connection which is now forbidden to be teared down | once either side wants to send any data. The rules will be set by an (normal) user. So I cannot assume the user to understand why he should insert this rule too... Automatically generating this rule is complicated too, because this rule could conflict with some other rule... |>Is there any way to accomplish this? | | Yes. (Well, it forces you to add an explicit REJECT rule for every | ACCEPT rule you remove, but that is less complicated than patching the | kernel.) Regards ~ Sven - -- ~ Sven Anders <anders@anduras.de> ~ ANDURAS service solutions AG ~ Innstraße 71 - 94036 Passau - Germany ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBtuN45lKZ7Feg4EcRAoZ/AJ9W37rM1Sf9F/8sScUbsokItmItRwCeMUr2 ++4zWG66gUGeIA0Rn25X/WI= =F92r -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-08 11:20 ` Sven Anders @ 2004-12-08 15:32 ` Henrik Nordstrom 0 siblings, 0 replies; 12+ messages in thread From: Henrik Nordstrom @ 2004-12-08 15:32 UTC (permalink / raw) To: Sven Anders; +Cc: netfilter-devel On Wed, 8 Dec 2004, Sven Anders wrote: > |>Possible solutions: > |> > |>~ 1) Recheck all CONNTRACK entries against the new firewall rules. > |> > |>~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to > |>~ NEW, to force the recheck. Implemented years ago by a collegue of mine: https://lists.netfilter.org/pipermail/netfilter-devel/2003-August/012109.html [or alternate archive location where MIME processing actually works...] http://marc.theaimsgroup.com/?l=netfilter-devel&m=105975103717126&w=2 Needs some trivial adjustments for current ip_conntrack versions.. Regards Herik ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 11:11 ` Sven Anders 2004-12-03 16:07 ` Phil Oester 2004-12-03 21:07 ` Carl-Daniel Hailfinger @ 2004-12-04 14:51 ` Henrik Nordstrom 2 siblings, 0 replies; 12+ messages in thread From: Henrik Nordstrom @ 2004-12-04 14:51 UTC (permalink / raw) To: Sven Anders; +Cc: netfilter-devel On Fri, 3 Dec 2004, Sven Anders wrote: > ~ 1) Recheck all CONNTRACK entries against the new firewall rules. > > ~ 2) Set all CONNTRACK entries with states RELATED or ESTABLISHED to > ~ NEW, to force the recheck. Setting it to NEW won't help you as this discards the current conntrack entry, and if the next packet is return traffic or on an related connection your ruleset will get very upset. > Is there any way to accomplish this? There is three ways a) The simple "CONFIRMED" patch posted by a collegue of mine little more than a year ago (see archives). b) Use CONNMARK as a ruleset counter instead of looking for state ESTABLISHED,RELATED. Mark accepted traffic with a specific CONNMARK and then look for this mark rather than the state. Note that in both cases special care is needed to make sure you look at traffic or addresses in the "original" direction. See the conntrack match. Also beware of related connections such as the data channel of FTP connection etc. Regards Henrik ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-02 22:09 Reset conntrack Sven Anders 2004-12-02 23:24 ` Richard 2004-12-03 6:08 ` Patrick Schaaf @ 2004-12-03 11:43 ` Yutaka Kondo 2004-12-03 13:50 ` Ferry Huberts 2004-12-04 14:44 ` Henrik Nordstrom 3 siblings, 1 reply; 12+ messages in thread From: Yutaka Kondo @ 2004-12-03 11:43 UTC (permalink / raw) To: netfilter-devel Hello I made littile change in file ip_conntrack_standalone.c This made, if you write IP address(in_addr_t format) to /proc/net/ip_conntrack, any contrack with SRC address is written address are forced timeout/removed. I think, this is useful for linux firewall with IDS(such as snort). Sorry, I put many debug change to this file for my understand, thus I cannnot post as diff/patch format. YKND add those 2 functions ----------------------- /* YKND Remove conntrack entry, if src ip address match as contrack */ static inline int match_remove_srcip_conntrack(ulong in, struct ip_conntrack *conntrack) { if( in == conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip){ del_timer(&conntrack->timeout); /* Delete from Timeout */ conntrack->timeout.function((unsigned long)conntrack); } return 0; } /* YKND write entry "proc/net/ip_conntrack" */ /* Walk arround conntrack list and call remove entry */ static int ip_conntrack_user_remove(struct file *file, const char *buffer, unsigned long count, void *data) { unsigned int i; ulong in; if(count != sizeof(int)){ printk("Write size error \n"); return count; } in = *(ulong *)buffer; /* DEBUG */ // printk("Address=%u.%u.%u.%u was removed from conntrack \n", NIPQUAD(in)); READ_LOCK(&ip_conntrack_lock); /* Traverse hash; print originals then reply. */ for (i = 0; i < ip_conntrack_htable_size; i++) { const struct list_head * head = &ip_conntrack_hash[i]; do { head = head->next; if (head == &ip_conntrack_hash[i]) { head = NULL; break; } if(head == NULL){ break; } } while (!match_remove_srcip_conntrack(in, ((struct ip_conntrack_tuple_hash *)head)->ctrack)); } READ_UNLOCK(&ip_conntrack_lock); return count; } ----------------------- and put 1 line in, function static int init_or_cleanup(int init) ----------------------- proc->write_proc = ip_conntrack_user_remove; ----------------------- ----- Original Message ----- From: "Sven Anders" <anders@anduras.de> To: <netfilter-devel@lists.netfilter.org> Sent: Friday, December 03, 2004 7:09 AM Subject: Reset conntrack... > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello! > > Is it possible to reset the conntrack list or set any entry to the state > NEW to force > a recheck against new filter rules? > > The problem is: > > ~ If I set the (new) filtering rules with the target DROP, I want old > ~ (existing) connections to be dropped immediatly. > ~ The global rule '--state RELATED,ESTABLISHED' I set would still allow > them... > > Regards > ~ Sven > > - -- > ~ Sven Anders <anders@anduras.de> > > ~ ANDURAS service solutions AG > ~ Innstraße 71 - 94036 Passau - Germany > ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 > 50-55 > > Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB > 6032 > Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön > Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h > QzBcNjCwn8da+HnPIaGjH+M= > =cVzY > -----END PGP SIGNATURE----- > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-03 11:43 ` Yutaka Kondo @ 2004-12-03 13:50 ` Ferry Huberts 0 siblings, 0 replies; 12+ messages in thread From: Ferry Huberts @ 2004-12-03 13:50 UTC (permalink / raw) To: netfilter-devel This is great! I've been looking for this for a while now. But can the write to the proc entry please be in ascii format i.s.o. binary? I use dynamically configured rules for peers that use DHCP: when a peer address changes the old conntrack is in the way and needs to be removed. I use a somewhat dirty trick for this that has more side effects than I want so this solution appeals to me very much! The trick (I use ESP traffic): # clear the connection tracking timeout for ESP traffic (generic) echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout \ 2> /dev/null delete-old-rules add-new-rules # set the connection tracking timeout for ESP traffic (generic) sleep 1 echo $connectiontracking_esp_timeout \ > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout \ 2> /dev/null -- Ferry Huberts > Hello > > I made littile change in file ip_conntrack_standalone.c > > This made, if you write IP address(in_addr_t format) to > /proc/net/ip_conntrack, any contrack with SRC address > is written address are forced timeout/removed. > > I think, this is useful for linux firewall with IDS(such as snort). > > Sorry, I put many debug change to this file for my understand, > thus I cannnot post as diff/patch format. > > YKND > > add those 2 functions > ----------------------- > /* YKND Remove conntrack entry, if src ip address match as contrack */ > static inline int > match_remove_srcip_conntrack(ulong in, struct ip_conntrack *conntrack) > { > if( in == conntrack->tuplehash[IP_CT_DIR_ORIGINAL].tuple.src.ip){ > del_timer(&conntrack->timeout); /* Delete from Timeout */ > conntrack->timeout.function((unsigned long)conntrack); > } > return 0; > } > > /* YKND write entry "proc/net/ip_conntrack" */ > /* Walk arround conntrack list and call remove entry */ > static int > ip_conntrack_user_remove(struct file *file, const char *buffer, > unsigned long count, void *data) > { > unsigned int i; > ulong in; > if(count != sizeof(int)){ > printk("Write size error \n"); > return count; > } > > in = *(ulong *)buffer; > /* DEBUG */ > // printk("Address=%u.%u.%u.%u was removed from conntrack \n", > NIPQUAD(in)); > > READ_LOCK(&ip_conntrack_lock); > > /* Traverse hash; print originals then reply. */ > for (i = 0; i < ip_conntrack_htable_size; i++) { > const struct list_head * head = &ip_conntrack_hash[i]; > do { > head = head->next; > if (head == &ip_conntrack_hash[i]) { > head = NULL; > break; > } > if(head == NULL){ > break; > } > } while (!match_remove_srcip_conntrack(in, ((struct > ip_conntrack_tuple_hash *)head)->ctrack)); > } > READ_UNLOCK(&ip_conntrack_lock); > return count; > } > ----------------------- > > and put 1 line in, function static int init_or_cleanup(int init) > > ----------------------- > proc->write_proc = ip_conntrack_user_remove; > > ----------------------- > > ----- Original Message ----- > From: "Sven Anders" <anders@anduras.de> > To: <netfilter-devel@lists.netfilter.org> > Sent: Friday, December 03, 2004 7:09 AM > Subject: Reset conntrack... > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hello! >> >> Is it possible to reset the conntrack list or set any entry to the state >> NEW to force >> a recheck against new filter rules? >> >> The problem is: >> >> ~ If I set the (new) filtering rules with the target DROP, I want old >> ~ (existing) connections to be dropped immediatly. >> ~ The global rule '--state RELATED,ESTABLISHED' I set would still allow >> them... >> >> Regards >> ~ Sven >> >> - -- >> ~ Sven Anders <anders@anduras.de> >> >> ~ ANDURAS service solutions AG >> ~ Innstraße 71 - 94036 Passau - Germany >> ~ Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 >> 50-55 >> >> Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB >> 6032 >> Mitglieder des Vorstands: Sven Anders, Marcus Junker, Michael Schön >> Vorsitzender des Aufsichtsrats: Dipl. Kfm. Karlheinz Antesberger >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.5 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFBr5Kw5lKZ7Feg4EcRAsENAJ0XErp8VEr6vAIBUiyj9UM+Qm0gMgCdHQ4h >> QzBcNjCwn8da+HnPIaGjH+M= >> =cVzY >> -----END PGP SIGNATURE----- >> > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Reset conntrack... 2004-12-02 22:09 Reset conntrack Sven Anders ` (2 preceding siblings ...) 2004-12-03 11:43 ` Yutaka Kondo @ 2004-12-04 14:44 ` Henrik Nordstrom 3 siblings, 0 replies; 12+ messages in thread From: Henrik Nordstrom @ 2004-12-04 14:44 UTC (permalink / raw) To: Sven Anders; +Cc: netfilter-devel On Thu, 2 Dec 2004, Sven Anders wrote: > Is it possible to reset the conntrack list or set any entry to the state > NEW to force a recheck against new filter rules? You can use CONNMARK for a similar kind of test instead of looking for NEW. Regards Henrik ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-12-08 15:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-12-02 22:09 Reset conntrack Sven Anders 2004-12-02 23:24 ` Richard 2004-12-03 6:08 ` Patrick Schaaf 2004-12-03 11:11 ` Sven Anders 2004-12-03 16:07 ` Phil Oester 2004-12-03 21:07 ` Carl-Daniel Hailfinger 2004-12-08 11:20 ` Sven Anders 2004-12-08 15:32 ` Henrik Nordstrom 2004-12-04 14:51 ` Henrik Nordstrom 2004-12-03 11:43 ` Yutaka Kondo 2004-12-03 13:50 ` Ferry Huberts 2004-12-04 14:44 ` Henrik Nordstrom
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.