Date: Mon, 8 Jan 2018 10:46:28 -0800 From: Freddie Cash <fjwcash@gmail.com> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: galtsev@kicp.uchicago.edu, freebsd-net <freebsd-net@freebsd.org> Subject: Re: Fwd: Re: Quasi-enterprise WiFi network Message-ID: <CAOjFWZ48aORiK0V%2BZk2y8LLfYpJO%2BgXmaC%2BmNMQG_Lj7-cY1hA@mail.gmail.com> In-Reply-To: <CAOjFWZ6XY2pHaVUqwSxL=hK9VdKh0ZdFMeHMdbhsDC=z8zngYw@mail.gmail.com> References: <CAOjFWZ6kYSTKmPHpQqd%2BywrUNVLcG6JNzwFJYPyt5z1H4HeRUw@mail.gmail.com> <20180107180422.GA46756@admin.sibptus.transneft.ru> <52165.108.68.171.12.1515350430.squirrel@cosmo.uchicago.edu> <CAOjFWZ5j%2BixKVc0cy6ik=BuU0nmpdUgFyePAVDouKmS=MM9vOg@mail.gmail.com> <20180108072035.GB52442@admin.sibptus.transneft.ru> <CAOjFWZ6XY2pHaVUqwSxL=hK9VdKh0ZdFMeHMdbhsDC=z8zngYw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 8, 2018 at 10:42 AM, Freddie Cash <fjwcash@gmail.com> wrote: > On Sun, Jan 7, 2018 at 11:20 PM, Victor Sudakov <vas@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 peop= le >> > through visiting a non-encrypted website, in order to bring up our log= in >> > 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. > > > =E2=80=8BCorrect. As we are a school district where each school has thei= r own > Internet connection, we try to do as much traffic blocking/shaping locall= y, > 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 =E2=80=8Bnetwork 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 th= at > grabbed the MAC from the device via the login page. It can easily be don= e > 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=3D302] > > # 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. > =E2=80=8BForgot 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). --=20 Freddie Cash fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ48aORiK0V%2BZk2y8LLfYpJO%2BgXmaC%2BmNMQG_Lj7-cY1hA>