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
next 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.