No Response from Radius Server - FreeRadius3 on pfSense
-
Let me give some background on what I am doing so the right context of assistance can be provided.
We have Cisco Meraki Cloud Controller and APs that manage our corporate WIFI. Meraki has its own authentication that allow you to create users to log into the WIFI but how you can configure the users is very limited. You can either limit them to one device or an infinite amount and there is no way to cap the bandwidth of individual users.
One of the options available for authentication is a radius server and from what I understand, radius provides more flexibility in how you configure the users. So I want to use Radius to authenticate users on my Meraki infrastructure. Meraki has its own splash page so I do not think I need a captive portal, just the users authenticated and given access with whatever parameters that is set.
I have a pfSense set up running at the moment that interfaces with the Meraki APs and it is working perfect.
I tried to configure FreeRadius3 on the pfSense but there are some concepts that remain unclear from my research and troubleshooting and I am hoping someone can assist.
So I installed freeradius3 on my pfSense. Then I went to the Services->FreeRadius->Interfaces and configured the Interface IP address for ports 1812, 1813 and 1816 for auth, acct and status respectively. This is my first confusion, the INterface IP, some tutorials/videos online said to leave it as * (for all interfaces) and others user 127.0.0.1 but in all cases they were testing locally within the same private network. FOr my situation, Meraki will be trying to authenticate with my radius server over the internet. So I am unclear what address should I be using in that scenario.
Anyhow, I configured the Authentication Server for Radius, the NAS/client and a user, went to Diagnostics->Authentication and tested and it was successful. for the NAS, I added 127.0.0.1 and that worked.
The issue is when I enter the details on MEraki and test, I am getting no response from server. I found a utility online that can test Radius but when I try testing over the internet using my WAN IP address as well as locally using the LAN IP address of one of my vlan interfaces, I also get no response from server.
So within pfSense its authenticating but outside it is not getting to the server. I tried port forwarding port 1812 but same issue. I believe my issue is the IP address for the Radius server but in this particular set up, my pfSense is internet facing, so I do not understand why there is no response from the server.
I may be tired and just need to take a break but I just need guidance as to which IP is the IP for the radius server when radius is on pfSense.
My alternative is to configure radius in a Windows Server or some other set up, so it is not on pfSense but I do not really want to have to configure a whole new machine/server, I would like to get this working with pfSense over the internet.
I was thinking that my internet from the ISP was being double NATTed and maybe I was unable to reach my pfSense from the internet but on the machine I was testing on, I installed xampp and set up a quick web server and then port forwarded port 80 to my test machine on pfSense and was able to load a web page from over the internet. So I can communicate with pfSense via port 80 but not via Radius so I believe it is how I have radius configured.
Can anyone help?
-
Ok so localhost (127.0.0.1) is only going to be available from the local host as you found. If you need access externally those will have to be the WAN IP. Or alternatively you could setup port forwards on WAN to 127.0.0.1 for those ports required.
How many clients do you have connecting to this? The limitations of the Freeradius package in pfSense can become all too obvious if you are trying to manage a large numer of clients. It would be better to use a dedicated authentication server for that if so.Steve
-
@stephenw10 thanks for responding.
well we have 34 Meraki APs and I entered all of them painstakenly in the Nas/client page but it seems that the way Meraki works is that you just need the IP of the Meraki Controller because according to the logs when I finally got the radius authentication to work, all the requests were coming from the controller IP and not any of the IPs of the APs.
So I finally figured out that you have to be very specific on the Nas/client page to get a response from the radius server. So I was able to connect and log in with a radius user via the Meraki.
However, after I got it working and started testing the user accounts, I then found out that the flexibility I really want from having radius (that is, controlling the number of devices one user can log into) comes from using a captive portal and not just from the radius user accounts themselves. So I tried configuring captive portal and after getting it to work, I realise that from a machine on the same internal network, the captive portal log in page loaded. But when I connect wirelessly via a Meraki AP, I cannot get the captive portal page to load.
All the tutorials tell me to place the captive portal on the internal lan interface and not the wan interface. When it is on the lan interface, the captive portal is trying to load the internal IP of the lan, which obviously over the internet is inaccessable. When I put the captive portal on the wan, it loads the internet and bypasses the log in page altogether.
But there are so many points of failure to consider. There is the interface IPs, you have to configure on the interfaces page for each of the radius ports, there is the interface you have to select for the radius server for the authentication server in the user manager page in the system menu, there is the interface,on the captive portal page and there is another somewhere I can't recall, but I am certain there are 4 in total but 3 for certain within pfsense alone. Then there is what ip I use on the Meraki splash page settings to direct it to the captive portal log in. Trying the wan IP:8002 of pfsense don't work, it still tried to load the lan ip:8002.
I figure I have to use the wan ip, but with so many places where you have to select an interface to use, it is really unclear where exactly. Unless I use the wan ip in all places.
Can you be more specific in your suggestion?
Also, if I do not use freeradius in pfsense, which external server would you recommend?
-
Why are you putting the captive portal on WAN? Are the access points not behind the firewall on LAN?
A diagram may be needed here.
Steve
-
@stephenw10 I would have to update our diagram.
Basically no the APs are not on the lan of my pfsense VM.
Originally we had 3 internet links. So we bought a Cisco Asa firewall with 6 interfaces during our technological upgrades back in 2014/2015. We use each Internet link on 3 separate outside interfaces and the other 3 interfaces were used as inside interfaces. 1 internet link on 1st interface is for our corporate network and that routes to our corporate inside interface (4th interface) with is the subinterfaced with 5 vlans etc for our corporate needs. The 2nd internet link is on our 2nd inteface for our general WiFi used for events (we are a conference center and provide internet to clients for corporate events), that is routed to our 5th interface which is subinterfaced with 5 vlans (one of which is the vlan of our Meraki APs). The 3rd internet link on the 3rd interface is for our bandwidth of demand which is provided to clients who want to stream online. This is a DIA service which is routed to the 6th and final interface of our firewall for services on that interface.
Subsequent to the above setup our ISP provided us with 2 additional high speed internet links, but with all of our interfaces currently in use on the Cisco firewall we could not route it through the firewall unless we placed a switch in front of the firewall to handle the additional connections and then send one link into the 2nd interface. Basically 3 links in and 1 out and that into a firewall interface. But then this would mean making changes to our firewall. I am a fan of if it ain't broke don't mess with it. Our set up works seamlessly at the moment. Maybe if we had the 5 links when we were upgrading we would have implemented a solution that handles 5 links or a set up that allows us to add as many isp links as we need etc. Hindsight is always 20/20. At the time we 3 internet links were not common so who would imagine we would be at 5.
Anyhow, initially we were only using the High speed internet links for wired connections only. But then we had a client who wanted the high speed but needed WiFi. Normally we would have used a wired network and place separate APs and provisioned them in the room the client was using but 2 things happened. 1) the room the client was in was large and we needed better coverage and 2) for some reason the 2 APs we normally used would not work. Anyhow we needed to get the WiFi for the high speed link on the Meraki AP while still bypassing our firewall.
So i purchased a Soho router and placed on one of the high speed internet in the wan port, configured DHCP and then I created separate vlan on the Cisco switch and since the Meraki APs were patched to trunk ports all I had to do was point the wifi ssid on the cloud controller to that vlan and when I tested, it worked we had the merakis APs on our high speed internet.
But then we had another client with a large event and I needed to supernet class C to cidr/22 to get 1022 IPs, but for some reason the Soho was not capable of anything but cidr/24. So this lead me to using untangle on a hyperv vm to get the amount of IPs I needed. This worked.
Then I needed to configure vlans on the high speed internet as I needed to put 2 clients on the link at the same time and I wanted to used bandwidth capping as 1 client was to get different speeds that the other. Untangle was not suitable. So I switched to a pfsense vm, created the vlans, and using limiters at the moment. This worked.
Now I need more capabilities than the Meraki authentication and captive portal seems to be the solution. That's where I am now.
So hopefully I have explained everything clearly but basically, the APs are behind one of our lan interfaces on our Cisco firewall, but the pfsense is acting as the internet facing firewall for our high speed internet links that do not go through our Cisco firewall. But they all converge on the same Cisco manage switches that have the vlans defined and all APs are on trunk ports on all switches throughout the building. Switches are physically connected to each other via fiber.
I can't update the drawing at the moment, but I hope my set up is clearer?
So this is where I am at now. The radius authentication works. I can connect to WiFi on a Meraki AP using a radius user. But the captive portal log in only works when accessing from a device behind my pfsense lan.
But clients will be accessing via our Meraki APs which use the Meraki Controller's public IP to authenticate users. So the captive portal seems to need accessing from over the internet. I configured the local lan ip of all 34 of our Meraki APs in the Nas/clients page but the Meraki controller public IP seems to be the only client being used to authenticate and not the APs themselves.
Any thoughts?
-
Hmm, Ok. So it sounds like the APs are in fact behind pfSense. Traffic from clients on wifi goes through pfSense and out on one of the new high speed WAN connections you have and not through the Cisco firewall.
If doesn't really matter what path the authentication takes the captive portal doesn't manage that it manages traffic from the clients to the internet. It should be on whatever internal interface the APs are connected to. You will have to add pass rules to allow the APs to reach the cloud controller though.
It also sounds like you don't want authentication on the APs at all. Clients have to login at the captive portal anyway.
It does look like the Meraki APs support radius accounting so you could probably do limited connection time per user there directly but if you need to set bandwidth limits per user or use total data limits I think you would need to use a captive portal.
This is not something that we often see though.
Steve