The Long Road to RADIUS Configuration of Firewalls

UPDATE: 5/13/2014

I found a feature/design flaw/bug/workaround in how the firewall identifies itself to the RADIUS server.

RADIUS server receives 3 IP addresses from the RADIUS client

  1. RAS IP: IP of the firewall interface that is making the request to the RADIUS server
  2. NAS IP: Alias IP of the firewall generally used for RADIUS accounting
  3. CLIENT IP: of the remote desktop client trying to SSH or WEBUI to the firewall



Problem: Seems that some RADIUS servers use the NAS-IP to do their database lookup for AV pairs, instead of the RAS IP. More specifically RADIUS uses the RAS IP for secret key lookup and NAS IP for AV pairs. Go figure.

The NAS IP is set in your /etc/hosts file for the localhost and the local host DNS name. You can also set this in your WEBUI


Its fixed in R77.10 a bit:



UPDATE: 2/18/2014

I spoke with the developers on this and got more info:

  1. R77 (I am at R75.47) you can specify a default shell of /bin/bash instead of /bin/clish and then EVERYONE who is RADIUS authenticated will go into /bin/bash and not clish. So this is what SPLAT had which is nice we are finally back to where we started.
  2. I asked the developer to consider adding another Radius Attribute GAIA-user-shell, where in RADIUS you can set the shell to /bin/bash or /bin/clish for that user. He thought it was a good idea and would consider it.
  3. gaia-superuser-access attribute RADIUS attribute is used to assign a Unix UID of 0 for superuser or 96 for regular user. I haven’t seen this documented anywhere and haven’t tried it to verify.
  4. Note: The role ‘radius-group-any’ gets assigned to EVERY user by default. So if a user has a role ‘guionlyRole’, the user will get the guidonlyRole features as well as the features from ‘radius-group-any’. I haven’t see this documented anywhere.
  5. Make sure you have
    hotfix HOTFIX_FOXX_HF_HA46_074
    as well as these. They are for the super user setting UID to 0:For pam rpm, command is a little different. Do:
    rpm -Uvh –force –noscripts pam-
    For CPshell, normal command:
    rpm -Uvh –force CPshell-1-986008001.i386.rpm

UPDATE:  02/5/2014
I got some of it to work on R75.46 with hotfix HOTFIX_FOXX_HF_HA46_074

I setup my own FreeRadius server (it was easy) and customized it according to sk72940 and it looks like it works.


  1. All users defined on RADIUS server. (Trying to get this to proxy to AD will be next step).
  2. Here is the RADIUS dictionary and the user definition for user ‘radius1’.usersfile
  3. No users defined locally on GAIA
  4. So now I SSH onto system and you can see the attributes being passed back to GAIA
    radius debug
  5. Now I log into expert mode and check out my security context. SuperUser!
  6. Here is the /var/log/messages file should look like:
  7. Network sniff should look like thisadminrole2
  8. FYI: I can’t seem to get CP_Gaia-SuperUser-Access=0 to do anything. I can’t log in with it.
    I can modify the CP-Gaia-user-Role and it will change the role for the user. For example,
    I can change CP-Gaia-user-Role=monitorRole and user will have read-only access and
    cannot! execute the expert command.

I just wish we could go directly into Unix mode and not have to use the expert password. Why? If someone quits we still have to change the expert password on 1000000000 of firewalls. SO how about this?

If you add a the user to GAIA as UID 0:


and set the shell to bash




and then make ‘radiusroot’ to exist in your AD/RADIUS server, …abra cadabra…. you are notw AD authenticated into /bin/bash! Unfortunately this means you have to add bash users to all 1000000 firewalls you own.

Oh well, beggers can’t be choosers I guess.

I’ll let you know if I can get AD proxy going. Stay tuned!

Get your RADIUS on!


UPDATE: 10/23/2013

Last I heard is there is a fix to give RADIUS users either bash or clish, but not both. Haven’t tried it.

The Fix.

UPDATE: 4/21/2013

So spoke with someone in the know and got same info:
There is no way they know of to RADIUS authenticate into expert mode. They claim R&D is going to fix it, but our person rolled their eyes.
So the status is RADIUS users can now execute tcpdump. So you can build a ‘netdebug’ group in GAIA and give them limited access.
But for the superadmins, you still either have to:
   1) Create each person individually on the firewall UID 0 and then RADIUS auth them into /bin/bash
   2) Create a generic account UID 0 on each firewall and then RADIUS auth them into /bin/bash
Hope this saves you some work,


3/29/2013: Word from R&D is that Radius authenticated users cannot be assigned UID 0, so they will not be able to execute commands like tcpdump. This is a design decision.  My opinion is this is a bad bad bad decision. It goes backwards from SPLAT. You can’t globally manage a disparate set of administrators.

They have updated the RADIUS groups to allow RADIUS attributes so you can have more than 1 security group, but in the end you still have to hand out the expert password to get UID 0 access. How lame is that?  Obviously R&D never tried changing expert passwords on 500 firewalls when an admin leaves.

UPDATE:: 1/21/2013: Ask and you shall receive:

BUT: still have to specify virtual systems assigned to role.


In large environments were many administrators have CLI access, GAIA was designed to provide a fine grain level of control over those users with ‘roles’.  GAIA was like the uber-cpshell. You could have 1 group be superusers, 1 group be run-backups admins, 1 group be tcpdump type admins, 1 group be, etc.

Unless you use RADIUS.

If non-local users are RADIUS authenticated, then they are put into one GAIA role ‘radius-group-any’. Now you can custom design what this group does. For example:

add rba role radius-group-any domain-type System readonly-features arp, ext_ping ,ext_traceroute

So this group only does arp, ping, traceroute

BUT, now there is only ONE RADIUS group that can only do ONE set of things.

Hopefully! this will be fixed soon. I’m trying to figure out how to get around this.

Unfortunately it only gets better under VSX.

When you create a role, you can assign the VSs that it can operate in (which is undocumented)

add rba role  ROLENAME virtual-system-access 0,1,2,3,4,5,………………

Well, seems OK unless you have 250 VSs on several clusters and have several different roles. Can you say exponential problem?

You cannot say

add rba role  ROLENAME virtual-system-access all

which is what the adminrole is:

domain-type applies to all domains
virtual-system access: all

No, you have to go through and add each VS to each role one at a time……UGH. Another RFE.

add rba role  ROLENAME virtual-system-access 0,1,2,3,4,5,6,7,8,9…………


Peace Out


Post a comment or leave a trackback: Trackback URL.


  • Arska  On November 22, 2012 at 7:28 pm

    You can create as many RADIUS groups as you want. Make RADIUS server to reply your custom group name

  • dreezman  On November 23, 2012 at 9:09 pm

    I will check it out but I think groups are just for local users. THanks for showing interest, will let you know.

  • dreezman  On November 27, 2012 at 11:00 pm

    OK. Just got a confirm from upper support that this is in fact broken. Only 1 RADIUS group, radius-group-any.

    If anyone can prove different I’m all ears.

  • Alex  On June 4, 2015 at 6:02 pm

    Hello friend´s

    I´m trying to setup Radius authentication through a Windows NPS Server and a 70.40 checkpoint firewall. It´s not working, I´m seeing the logs on tcpdump and says a kind of access accepted, but the login through https is not working. Any idea about how to troubleshoot? Plase, feel free to request as much information as needed, any comment or documentation will be appreciated.

    Best Regards!

  • Benjamin  On October 15, 2015 at 8:23 am

    Michael, have you found any way to get the Calling-Station-ID attribute from other types of logins? I can only get the attribute from SSH access, not from SmartDashboard or any of the VPN clients :-/

    • Dreezman  On October 16, 2015 at 7:30 am

      What do you mean by ‘get’? How do you ‘get’ the Calling-Station-ID’.

      • Benjamin  On October 16, 2015 at 8:49 am

        ‘get’ might not have been the best expression 🙂 What I mean to say was: Is there a way to include the Calling-Station-ID attribute in ACCESS-REQUEST packets sent from the firewall, when a user logs on using a VPN client.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Helen's Loom

"Peculiar travel suggestions are dancing lessons from God." - Kurt Vonnegut

Life Stories from Dreez

These are stories from my travels. Generally I like to write stories about local people that I meet and also brag about living the retirement dream with my #1 wife Gaby. She is also my only wife.

%d bloggers like this: