All of lore.kernel.org
 help / color / mirror / Atom feed
From: I & L Fogg <il.fogg@bigpond.net.au>
To: netfilter@lists.netfilter.org, I & L Fogg <il.fogg@bigpond.net.au>
Subject: How to get "real time" kernel updates from iptables
Date: Tue, 15 Mar 2005 01:33:30 +1000	[thread overview]
Message-ID: <4235AECA.80305@bigpond.net.au> (raw)

I would appreciate any advice on the following problem (if it is, in 
fact, a problem).

I have a pretty simple situation whereby I block internet access to 
clients behind my iptables firewall until they have been properly 
authenticated.

I set up a user-defined chain 'captive' with a default rule to redirect 
traffic to a local web server (that handles the authentication)...

iptables -t nat -A captive -i eth0 -j REDIRECT

This chain is traversed from nat's PREROUTING chain...

iptables -t nat -A PREROUTING -j captive

If/once the user authenticates, a script fires and inserts a 
'short-circuit' rule into the captive chain. After completing, the 
captive chain looks like (which will allow client 192.168.1.222 to 
escape the wormhole)...

iptables -t nat -I captive -s 192.168.1.222 -j RETURN
iptables -t nat -A captive -i eth0 -j REDIRECT

The problem...

My clients need to wait 10-15 seconds before trying to access the 
internet. Shorter waits (ie, user starting to surf the web too early) 
result in a re-capture (REDIRECT), as if the 'short circuit' rule had 
never been inserted. I suspect this is being caused by delays in 
iptables updating the rule base, and the rules making it into the kernel 
(via the netlink socket???).

Is there anything I can do to reduce/eliminate the delay in getting 
updates into the kernel? I have tried an 'iptables-save | 
iptables-restore' in the hope that the COMMITs in the restore would do 
what the docs say (iptc_commit the changes to the kernel), but this 
doesn't seem to help.

I'm running iptables v 1.2.11 on a 2.6.10 kernel.

This has been bugging me for days, so I'd really appreciate any 
suggestions, of even a confirmation that there's not much I can do about 
it (the delay). In the latter case, I can set my user expectations, 
which is not my preferred course of action.

Cheers, Iain


             reply	other threads:[~2005-03-14 15:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 15:33 I & L Fogg [this message]
2005-03-14 22:32 ` How to get "real time" kernel updates from iptables Eric Leblond
2005-03-15  8:45   ` Mohamed Eldesoky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4235AECA.80305@bigpond.net.au \
    --to=il.fogg@bigpond.net.au \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.