From owner-freebsd-net@freebsd.org Mon Jan 8 18:46:31 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5770EE7E103 for ; Mon, 8 Jan 2018 18:46:31 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B79226C854 for ; Mon, 8 Jan 2018 18:46:30 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id h137so13168675lfe.8 for ; Mon, 08 Jan 2018 10:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6iOElqGwechRKv+Uh7FRTJjglfbbMPPfoNoPs3l5jkQ=; b=XvnOW7enr6p3JS2TpKLC8caFPWNw8cZP8RU9VmK9qRQV/U9YbKZfic/JQmImT3Wqmt 7Cp3tj4KW8BKPAyPZhkHmzoIkRRuZ48kyoncxB1g8w8xnxj+2l/pKhw69eX2SLLSddD9 00aG1aXwfatxMiv6ASXGWmuJuoBg7X1B8siXJau0tpS2C56EnuXdmESCgyIntIHW3zVe We75WNUFhM9iTXPWtOiEN+AVSSnNV+1U/u+oT5s0b4LQVvOtzOj0XXvUG/8IoKi7CY6v Bu6bxww/MPk75e1cUq8aZrHf5ofWb8/s0LfDp1vm0XZaOvlTRWmLEtCW8OnqWNsxKKrJ fAEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6iOElqGwechRKv+Uh7FRTJjglfbbMPPfoNoPs3l5jkQ=; b=suCrmBLgQq5VnvcqdKz2y4ePW+8gr1nQSQVcNE2D102GD6XGre8N2bS3vteD7Gj0WC gdLdhMSkaTKcHAXYQnQT28fdFskw62MqnMIabqnMyeKhfRXrIuN0RouFkSKN+5eZnqfy J1byy/9Ewp5t75hY5MAsarsQqM+BP18LcEyyp8GXAfvmcZFe4rNbSk1jfOLRIFVJLrwI UmYocVLC6Rgx8SdMyB5dR/PgLM7yAmNKLNZhhy78Y0VkdxlXGg82PLtgJtS8fVUSCFLk fhTnaUM6QXQbfQnIBncmQLwsCL0y/zg2o2UdhdOl4ExeEOGainMQuHtHAkwR9rX/yi+7 FbSg== X-Gm-Message-State: AKwxyteY546vvgfItUZvtbDDXMopuvxsB5gGJ2YddUvJjHO+3o7SC6dh dXLjMdU7TH7xA8Zx2WpGFOs8YuVnjdO2n6CLkUk= X-Google-Smtp-Source: ACJfBos4+Jln+chVKieTiLUdXPVFtUVER76sjAnV+1saC3Xb5deaI6TBny/QQ9Pza+JfdJZSszTp6dZQFbqP9pDaxYI= X-Received: by 10.25.86.17 with SMTP id k17mr6634871lfb.67.1515437188601; Mon, 08 Jan 2018 10:46:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Mon, 8 Jan 2018 10:46:28 -0800 (PST) In-Reply-To: References: <20180107180422.GA46756@admin.sibptus.transneft.ru> <52165.108.68.171.12.1515350430.squirrel@cosmo.uchicago.edu> <20180108072035.GB52442@admin.sibptus.transneft.ru> From: Freddie Cash Date: Mon, 8 Jan 2018 10:46:28 -0800 Message-ID: Subject: Re: Fwd: Re: Quasi-enterprise WiFi network To: Victor Sudakov Cc: galtsev@kicp.uchicago.edu, freebsd-net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:46:31 -0000 On Mon, Jan 8, 2018 at 10:42 AM, Freddie Cash wrote: > On Sun, Jan 7, 2018 at 11:20 PM, Victor Sudakov > 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