This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WPA2 Enterprise with FreeRADIUS

I have successfully configured FreeRADIUS to work with SophosUTM and was able to successfully authenticate users. Unfortunately, my setup have multiple SSID and I need certain users to be restricted from connecting to SSID's they are not authorize. I also noticed from the FreeRADIUS log that the UTM passes the SSID to FreeRADIUS as a NAS-Identifier attribute. I was hoping that someone can point me to the right direction on how to go about this and deny certain users connecting to certain SSID's.


This thread was automatically locked due to age.
  • Jet, I think your question needs to be on a FreeRADIUS BB.  There's no way for the UTM to deny someone unless RADIUS denies them.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I was actually hoping that someone else from the forum implemented a similar setup and could give me some tips how they go about with it
  • I think that only the hostname of the client that wants to connect to the wifi network is send to the radius server and not the logged in username. So i guess you can restrict the workstations that can connect but not the user.

    There is a kb entrie how to use a windows-radius server, maybe there are some useful hints too.

    Regards
    Manfred
  • BAlfson said:
    Jet, I think your question needs to be on a FreeRADIUS BB.

    Bob - I totally get where you are coming from with your encouragement to post the question in another BB. I politely disagree that a discussion here is of little value. This is a good place for such a question it has as much to do with Sophos as it does radius (speaking generically). 

    BAlfson said:
    There's no way for the UTM to deny someone unless RADIUS denies them.

    Not true. I've configured (today) the same setup in the lab and indeed you can have radius auth but still get a failed connection.  Testing locally on radius results in a successful authentication, using the test feature within the radius server object on the UTM also passes, but bombs somewhere else when making an actual wifi connection. And for this reason, and the others below I think the topic is useful. 

    The problem is that it is not very well documented by Sophos what attributes and reply items are expected and optional in Sophos (both SG and XG). You can follow the cookbook provided in the KB if you're in an AD environment (and it works perfectly), but the guide doesn't shed much light on the interaction with the radius service, which doesn't give much help to those wishing to use a non-AD radius server. Sophos should at least document the check and reply items the UTM requires and optionally supports.

    Just for background, I got interested because XG supports a way to assign a vlan to a wifi client connection dynamically but so far I can't find what combination of check/reply items are needed to make it work. So I thought it would make for a good blog post once I found the solution.

    As a side note, I still think that Sophos SHOULD implement the some glue between local users & WPA2 Enterprise authentication, so I wouldn't have to muck with this. That's my opinion. :)

  • "Testing locally on radius results in a successful authentication, using the test feature within the radius server object on the UTM also passes, but bombs somewhere else when making an actual wifi connection. And for this reason, and the others below I think the topic is useful."

    Is RADIUS for WiFi configured in 'Enterprise Authentication' on the 'Advanced' tab of 'Wireless Protection >> Global settings'?

    In fact, that may have contributed to Jet's problem also.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA