Captive portal with auth from AD on the WAN side



  • Hi folks, my first post to the forums here.

    I was thinking of using PF and captive portal as authentication for the students using wireless in our school.

    [student] -> [Wireless] -> [accesspont] -> [PF+captive portal] -> [AD]

    <–------------------- LAN --------------->                      <-WAN->

    The WAN side of PF is actually the LAN side of our school network and therefore the domaincontroller with AD is here.
    I have setup PF without captive portal and everything works ok. Tried to set up captive portal according to the tutorial about
    captive portal (Radius and W2K3). When I try to open a webpage from the LAN side of PF, I´m redirected to the loginpage of
    captive portal, but I get an error when I try to login. The error is that my username or password is incorrect.
    I think that the communication between PF and AD isn´t working due to firewall rules.

    My questions is if this is doable and if it´s a good idea to do it? What should I do to make it work?

    Thanks in advance!

    /Wizzie



  • I've never done this with AD but I did this extensively with RADIUS.  There is no design reason that the auth server can't be outside. If you're concerned with firewall rules, create an allow for all traffic to/from the AD server to test.



  • We do something similar at my university.  However, for security I'd try a different approach:

    LAN - Wireless AP's
    WAN - Actual connection out through modem
    OPT1 - Internal network.

    This is what I use at this school and it works great.  Just set up a RADIUS server on any machine on the internal network and point the captive portal at it for RADIUS auth.  Setting up IAS is pretty easy, and NPS is even easier if you feel like moving to Server 2008.

    Quick note - double check your ports that you're using in IAS.  W2k3 doesn't use the same ports that pfSense does by default and that messed me up for a bit on my first setup.

    Combine it with decent traffic shaping and consider Snort to fulfill your "we tried to stop them" legal requirements for p2p prevention.


Log in to reply