Overrides for sites-available/inner-tunnel
This question is kind of Docker-related, but also a general question. I'm working on a project here (WIP): https://github.com/eiddor/cisco-sda-freeradius/ My goal is to include any customized files that a user would need in order to get this going. So far I've got users, clients.conf, and a sample docker-compose file. It works in general, except I figured out today that I need to change a setting in sites-available/inner-tunnel to get it to work with actual clients. (Found this fix on a ten year old mailer post :-) ). I haven't updated the repo with these findings yet. The fix is simply to change "if (0)" to "if (1)" on line #335 in the post-auth{} section. Because I'm also including instructions for users to run this in Docker, my question is: What's the best way to change this setting while keeping the repo simple and also making it easy for Docker users to implement. The way I see it, I have three options: 1) Spin-off my own Docker image with this setting changed. A heavy-lift and there's really no reason to reinvent this particular wheel for a single character change. 2) Copy sites-available/inner-tunnel out of the container, change it, and just have the user mount it as a volume (similar to clients.conf and users). This seems like the appropriate option, it just seems a bit goofy in my head to break out the full 13K file just to override a single setting. 3) Instruct the user to change the setting inside of the container itself. This isn't really an option, but I didn't want to include only two :-) Are these the only options I have or is there a way to easily override this setting from another file? If I just break out the post-auth{} section and mount it as sites-available/inner-tunnel will the other settings in the original file disappear, or are they set by default? Thanks for any input! Roddie
On Apr 13, 2021, at 12:47 PM, Roddie Hasan <roddie@krweb.net> wrote:
This question is kind of Docker-related, but also a general question.
I'm working on a project here (WIP): https://github.com/eiddor/cisco-sda-freeradius/
My goal is to include any customized files that a user would need in order to get this going. So far I've got users, clients.conf, and a sample docker-compose file.
We're also happy to take examples and add them to the default configuration.
The fix is simply to change "if (0)" to "if (1)" on line #335 in the post-auth{} section.
Because I'm also including instructions for users to run this in Docker, my question is: What's the best way to change this setting while keeping the repo simple and also making it easy for Docker users to implement.
The way I see it, I have three options:
If you can set it via an environment variable, you can do: if ($ENV{FOO}) and tell users to set FOO=0 or FOO=1 as they need.
Are these the only options I have or is there a way to easily override this setting from another file?
You can also do: if (${foo}) and then in the main radiusd.conf file, set: foo=1 or foo=0
If I just break out the post-auth{} section and mount it as sites-available/inner-tunnel will the other settings in the original file disappear, or are they set by default?
That's really a file-system question. Alan DeKok.
On Tue, Apr 13, 2021 at 12:50 PM Alan DeKok <aland@deployingradius.com> wrote:
We're also happy to take examples and add them to the default configuration.
Thanks for the reply, Alan - Once I can get this process figured out (I think I have already), we can figure out an appropriate place for them to be included. At the end of the day, it's really just a simple dot1x and RADIUS with a Cisco switch PoC, and we just happen to also be pushing a TrustSec SGT along with the VLAN. I'm honestly surprised the setting that I found this morning isn't more commonly needed.
The way I see it, I have three options:
If you can set it via an environment variable, you can do:
if ($ENV{FOO})
and tell users to set FOO=0 or FOO=1 as they need.
Oh, interesting idea. I'm not even 100% what we're testing for in this section - Maybe "use_tunneled_reply" from mods-available/eap? Also, it seems to be a completely different structure in 4.x which actually has a "use_tunneled_reply" in the inner-tunnel file. My problem is that I started with 3.x, which is the latest version on Docker Hub, so I'm going to have to redo this if/when it's upgraded and probably document both settings on my repo for those who aren't using Docker. No big deal.
Are these the only options I have or is there a way to easily override this setting from another file?
You can also do:
if (${foo})
and then in the main radiusd.conf file, set:
Another good suggestion, except that would involve breaking out radiusd.conf from the container for the user to mount, which is a similar solution to Option #2 in my OP. I kind of figured that was my only path, but I wanted to check with y'all first. Related: Are there plans or is there an appetite for an Alpine-based Docker image for FreeRADIUS 4.x? Thanks again! Roddie
On Apr 13, 2021, at 2:50 PM, Roddie Hasan <roddie@krweb.net> wrote:
Thanks for the reply, Alan - Once I can get this process figured out (I think I have already), we can figure out an appropriate place for them to be included. At the end of the day, it's really just a simple dot1x and RADIUS with a Cisco switch PoC, and we just happen to also be pushing a TrustSec SGT along with the VLAN. I'm honestly surprised the setting that I found this morning isn't more commonly needed.
It might be. But many people solve a problem, and then never tell anyone about it.
Oh, interesting idea. I'm not even 100% what we're testing for in this section - Maybe "use_tunneled_reply" from mods-available/eap?
The old "eap" module "use_tunneled_reply" configuration is fairly brute-force. It also can't be changed in "unlang". If you disable the "eap" module "use_tunneled_reply" configuration, you can enable this "unlang" section. And then have full control over what happens with the tunneled reply.
Also, it seems to be a completely different structure in 4.x which actually has a "use_tunneled_reply" in the inner-tunnel file. My problem is that I started with 3.x, which is the latest version on Docker Hub, so I'm going to have to redo this if/when it's upgraded and probably document both settings on my repo for those who aren't using Docker. No big deal.
v4 hasn't been released, so please ignore it for now.
Related: Are there plans or is there an appetite for an Alpine-based Docker image for FreeRADIUS 4.x?
No. Please don't use v4, as it hasn't been released. Please don't encourage people to use it. The configuration files and packet handling are changing on a near-daily basis. All for the better, but we're still a ways off of an alpha release of v4. The good news is that we've abstracted away all of the RADIUS stuff in the server core, and it is now fully protocol agnostic. So the core does anything. Which means a full DHCPv4 implementation is ~3500 LoC, including packet encode / decoding, DHCP protocol state machines, network IO, and configuration file parsing. And yes, if we decide to go crazy, it's now possible to add Diameter to the server. :) Alan DeKok.
be pushing a TrustSec SGT along with the VLAN. I'm honestly surprised the setting that I found this morning isn't more commonly needed.
It might be. But many people solve a problem, and then never tell anyone about it.
I'll make sure I document it well in my repo :-) I think I'm actually going to build my own Docker image with this feature enabled and then I'll document the fix for those who aren't using Docker. This way I won't have problems if the official image changes.
Oh, interesting idea. I'm not even 100% what we're testing for in this section - Maybe "use_tunneled_reply" from mods-available/eap?
The old "eap" module "use_tunneled_reply" configuration is fairly brute-force. It also can't be changed in "unlang".
If you disable the "eap" module "use_tunneled_reply" configuration, you can enable this "unlang" section. And then have full control over what happens with the tunneled reply.
Got it (I think) - Thank you!
Related: Are there plans or is there an appetite for an Alpine-based Docker image for FreeRADIUS 4.x?
No. Please don't use v4, as it hasn't been released. Please don't encourage people to use it.
Understood - I saw that 4.x was the master branch of freeradius-server, so I thought I missed something. I'll stick to documenting this for 3.x only for now.
The good news is that we've abstracted away all of the RADIUS stuff in the server core, and it is now fully protocol agnostic. So the core does anything. Which means a full DHCPv4 implementation is ~3500 LoC, including packet encode / decoding, DHCP protocol state machines, network IO, and configuration file parsing.
Oh, wow - An IPAM, too? :-) Roddie
participants (2)
-
Alan DeKok -
Roddie Hasan