Proxy CoA packet from network control to NAS(same as CoA server) configs in case of many many NASes.
Hello, Freeradius team and users community! First of all thanks to all creators of FreeRadius! It makes a lot of people happy ) I use FreeRadius 3.0.9 builded from a source on CentOS 6. Everything is fine. But I still can't find some details in documentation. So I need short comments to clarify. My pain. I have about 800 NASes in our network and all of them is home servers (CoA servers) (no redundancy due to small areas for each NAS). I do proxy CoA from my network control server (CoA client) to NASes that same time are CoA servers (Cisco WLCs) and configuration below works with small trick but as I expected. I named my home server pools same name as "IP" address and it helps me to avoid additional operations, it's good anyway. My question is if I have any chances to simplify configuration and avoid to write 800 home servers and home server pools (each pool still one server unfortunately)? I understand that templates technique may simplify home server sections little bit, but I still need 800 home servers and 800 home server pools? :( I've tried to use clients.conf and derive home servers from that section as announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry). As I understand that NAS and CoA server can be same in case I add section in clients.conf.. If it possible to identify this CoA server somehow and send proxy packet to exact server (in my case IP same as NAS IP) it would be nice? 1. Could you please tell me if there is a way to send proxy packet to such unnamed home server (derived from clients) based on IP of my NAS? I've tried to use Packet-DST-IP-Address = "%{NAS-IP-Address}" together with Packet-Dst-Port = 1700 or without it, but seems it doesn't work. Freeradius in debug writes random port number and message like "home server 10.56.33.174 doesn't exists". Later I read in docs that I can't add name to such unnamed home servers so I can't use such home servers in combination with pools (for example) and than use Home-Server-Pool := "%{NAS-IP-Address}"... 2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server? Have I missed some important part? Sorry in advance if it is awkward moment. Thank you in advance for your help! Best Regards, Sergey Komaroff How it works now: ---sites enabled/сoa--------------------------------- server coa { recv-coa { suffix update control { # It works: Home-Server-Pool := "%{NAS-IP-Address}" # Tested to switch to this but it makes error home server X.X.X.X not found when home server derived from clients.conf # Packet-DST-IP-Address = "%{NAS-IP-Address}" # Packet-DST-Port = 1700 } # Insert your own policies here. ok } send-coa { # Sample module. ok } } ------------------------ clients.conf --------- client wlc_1 { ipaddr = 10.56.33.174 secret = secret nas_type = cisco coa_server = wlc1 } client wlc_2 { ipaddr = 10.56.33.190 secret = secret nas_type = cisco coa_server = wlc2 } client wlc_3 { ipaddr = 10.0.249.253 secret = secret nas_type = cisco coa_server = wlc3 } ...... ----------------proxy.conf------------------------ home_server wlc1 { type = coa ipaddr = 10.56.33.174 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server wlc2 { type = coa ipaddr = 10.0.249.253 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server wlc3 { type = coa ipaddr = 10.56.33.190 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } ..... home_server_pool 10.56.33.174 { home_server = wlc1 } home_server_pool 10.0.249.253 { home_server = wlc2 } home_server_pool 10.56.33.190 { home_server = wlc3 } ..... -----------------------------------------------------------------------------------
On Jul 16, 2015, at 4:19 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I've tried to use clients.conf and derive home servers from that section as announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry).
Just do: update control { Packet-Dst-IP-Address := 192.0.2.4 } which is the IP of the NAS.
2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server?
Yes. update control { Packet-Dst-IP-Address := &NAS-IP-Address } Alan DeKok.
Hello Alan and colleagues, Yes, I've tried to do so. In case I write as you said I get: Waking up in 0.4 seconds. (22) Received CoA-Request Id 187 from 10.1.1.1:17809 to 10.1.1.174:3799 length 113 (22) User-Name = "78-6c-1c-94-d2-07" (22) Calling-Station-Id = "78-6c-1c-94-d2-07" (22) Cisco-AVPair = "subscriber:command=account-reauthenticate" (22) NAS-IP-Address = 10.56.33.190 (22) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (22) recv-coa { (22) [suffix] = noop (22) update control { (22) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.190 (22) Packet-Dst-Port := 1700 (22) } # update control = noop (22) [ok] = ok (22) } # recv-coa = ok *No such home server 10.56.33.190 port 14346* (22) Not sending reply to client. (22) Finished request (22) <done>: Cleaning up request packet ID 187 with timestamp +5 Waking up in 0.2 seconds. In case I add also port (Packet-Dst-Port := 1700) I get this: Waking up in 2.9 seconds. (13) Received CoA-Request Id 198 from 10.1.1.1:11374 to 10.1.1.174:3799 length 113 (13) User-Name = "60-d9-c7-32-4f-02" (13) Calling-Station-Id = "60-d9-c7-32-4f-02" (13) Cisco-AVPair = "subscriber:command=account-reauthenticate" (13) NAS-IP-Address = 10.56.33.174 (13) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (13) recv-coa { (13) [suffix] = noop (13) update control { (13) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.174 (13) Packet-Dst-Port := 1700 (13) } # update control = noop (13) [ok] = ok (13) } # recv-coa = ok *No such home server 10.56.33.174 port 14346* (13) Not sending reply to client. (13) Finished request (13) <done>: Cleaning up request packet ID 198 with timestamp +2 Waking up in 2.8 seconds. Thank you in advance for your comments! Best Regards, Sergey Komaroff On Thu, Jul 16, 2015 at 3:01 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 16, 2015, at 4:19 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I've tried to use clients.conf and derive home servers from that section
as
announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry).
Just do:
update control { Packet-Dst-IP-Address := 192.0.2.4 }
which is the IP of the NAS.
2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server?
Yes.
update control { Packet-Dst-IP-Address := &NAS-IP-Address }
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry for debug quotes, for the first case a little bit different error (port is original here, but coa home server has port 1700 at proxy.conf): Waking up in 0.2 seconds. (65) Received CoA-Request Id 238 from 10.1.1.2:24820 to 10.1.1.174:3799 length 113 (65) User-Name = "bc-92-6b-20-16-66" (65) Calling-Station-Id = "bc-92-6b-20-16-66" (65) Cisco-AVPair = "subscriber:command=account-reauthenticate" (65) NAS-IP-Address = 10.16.35.46 (65) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (65) recv-coa { (65) [suffix] = noop (65) update control { (65) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.16.35.46 (65) } # update control = noop (65) [ok] = ok (65) } # recv-coa = ok No such home server 10.16.35.46 port 3799 (65) Not sending reply to client. (65) Finished request So it looks like server can't find such home server in case if it search it by IP address not by home server pool name... pool name works ok. Best Regards, Sergey Komaroff On Thu, Jul 16, 2015 at 4:14 PM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Hello Alan and colleagues,
Yes, I've tried to do so. In case I write as you said I get:
Waking up in 0.4 seconds. (22) Received CoA-Request Id 187 from 10.1.1.1:17809 to 10.1.1.174:3799 length 113 (22) User-Name = "78-6c-1c-94-d2-07" (22) Calling-Station-Id = "78-6c-1c-94-d2-07" (22) Cisco-AVPair = "subscriber:command=account-reauthenticate" (22) NAS-IP-Address = 10.56.33.190 (22) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (22) recv-coa { (22) [suffix] = noop (22) update control { (22) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.190 (22) Packet-Dst-Port := 1700 (22) } # update control = noop (22) [ok] = ok (22) } # recv-coa = ok *No such home server 10.56.33.190 port 14346* (22) Not sending reply to client. (22) Finished request (22) <done>: Cleaning up request packet ID 187 with timestamp +5 Waking up in 0.2 seconds.
In case I add also port (Packet-Dst-Port := 1700) I get this:
Waking up in 2.9 seconds. (13) Received CoA-Request Id 198 from 10.1.1.1:11374 to 10.1.1.174:3799 length 113 (13) User-Name = "60-d9-c7-32-4f-02" (13) Calling-Station-Id = "60-d9-c7-32-4f-02" (13) Cisco-AVPair = "subscriber:command=account-reauthenticate" (13) NAS-IP-Address = 10.56.33.174 (13) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (13) recv-coa { (13) [suffix] = noop (13) update control { (13) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.174 (13) Packet-Dst-Port := 1700 (13) } # update control = noop (13) [ok] = ok (13) } # recv-coa = ok *No such home server 10.56.33.174 port 14346* (13) Not sending reply to client. (13) Finished request (13) <done>: Cleaning up request packet ID 198 with timestamp +2 Waking up in 2.8 seconds.
Thank you in advance for your comments!
Best Regards, Sergey Komaroff
On Thu, Jul 16, 2015 at 3:01 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 16, 2015, at 4:19 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I've tried to use clients.conf and derive home servers from that
section as
announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry).
Just do:
update control { Packet-Dst-IP-Address := 192.0.2.4 }
which is the IP of the NAS.
2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server?
Yes.
update control { Packet-Dst-IP-Address := &NAS-IP-Address }
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 16, 2015, at 4:19 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I've tried to use clients.conf and derive home servers from that section
as
announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry).
Just do:
update control { Packet-Dst-IP-Address := 192.0.2.4 }
which is the IP of the NAS.
2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server?
Yes.
update control { Packet-Dst-IP-Address := &NAS-IP-Address }
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
The problem is that the architecture of the server currently demands a home server instance be constructed for each and every NAS receiving CoAs, and AFAICT there's no way to build these dynamically based on arbitrary IPs encountered at runtime. We sidestepped it and just shell out to a script to use radclient to send them. As long as you don't have a giant volume of CoA traffic and can easily figure out secrets for any given NAS from its IP address, that might be your best option. e.g. to send one out when you see a special access-accept from a home server one would: exec punchdhcp { wait = no input_pairs = request program = "/etc/raddb/punchdhcp.sh %{request:NAS-IP-Address}' '%{control:NAS-Identifier}' '%{control:Calling-Station-Id}'" packet_type = Access-Accept } ...then call the punchdhcp in unlang at the appropriate time... ...Then the script would have something like: #!/bin/sh echo "Calling-Station-Id := $3 Aruba-Port-Bounce-Host := 5" | /bin/radclient $1:3799 disconnect -i $(($RANDOM % 250 + 1)) -s -S secret.txt ________________________________________ From: Freeradius-Users [freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org] on behalf of Sergey Komarov [sergey.komaroff@gmail.com] Sent: Thursday, July 16, 2015 9:14 AM To: FreeRadius users mailing list Subject: Re: Proxy CoA packet from network control to NAS(same as CoA server) configs in case of many many NASes. Hello Alan and colleagues, Yes, I've tried to do so. In case I write as you said I get: Waking up in 0.4 seconds. (22) Received CoA-Request Id 187 from 10.1.1.1:17809 to 10.1.1.174:3799 length 113 (22) User-Name = "78-6c-1c-94-d2-07" (22) Calling-Station-Id = "78-6c-1c-94-d2-07" (22) Cisco-AVPair = "subscriber:command=account-reauthenticate" (22) NAS-IP-Address = 10.56.33.190 (22) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (22) recv-coa { (22) [suffix] = noop (22) update control { (22) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.190 (22) Packet-Dst-Port := 1700 (22) } # update control = noop (22) [ok] = ok (22) } # recv-coa = ok *No such home server 10.56.33.190 port 14346* (22) Not sending reply to client. (22) Finished request (22) <done>: Cleaning up request packet ID 187 with timestamp +5 Waking up in 0.2 seconds. In case I add also port (Packet-Dst-Port := 1700) I get this: Waking up in 2.9 seconds. (13) Received CoA-Request Id 198 from 10.1.1.1:11374 to 10.1.1.174:3799 length 113 (13) User-Name = "60-d9-c7-32-4f-02" (13) Calling-Station-Id = "60-d9-c7-32-4f-02" (13) Cisco-AVPair = "subscriber:command=account-reauthenticate" (13) NAS-IP-Address = 10.56.33.174 (13) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (13) recv-coa { (13) [suffix] = noop (13) update control { (13) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.174 (13) Packet-Dst-Port := 1700 (13) } # update control = noop (13) [ok] = ok (13) } # recv-coa = ok *No such home server 10.56.33.174 port 14346* (13) Not sending reply to client. (13) Finished request (13) <done>: Cleaning up request packet ID 198 with timestamp +2 Waking up in 2.8 seconds. Thank you in advance for your comments! Best Regards, Sergey Komaroff On Thu, Jul 16, 2015 at 3:01 PM, Alan DeKok <aland@deployingradius.com> wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hello, Thank you Brian! But actually what I do now is that our external network controls(CoA portal) sends these coa packets to change users policy(I don't need to bind it to access req) and I wanted just proxy it via FreeRadius (to have more control about contents of these packets and have ability to modify something on the fly in CoA packet later if needed just inside of FreeRadius). I understand that all home servers must be in configs to address them correctly and I did it. Problem is that my home servers are in config, but packet doesn't proxy in case of Dst-IP usage (home server not found)... So currently I have to send CoA directly to NAS(I don't like this idea) or I have to use home server pools with name as workaround and it works now. I expected that it is possible to send via Packet-Dst-IP-Address := &NAS-IP-Address as Alan said to me and I tested but seems that it doesn't find home server in this case... BTW thank you for your scripts I will hold it to some other options, but currently this is not my case. Best Regards, Sergey Komaroff On Thu, Jul 16, 2015 at 4:30 PM, Brian Julin <BJulin@clarku.edu> wrote:
The problem is that the architecture of the server currently demands a home server instance be constructed for each and every NAS receiving CoAs, and AFAICT there's no way to build these dynamically based on arbitrary IPs encountered at runtime.
We sidestepped it and just shell out to a script to use radclient to send them. As long as you don't have a giant volume of CoA traffic and can easily figure out secrets for any given NAS from its IP address, that might be your best option.
e.g. to send one out when you see a special access-accept from a home server one would:
exec punchdhcp { wait = no input_pairs = request program = "/etc/raddb/punchdhcp.sh %{request:NAS-IP-Address}' '%{control:NAS-Identifier}' '%{control:Calling-Station-Id}'" packet_type = Access-Accept }
...then call the punchdhcp in unlang at the appropriate time...
...Then the script would have something like: #!/bin/sh echo "Calling-Station-Id := $3 Aruba-Port-Bounce-Host := 5" | /bin/radclient $1:3799 disconnect -i $(($RANDOM % 250 + 1)) -s -S secret.txt
Sergey Komarov [sergey.komaroff@gmail.com] wrote
Thank you Brian! But actually what I do now is that our external network controls(CoA portal) sends these coa packets to change users policy(I don't need to bind it to access req) and I wanted just proxy it via FreeRadius (to have more control about contents of these packets and have ability to modify something on the fly in CoA packet later if needed just inside of FreeRadius).
Right, so what you do to use my scripts is proxy all the CoAs to some dummy server which just accepts them, and unlang the script into the config so it runs pre-proxy when forwarding the CoA request, sending attributes from the CoA request to the script with your modifications. Basically you originate a CoA to replace the one sent by the AS. You might even be able to finagle using rlm_exec or something to return accurate responses if the NAS rejects the CoA, I don't know. I haven't had the opportunity to deal with an AS that will actually send me back the CoAs as mine will only send them direct to the NAS, which is why my example acted during auth packets rather than dynauth.
I understand that all home servers must be in configs to address them correctly and I did it. Problem is that my home servers are in config, but packet doesn't proxy in case of Dst-IP usage (home server not found)...
If that's not working, perhaps some rlm_realm magic may be able to map IPs to home_servers. You'd have to autogen the realm rules to match the server defs. Personally, though, I try to avoid anything that requires me to maintain a database of all my NASes. If it knows the secret for its class of device, it's a NAS :-) I have better things to do with my time.
On Jul 16, 2015, at 11:08 AM, Brian Julin <BJulin@clarku.edu> wrote:
Right, so what you do to use my scripts is proxy all the CoAs to some dummy server which just accepts them, and unlang the script into the config so it runs pre-proxy when forwarding the CoA request, sending attributes from the CoA request to the script with your modifications.
That shouldn't be necessary. Just have the server proxy the CoA packets. In 3.0.9, this works. Alan DeKok.
Hello Alan, I use 3.0.9, it doesn't works, thats why I asked about it, in case of dst-ip or dst-ip and dst-port I get same results - I get message "no home server x.x.x x". I will send detailed log later. -- Best Regards, Sergey Komarov 16 июля 2015 г. 20:49 пользователь "Alan DeKok" <aland@deployingradius.com> написал:
On Jul 16, 2015, at 11:08 AM, Brian Julin <BJulin@clarku.edu> wrote:
Right, so what you do to use my scripts is proxy all the CoAs to some dummy server which just accepts them, and unlang the script into the config so it runs pre-proxy when forwarding the CoA request, sending attributes from the CoA request to the script with your modifications.
That shouldn't be necessary. Just have the server proxy the CoA packets. In 3.0.9, this works.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 16, 2015, at 4:26 PM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I use 3.0.9, it doesn't works, thats why I asked about it, in case of dst-ip or dst-ip and dst-port I get same results - I get message "no home server x.x.x x". I will send detailed log later.
Well, it worked in all of my tests. But I did define a "home_server" of "type = coa" for that IP address / port. Alan DeKok.
Hello Alan, Could you please test it one more time with 3.0.9 or you tested recently? I have configuration with home server and type coa and port 1700, but when I try to use Dst-IP I get message as below: (43) Received CoA-Request Id 169 from 10.1.1.2:36622 to 10.1.1.174:3799 length 113 (43) User-Name = "e4-8b-7f-8b-d3-79" (43) Calling-Station-Id = "e4-8b-7f-8b-d3-79" (43) Cisco-AVPair = "subscriber:command=account-reauthenticate" (43) NAS-IP-Address = 10.56.33.174 (43) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (43) recv-coa { (43) [suffix] = noop (43) update control { (43) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.174 (43) } # update control = noop (43) [ok] = ok (43) } # recv-coa = ok No such home server 10.56.33.174 port 3799 (43) Not sending reply to client. (43) Finished request When I try to force Dst-port 1700 (anyway it is in home server config) I will get same error and random port number (No such home server 10.56.33.174 port 20). I'm using CenOS 6. I don't know may be my compilation have some troubles but rest of functions are working normally. Also if I use home server pool name it works ok, thats strange. Thank you in advance for your help! Best Regards, Sergey Komaroff --------------clients.conf--------------- client wlc_1 { ipaddr = 10.56.33.174 $template client_wlc coa_server = wlc1 } client wlc_2 { ipaddr = 10.0.249.253 $template client_wlc coa_server = wlc2 } client wlc_3 { ipaddr = 10.56.33.190 $template client_wlc coa_server = wlc3 } ------------------------------------------- -- proxy.conf------------------------- home_server wlc1 { ipaddr = 10.56.33.174 $template home_server } home_server wlc2 { ipaddr = 10.0.249.253 $template home_server } home_server wlc3 { ipaddr = 10.56.33.190 $template home_server } home_server_pool 10.56.33.174 { home_server = wlc1 } home_server_pool 10.0.249.253 { home_server = wlc2 } home_server_pool 10.56.33.190 { home_server = wlc3 } ------- -------templates.conf------------ home_server { type = coa port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } client_wlc { secret = secret nas_type = cisco } --------------------------------------------- On Thu, Jul 16, 2015 at 11:42 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 16, 2015, at 4:26 PM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
I use 3.0.9, it doesn't works, thats why I asked about it, in case of dst-ip or dst-ip and dst-port I get same results - I get message "no home server x.x.x x". I will send detailed log later.
Well, it worked in all of my tests. But I did define a "home_server" of "type = coa" for that IP address / port.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 17, 2015, at 6:34 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Could you please test it one more time with 3.0.9 or you tested recently? I have configuration with home server and type coa and port 1700, but when I try to use Dst-IP I get message as below:
Are you sure you're running 3.0.9? Because that code was buggy in 3.0.8. And the code to proxy based on Packet-Dst-IP-Address is the *same* for normal packets, and for CoA packets. So please try it for authentication packets. If it works there and not for CoA... something is wrong with your system. Make sure to install (and use) 3.0.9. If Packet-Dst-IP-Address doesn't work for authentication packets, then there's something magically broken about the code. Try to come up with a simple example which we can add to the unit test framework... Alan DeKok.
Hello Alan, On Fri, Jul 17, 2015 at 3:26 PM, Alan DeKok <aland@deployingradius.com> wrote:
Are you sure you're running 3.0.9? Because that code was buggy in 3.0.8.
Yes, I'm using 3.0.9: FreeRADIUS Version 3.0.9, for host x86_64-unknown-linux-gnu, built on Jul 14 2015 at 19:39:49 Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014
And the code to proxy based on Packet-Dst-IP-Address is the *same* for normal packets, and for CoA packets. So please try it for authentication packets. If it works there and not for CoA... something is wrong with your system. Make sure to install (and use) 3.0.9.
If Packet-Dst-IP-Address doesn't work for authentication packets, then there's something magically broken about the code.
Try to come up with a simple example which we can add to the unit test framework...
(7) Received Access-Request Id 82 from 10.56.33.174:32770 to 10.1.1.174:1812 length 267 (7) User-Name = "84-8e-df-ea-e9-62" (7) Called-Station-Id = "44-ad-d9-f1-9b-10:SSIDNAME" (7) Calling-Station-Id = "84-8e-df-ea-e9-62" (7) NAS-Port = 1 (7) NAS-IP-Address = 10.56.33.174 (7) NAS-Identifier = "WLC2504" (7) Airespace-Wlan-Id = 1 (7) User-Password = "xxxxxx" (7) Service-Type = Call-Check (7) Framed-MTU = 1300 (7) NAS-Port-Type = Wireless-802.11 (7) Tunnel-Type:0 = VLAN (7) Tunnel-Medium-Type:0 = IEEE-802 (7) Tunnel-Private-Group-Id:0 = "63" (7) Cisco-AVPair = "audit-session-id=0a3821ae000023bd55a8fab6" (7) Acct-Session-Id = "55a8fab6/84:8e:df:ea:e9:62/9166" (7) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default (7) authorize { ............. sql queries and checks skipped ............ (7) --> 1 (7) case 1 { (7) update reply { (7) Cisco-AVPair += "url-redirect-acl=acl" (7) EXPAND url-redirect=http://login.domain... (7) --> url-redirect=http://login.domain (7) Cisco-AVPair += url-redirect=http://login.domain (7) Packet-Dst-IP-Address := 10.56.33.190 <------------ here I just override real NAS IP with another NAS fixed address (it present in clients too) (7) } # update reply = noop (7) update control { (7) Auth-Type := Accept (7) } # update control = noop (7) } # case 1 = noop (7) } # switch %{sql:select state from radiusdb.radcheck where username='%{Calling-Station-Id}'} = noop (7) } # else = noop (7) } # authorize = noop (7) Found Auth-Type = Accept (7) Auth-Type = Accept, accepting the user (7) Sent Access-Accept Id 82 from 10.1.1.174:1812 to 10.56.33.174:32770 length 0 <-------- here looks like override ignored (7) Cisco-AVPair += "url-redirect-acl=acl" (7) Cisco-AVPair += "url-redirect= http://login.wi-fi.ru/am/UI/Login?org=mac&service=coa&client_mac=84-8e-df-ea... " (7) Finished request FreeRadius still sends to NAS IP instead of my override IP. So it doesn't matter in CoA or in authorize section it is same behavior - FreeRadius ignores NAS ip override via Packet-DST. Could you please check any simple scenario - just try to override Packet-Dst-IP-Address and than add to override Packet-Dst-Port? Best Regards, Sergey Komaroff
On Jul 17, 2015, at 9:15 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Yes, I'm using 3.0.9: FreeRADIUS Version 3.0.9, for host x86_64-unknown-linux-gnu, built on Jul 14 2015 at 19:39:49 Linux version 2.6.32-504.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) ) #1 SMP Wed Oct 15 04:27:16 UTC 2014
OK.
(7) update reply { (7) Cisco-AVPair += "url-redirect-acl=acl" (7) EXPAND url-redirect=http://login.domain... (7) --> url-redirect=http://login.domain (7) Cisco-AVPair += url-redirect=http://login.domain (7) Packet-Dst-IP-Address := 10.56.33.190 <------------ here I just override real NAS IP with another NAS fixed address (it present in clients too)
No, that is NOT the same as what you did for CoA packets. This isn't about sending the reply to a different NAS-IP. That will NEVER be supported, because it's wrong. It's about can you *proxy* the packet to a home server. You should instead do: update control { Packet-Dst-IP-Address := ip.of.home.server. }
FreeRadius still sends to NAS IP instead of my override IP. So it doesn't matter in CoA or in authorize section it is same behavior - FreeRadius ignores NAS ip override via Packet-DST.
The server will ALWAYS send replies to the IP that the request came from. Anything else is wrong.
Could you please check any simple scenario - just try to override Packet-Dst-IP-Address and than add to override Packet-Dst-Port?
I won't have time for a while. Until then, please try the correct test for Access-Request packets. Alan DeKok.
The server will ALWAYS send replies to the IP that the request came from. Anything else is wrong.
I see now, yes, it is correct idea.
Could you please check any simple scenario - just try to override Packet-Dst-IP-Address and than add to override Packet-Dst-Port?
I won't have time for a while.
Until then, please try the correct test for Access-Request packets.
Update control for Acc-Req doing same things for me now - no home server found. I will try to build again later on other server and if something would be different I will write here. Now I will use home server pool name as I have to configure all home servers anyway in proxy.conf now. It works. Thank you for your help and for FreeRadius software! Best Regards, Sergey Komaroff
On Jul 17, 2015, at 6:34 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Could you please test it one more time with 3.0.9 or you tested recently? I have configuration with home server and type coa and port 1700, but when I try to use Dst-IP I get message as below:
(43) Received CoA-Request Id 169 from 10.1.1.2:36622 to 10.1.1.174:3799 length 113 (43) User-Name = "e4-8b-7f-8b-d3-79" (43) Calling-Station-Id = "e4-8b-7f-8b-d3-79" (43) Cisco-AVPair = "subscriber:command=account-reauthenticate" (43) NAS-IP-Address = 10.56.33.174 (43) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (43) recv-coa { (43) [suffix] = noop (43) update control { (43) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.174 (43) } # update control = noop (43) [ok] = ok (43) } # recv-coa = ok No such home server 10.56.33.174 port 3799
I've pushed a fix to the v3.0.x branch. Please try that. Alan DeKok.
On Jul 16, 2015, at 9:14 AM, Sergey Komarov <sergey.komaroff@gmail.com> wrote:
Yes, I've tried to do so. In case I write as you said I get:
Waking up in 0.4 seconds. (22) Received CoA-Request Id 187 from 10.1.1.1:17809 to 10.1.1.174:3799 length 113 (22) User-Name = "78-6c-1c-94-d2-07" (22) Calling-Station-Id = "78-6c-1c-94-d2-07" (22) Cisco-AVPair = "subscriber:command=account-reauthenticate" (22) NAS-IP-Address = 10.56.33.190 (22) # Executing section recv-coa from file /usr/local/etc/raddb/sites-enabled/coa (22) recv-coa { (22) [suffix] = noop (22) update control { (22) Packet-Dst-IP-Address := &NAS-IP-Address -> 10.56.33.190 (22) Packet-Dst-Port := 1700 (22) } # update control = noop (22) [ok] = ok (22) } # recv-coa = ok *No such home server 10.56.33.190 port 14346*
Upgrade to 3.0.9. http://freeradius.org/press/index.html#3.0.9 * Fix proxy to Packet-Dst-IP-Address, so that it uses the correct destination port. Alan DeKok.
participants (3)
-
Alan DeKok -
Brian Julin -
Sergey Komarov