From owner-freebsd-net@freebsd.org Mon Jan 8 18:42:59 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 8C427E7DCD2 for ; Mon, 8 Jan 2018 18:42:59 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 ECC126C377 for ; Mon, 8 Jan 2018 18:42:58 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-lf0-x22b.google.com with SMTP id h137so13157362lfe.8 for ; Mon, 08 Jan 2018 10:42:58 -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=0WRkVjeOxfZ7RcQwBbcTvLx2dR6N5rxTEB2Uu7T80SE=; b=egL6AECe1uhYeJkiVWjO8CbHjckudxARs38fIihEY1zr29EUAmUkwHa+ZDRtumlaN6 xf3ZJC/53HQiTP5N5jJvduNttWnl3psiY7/CBUMJMR2kHHgusFju9Q7qE1XgyZCxsIke 7PwGOW66eMItfPLXEZbtg3IOfM5vaEbTKlQRUPCUlqi9kuEM7xlLGsRWL8aN9fwoEkSz QESKNcpHkYKzyjOgDqp8wQXRB78j1AfZ+QsR9ngMaBiSp4Ksz+cUXDYUDvfuyD9Ghq1h rL/ue2SfRResZ2MeCdmobp9DGs+GU1EsDmpilJeA3uZ5bMqGyLn5nI9hClps95kFjnga TgZA== 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=0WRkVjeOxfZ7RcQwBbcTvLx2dR6N5rxTEB2Uu7T80SE=; b=CT4uXr07Hvx7CMqr6x4Sh+cmUVAe5Qvk7yykF7MQwsZT3ClABtlsbUXd4VreiuxZiG iAAjZgT+U7FNcDQhf9dw4jst8vJbto7XQrWtVUufSBmqY8UvYhrs07OfxOLmp6mFGkvF /r7TST5VLRxDcS3jzkHKTdfsuuUX2gLiaX/JjdqeND3R3aMutz2KF9STyeHnSvrTKOXo 08HK1JCTlDxPyIEF9HCZCUwQ84xb/9DK+axJcFMKqQdBXFrDlX7CDgXCLjdbYDdKA60H mjf2sB8iXz8ueVIEI6+XFz5eCormqCpjnSDkBHWEq8kSI3K6StcB6k4Xn229Wtm6DMGu LIxg== X-Gm-Message-State: AKGB3mLyrkBL1S1y/lrkAwajxJk8ssJaxmSqFpHSk86zE+uJYGSh3mGz MjpTSRWARTmAbKbdyhHDlYLnl8q+csgLIL3Y/dS5Brpo X-Google-Smtp-Source: ACJfBos9RNZfg0VzR2HJKCz8hDmbXiPxeyvnmU11StW/PQWuk5E+UJb8b8KJd6r0OO8OKHKGlvQlhT6tRvj7UotjJfM= X-Received: by 10.25.42.68 with SMTP id f65mr5887571lfl.25.1515436976358; Mon, 08 Jan 2018 10:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.163.207 with HTTP; Mon, 8 Jan 2018 10:42:54 -0800 (PST) In-Reply-To: <20180108072035.GB52442@admin.sibptus.transneft.ru> 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:42:54 -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:42:59 -0000 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 original= ly > > > to. I've seen quite a few of similar things. "Home brew" words come t= o > 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 peopl= e > > through visiting a non-encrypted website, in order to bring up our logi= n > > 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 o= f > > HTTP sites after connecting to a network. The mod_rewrite rules interce= pt > > 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 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 =E2=80=8Bnetwork setup. Our B= YOD 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=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. --=20 Freddie Cash fjwcash@gmail.com