> maybe i'd explain how the captive portal works. manuel first wrote in
> captive portal functionality, and i stepped in later with some
> and RADIUS support.
Right - sorry - couldn't remember at what point you got involved, just
remembered you did a buunch of the heavy lifting recently ;-)
> the captive portal initially sets up IPFW rules to divert all outgoing
> connections to another instance of httpd which throws up the
> page. upon successful authentication, specific rules opening access are
> created for the IP and MAC address of the client host and
> subsequent access
> by this client is allowed thru without being diverted. though the IP
> address is used specifically to bypass the divert, it's still tied to the
> MAC address.
Meaning that on a routed public network it would only see the MAC of the
nearest router sending traffic - correct?
> this means an IP address, once bound to a MAC address on the captive
> portal, will only be allowed access if it continues to be bound
> to that MAC
That would be the case, but it would just appear that multiple IP's had the
same MAC address. Does ieach new bind displace the old one? Or is it a
simple check like:
IF ((IP in [IP_LIST]) && (MAC == RememberedMAC[IP])) THEN allow
Admittedly that's not as secure - it basically makes the MAC side
non-existant - but wouldn't it still work?
> because of the binding to MAC addresses, it would not be possible
> to twist
> the m0n0wall around to face the WAN in a NATted environment and
> then to use
> the captive portal functionality as a authentication service of sorts.
If above I misunderstood, and there list is turned around (e.g.
RememberedIP[MAC]) could this be hacked out? Any starter-pointers?
Also, what are your thoughts on adding https support?
A number of people have expressed interest in this - particularly when they
decide to use their WINNT database as the RADIUS server, it would be nice
not to have to expose those passwords on the wireless. From mono to WINNT
could be handled by tunnel if it's offsite of course.