On Mon, Jan 8, 2018 at 10:42 AM, Freddie Cash <fjwc...@gmail.com> wrote:
> On Sun, Jan 7, 2018 at 11:20 PM, Victor Sudakov <v...@mpeks.tomsk.su>
> wrote:
>
>> Freddie Cash wrote:
>> >
>> > > One trouble I expect here is: if the client goes to https
>> destination, it
>> > > will complain about your local apache certificate, as the client
>> expects
>> > > next packet (SSL negotiation) to come from host it was going
>> originally
>> > > to. I've seen quite a few of similar things. "Home brew" words come
>> to my
>> > > mind, no offense intended. Even older or two WiFi setups central IT
>> folks
>> > > at big university I work for did this setup that brakes when client
>> goes
>> > > to SSL-ed URL. Next, what if client does not use web browser at all,
>> and
>> > > just attempts to ssh to external host...
>> >
>> > That was an issue with our original setup that only used firewall
>> redirect
>> > rules, without the mod_rewrite stuff. It only worked if we walked people
>> > through visiting a non-encrypted website, in order to bring up our login
>> > page. As more and more sites started defaulting to HTTPS, it became
>> > cumbersome.
>> >
>> > All mobile devices, including Windows/MacOS devices, include captive
>> portal
>> > detection these days, where they attempt to connect to a specific set of
>> > HTTP sites after connecting to a network. The mod_rewrite rules
>> intercept
>> > only these requests, and redirect them to the login page.
>>
>> Your mod_rewrite rules are becoming more and more interesting. Please
>> do post them.
>>
>> There is one more drawback however I have just thought about. If I go
>> for a WiFi solution, I can deploy just an AP at some remote branch as
>> a RADIUS client of the central FreeRADIUS server.
>>
>> If I go for a captive portal solution, I would need to install captive
>> portals at every branch, or tunnel Internet traffic via the central
>> hub.
>
>
> Correct. As we are a school district where each school has their own
> Internet connection, we try to do as much traffic blocking/shaping locally,
> so we have a separate wireless firewall in each school (and we use
> Colubris/HPe/Aruba access points as they don't tunnel traffic back to a
> central controller like Cisco and other gear does). That handles the
> captive portal, DHCP for wireless devices, etc for each school. The nice
> thing is that since it's all done with private addressing, the wireless
> firewalls are virtually identical and easy to image/replace. :) But it is
> one more server to manage at each site.
>
> Our setup uses the MAC address of the device simply because our public
> guest network setup is derived from our BYOD network setup. Our BYOD
> network uses the MAC address as it's unique to the device and gets shared
> out to all the schools such that once a device is enabled on our BYOD
> network, it will work in any school. Since we had that infrastructure
> already in place, we just extended it to create a public guest network that
> grabbed the MAC from the device via the login page. It can easily be done
> using the IP of the device instead, to make the firewall rules easier to
> write on FreeBSD (MAC address rules in IPFW are ... interesting ... to
> write).
>
> Our firewall rules go something like:
> - allow all the local traffic to the wireless firewall (DHCP, DNS, NTP,
> HTTP)
> - allow Internet traffic if the MAC is in the allowed table
> - redirect all other traffic to Apache running on the wireless firewall
> - block everything else
>
> In the Apache configuration, the following mod_rewrite rules are enabled:
> # Captive portal stuff
> RewriteEngine on
>
> # Apple devices
> RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC]
> RewriteCond %{HTTP_HOST} !^10.40.0.1$
> RewriteCond %{REQUEST_URI} !^/login.php [NC]
> RewriteRule ^(.*)$ http://10.40.0.1/index.php [L,R=302]
>
> # Android devices
> RewriteCond %{HTTP_HOST} !^10.40.0.1$
> RewriteCond %{REQUEST_URI} !^/login.php [NC]
> RedirectMatch 302 /generate_204 http://10.40.0.1/index.php
>
> # Windows devices
> RewriteCond %{HTTP_HOST} !^10.40.0.1$
> RewriteCond %{REQUEST_URI} !^/login.php [NC]
> RedirectMatch 302 /ncsi.txt http://10.40.0.1/index.php
>
> # Catch-all for everything else
> RewriteCond %{REQUEST_URI} !^/captive/ [NC]
> RewriteCond %{HTTP_HOST} !^10.40.0.1$
> RewriteRule ^(.*)$ http://10.40.0.1/index.php [L]
>
> If the HTTP traffic matches the RewriteCond expression, then the
> destination URL is rewritten to the RewriteRule location. We exclude the
> server IP (!^10.40.0.1) as the login page POSTs to the server for
> processing. And we exclude the login page itself (!^login.php) where all
> the authentication is done. The index.php displays information about the
> network, shows the login fields, and POSTs to login.php.
>
> Let me know if you need any other information.
>
Forgot to mention that a successful login adds the MAC address of the
device to the table of allowed MACs (that way, no reloading of the firewall
rules is needed and no traffic is dropped during the reload). And we have
a separate cronjob that runs at midnight to clear out that table (so no
devices are allowed in the morning).
--
Freddie Cash
fjwc...@gmail.com
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
