Dinesh Nair wrote:
> 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.
Well, I can only speak for myself of course, and I'm probably not your
typcial captive portal user/admin! I run m0n0wall on my home network,
and would like to use the captive portal partly as a gimmick to
impress my WLAN guests, and partly to discourage abuse of my WLAN/WAN
by making sure any "intruders" are at least shown a few lines of legal
mumbojumbo (and a warning about their IP being logged) before being
allowed to (ab)use my WAN line. Later on I might even elaborate on the
concept with some kind of added security and/or authentication.
For this use (and yes, I realise this isn't what the captive portal
was meant for) it would be nice if I could allow some specific hosts
(ie. my own) to bypass the portal, without having to add a seperate
interface to my m0n0wall box, for just this purpose (after all
wireless devices, especially standalone APs, aren't THAT cheap!) This
is only really usefull, however, if these hosts have no restrictions
on their WAN access (including not having to do a http request to get
access, thus my request for something other than the MAC list!)
Also (and this might actually be a real argument, even for serious
users of the portal feature), using a separate interface for
non-portal users will entail running two wireless devices on top of
eachother (assuming a setup where both portal and non-portal users are
using wireless access). This might not be optimal for any number of
reasons (including, but not limited to: interference, added security
risks/overhead, increased costs, increased number of parts that can
break down and so on...) In fact some of this even holds for
non-wireless use of the portal (at the very least you'd need an extra
switch and some added patching, which might be a problem if the
physical location of the two types of users change frequently!)
I wouldn't say any of this is "overwhelming", so perhaps you should
wait to hear from other users as well before deciding. On the other
hand, I can't see any harm in adding this feature (that's assuming you
have nothing better to do with your time, of course?) If left unused I
assume that everything will be the same as before security- and
Thanks for your time helping Manuel with this feature!