On Sun, 16 May 2004, Manuel Kasper wrote:
> On 16.05.2004 18:59 +0200, Adam Nellemann wrote:
> > Is there ANY chance that you will find a workaround to this ipfw
> > limitation? Would it perhaps be possible to avoid this issue if the
> > check was done on the IP instead of the MAC?
> None of my business really, as I didn't code that feature! But we
> could just extend the "Allowed IP addresses" functionality to handle
> both IP addresses on the captive portal subnet ("source") and
> elsewhere ("destination" - status quo).
it wouldnt be difficult to extend this at all. however, from a policy
perspective, would it be alright to do so ?
my thoughts are that if an IP was always going to be punched thru the
captive portal, why would it be sitting behind the captive interface ?
wouldnt it be better to place that server/client on another interface ?
the line of thought i'm going thru is that the captive portal would be
used to allow access to guests in an organization/enterprise or perhaps to
implement some sort of hotspot/public access where a user would have to
agree to ToS and and AUP (the portal page) and authenticate (when i'm done
with radius support) before being allowed thru. an Allowed Source IP would
bypass this and not explicitly agree on the ToS/AUP.
what are your thoughts on this line of reasoning ?
if it's overwhelming in support of Allowed Source IPs, i'll add them in
over this week and pass them over to manuel for inclusion into his next
beta release by the coming weekend. i'm hoping to finish radius
authentication for the captive portal by then as well, with thanx to Jason
Grimm who has kindly provided a radius server to test against.
Regards, /\_/\ "All dogs go to heaven."
dinesh at alphaque dot com (0 0) http://www.alphaque.com/
| for a in past present future; do |
| for b in clients employers associates relatives neighbours pets; do |
| echo "The opinions here in no way reflect the opinions of my $a $b." |
| done; done |