Greetings, I am having troubles wrapping my hear around the unlang concepts to make this work. Situation: My company just merged with another that is also using freeradius, though they are using 2.x instead of 3.x. We were in the process of upgrading ours to 3.x when this merger was announced internally. I am tasked with merging the radius system. Here is what I need. In proxy.conf we have 4 needed realms, each using a different virtual_server. I have the following: realm company1.org { virtual_server = company1 } realm company2.net { virtual_server = company2 } realm company3.net { virtual_server = accept } realm company4.com { virtual_server = reject } realm NULL { virtual_server = company1 } realm DEFAULT { virtual_server = default ##duplicate of company1's file for now. } I have each of the virtual servers listening on different ports and only listing on ip 127.0.0.1. Examples: company1: 9990,9991, company2: 9992,9993, etc The main server listens to ports 1812,1813. I need the accept virtual_server to accept anything sent to it. I need the reject virtual_server to reject all sent to it. company1 has realm and non-realm users, using Stripped-User-Name for final lookup to the database. Company2 always has the realm on it, and can be configured to use stripped or non-stripped usernames when going to the database. So far company1 and company2 work, but when I add company3 and company4, things start working very strangely. When I use radtest to query the server for company3 I get a result: (0) Expected Access-Accept got Access-Reject I am assuming I have my server config messed up, but I won't count on that being the issue. Any help would be appreciated. My accept and reject virtual servers are pretty basic and are almost identical. Below is my accept server config: # server accept { listen { type = auth ipaddr = * port = 9992 limit { max_connections = 16 lifetime = 0 idle_timeout = 120 } } listen { ipaddr = * port = 9993 type = acct limit { } } authorize { update control { &Auth-Type := Accept } } authenticate { Auth-Type CHAP { chap } } preacct { preprocess acct_unique suffix files } accoutning { detail unix -sql if (noop) { ok } attr_fileter.account_response } session { } post_auth { replay_log -sql Post-Auth-Type REJECT { -sql attr_filter.access_reject } } pre-proxy { } post-proxy { eap } }
On Jan 29, 2016, at 12:36 PM, azander <azander@netonecom.net> wrote:
I am having troubles wrapping my hear around the unlang concepts to make this work.
Sometimes the solution can be found by taking a step back and re-writing the requirements. Unlang itself is pretty simple. If / then / else checks on packets. If you can write requirements in English, they can generally be implemented in unlang.
In proxy.conf we have 4 needed realms, each using a different virtual_server. I have the following:
That's a solution. It's not a requirement. If the solution is hard to understand, there's likely another solution which meets the high level requirements.
I have each of the virtual servers listening on different ports and only listing on ip 127.0.0.1. Examples: company1: 9990,9991, company2: 9992,9993, etc
Again, that's a solution, not a requirement.
I need the accept virtual_server to accept anything sent to it. I need the reject virtual_server to reject all sent to it.
You don't need virtual servers for that. You can just accept or reject requests in a virtual server i.e. your solution is much more complex than it needs to be.
company1 has realm and non-realm users, using Stripped-User-Name for final lookup to the database. Company2 always has the realm on it, and can be configured to use stripped or non-stripped usernames when going to the database.
"Can be configured" ? What does that mean? Again, these aren't requirements.
So far company1 and company2 work, but when I add company3 and company4, things start working very strangely.
Probably because the rules you've written are imprecise, and too broad. The rules are too broad because you don't have a clear set of requirements.
When I use radtest to query the server for company3 I get a result: (0) Expected Access-Accept got Access-Reject\
That is unfortunately useless. The FAQ, "man" pages, web pages, and daily messages on this list say to run the server in debug mode. *Nothing* says to post the client output, or the configuration files. Please follow instructions.
I am assuming I have my server config messed up, but I won't count on that being the issue. Any help would be appreciated.
Your server configuration is broken. Because you don't have a clear set of requirements. i.e. you don't know what you want the server to do, so you haven't configured it to do anything useful. Start from scratch with the default configuration. Then, write down your requirements for one company: - if packet comes in - here's how to tell it's for company 1 - and only company 1 - we should re-write attribute X from A to B - we should look up D, E, and F in the database using attributes X, Y, and Z - we should return P, Q, and R in the response Then... implement that. Piece by piece. Test it at every step. Read "man radiusd" for instructions. There are a lot of things to do, but it's not complicated. Just write down the requirements, write down what you have (attributes, DB, etc.), and write down what you want it to do. Then, implement it and test it. Alan DeKok.
With these typos I'm surprised it works at all accoutning { ^^^^ detail unix -sql if (noop) { ok } attr_fileter.account_response ^^^^^ As Alan says . Define your logic on paper. Write a flow chart. Then implement. alan
participants (3)
-
Alan Buxey -
Alan DeKok -
azander