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 
other-wise?


Thanks for your time helping Manuel with this feature!

Regards,

Adam.