So, to clarify; the Astaro does not perform the RADIUS authentication; it merely allows the AP, or the Client, to access RADIUS? I saw a bunch of RADIUS traffic trying to go through while trying to authentication a client (it still doesn't work for me), so I added packet filters... still no go. I tried one of the other tester's examples, still no dice. Does Astaro have an official (or unofficial) how-to on getting RADIUS authentication, with WPA-2 Enterprise authentication, to work with this? I must be missing something, but for the life of me, I don't know what.
Yes, neither the ASG nor the AP perform RADIUS authentication as every other AP as well. That's the job of an authentication server. The AP itself only relays frames from the wireless clients to the RADIUS server as the wireless client is not yet authorized to access the according network.
The AP firmware previously had a bug that refused EAP authentication on bridge-to-LAN wifi networks. That's fixed in 7.507+.
Bruce and Helmut, I don't have an Astaro WAP. I agree that it sounds like a bug, but I thought it might be an experiment worth making to see if RADIUS auth worked if a RADIUS server were placed ahead of the AD server in 'Users >> Authentication'.
I'm guessing you could see the authentication in the User Auth Daemon live log and that it's related to the bug that RADIUS authorization fails for L2TP if the AD server is ahead of the RADIUS server.
Cheers - Bob
Sophos UTM Community Moderator Sophos Certified Architect - UTM Sophos Certified Engineer - XG Gold Solution Partner since 2005
So, Helmut, do I need to define any packet filters for RADIUS access for the APs or connected clients? I saw a bunch of drops for the RADIUS port when I tried this -- so I added some packet filters to take care of it. I did try following the steps in that other thread, it didn't work.
Yes, neither the ASG nor the AP perform RADIUS authentication as every other AP as well. That's the job of an authentication server. The AP itself only relays frames from the wireless clients to the RADIUS server as the wireless client is not yet authorized to access the according network.
The AP firmware previously had a bug that refused EAP authentication on bridge-to-LAN wifi networks. That's fixed in 7.507+.
Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries. Use the advice given at your own risk.
So, Helmut, do I need to define any packet filters for RADIUS access for the APs or connected clients? I saw a bunch of drops for the RADIUS port when I tried this -- so I added some packet filters to take care of it.
Basically, no, the ASG should automatically create a masquerading rule for that. At least the fact that you see a few drops might indicate a problem somewhere in that corner. Maybe something messed it up?
To be a bit more precise, the AP will send the RADIUS requests directly to the ASG which in turn masquerades them to the RADIUS server.
Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries. Use the advice given at your own risk.
Can you please tell us more about your network setup? Small ascii art graphs and IP addresses would help, too.
Basically, it works like this: the ASG creates a DNAT rule which applies on traffic that comes in via an interface specified in the "allowed interfaces" box with the port used for AP->ASG radius traffic and transforms this into the destination address/port which you specified in the Radius configuration dialogue in Wireless Security->Global Settings->Advanced. Additionally, there is a filter rule in place which allows this traffic to be forwarded. To make the return way work as well, those packets are then masqueraded when leaving the ASG.
The reason for this is that APs don't need to be able to speak with the Radius directly, it is sufficient if the AP can contact the ASG, and the ASG can contact the radius server. Additionally we're able to extend this architecture and improve integration into the ASG authentication backend somewhere in the future.
