cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2015
Views
0
Helpful
3
Replies

Radius requests changed with IOS

lucix
Level 1
Level 1

Hello,

I have some AS5350 voice gateways using an dummy radius server which has one "little" bug. It can be configured for a auth to listen on one port and for acct on another port, but, when a packet hits it having any source udp port of the sender IP it does not respond on the same udp port, but it sends the packet to the requester's ip with the destination udp port as the same port it received the request.

I don't know if anyone understands what I just wrote, so, let me give you an example :

as5350 with IP 1.1.1.1 with radius server 2.2.2.2 auth-port 1645 acct-port 1646 scenario:

1.1.1.1.1645 > 2.2.2.2.1645

2.2.2.2.1645 > 1.1.1.1.1645

(If as5350 sends the auth request using local udp port 1645, auth works fine)

1.1.1.1.21645 > 2.2.2.2.1645

2.2.2.2.1645 > 1.1.1.1.1645

(If as5350 sends the auth request using another local udp port than the auth-port of my radius, auth fails because the dummy radius sends the packet back using the destination udp port 1645).

Using IOS Versions 12.2 XB, everything is OK, the as5350 sends its requests from udp port 1645 always.

Using IOS Versions > 12.2(11)T, AS5350 sends its requests using udp port 21645. The quick fix should have been to change the radius acctport to 21645, which I did, and everything was OK for about 10 minutes. After that, AS5350 started sending requests using udp port 21646 so I had no auth.

I could not determine how it changes the source udp port, but the problem is that it does.

My Question :

IS There any way for me to make my AS5350 using IOS 12.3(2)T to send auth and acct packets to my radius server using a non-changing source udp port ?

1 Accepted Solution

Accepted Solutions

gfullage
Cisco Employee
Cisco Employee

Check out http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCea72719&Submit=Search and you'll see that we've reverted back to the old behaviour using 1645 only in 12.3(3.6)T which is not available as yet (you could open a TAC case and get it posted for you if you like).

For the moment implement the workaround but be careful, it's a hidden command and apparently, although I haven't tested it, it doesn't stay there after a reboot.

View solution in original post

3 Replies 3

gfullage
Cisco Employee
Cisco Employee

Check out http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCea72719&Submit=Search and you'll see that we've reverted back to the old behaviour using 1645 only in 12.3(3.6)T which is not available as yet (you could open a TAC case and get it posted for you if you like).

For the moment implement the workaround but be careful, it's a hidden command and apparently, although I haven't tested it, it doesn't stay there after a reboot.

Thanks a lot !

I will test it during the night because I need to see if it works right on a gateway with traffic, but I read the bug and it's exactly the info I needed, so... problem solved ... I owe you a beer :D

Ok, I did issued the hidden command radius-server source-ports 1645-1646, then I did a test aaa authentication with debug ip packed detailed and everything worked well.

I saved the config, reloaded the router and still works, and I see the hidden command in show running-config, so... it works !

Thanks

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: