-1

We are facing issue with radius server application wherein wireshark traces show radius request packets however some random packets are not visible in application's debug logs.

This is carrier grade radius application server from MNC vendor. I can't provide further info on that. :-(

OS = RHEL 7

radius communication utilizes IPv6

Any troubleshooting hints would be appreciated..

Vijay Gharge
  • 87
  • 1
  • 2
  • 10

1 Answers1

0

Most Radius servers operates on UDP so it is very common for packets to not be received. Most clients will send multiple packets spaced apart for this reason.

Also most radius servers do not respond to failed authentication, typically they only respond to failed authorization. If you are not seeing the logs I would suggest double checking your device conditions to make sure the server isn't simply dropping the packet.

PHELMS
  • 92
  • 1
  • 9
  • Thanks for response. While I understand all that you mentioned - how exactly I find out further details as to what exactly causes linux TCP/IP stack to receive UDP but not application stack ? – Vijay Gharge Feb 25 '17 at 06:43
  • Without knowing the specific Radius server being used I wouldn't be able to give exact answers. As an example - for Wireless authentication the AP or Controller will talk to the radius server, using the preshared key. The Radius server will have some method to validate that device is authorized (PSK + IP Address/Name/Product/etc). If THIS fails they will drop packet, without a response and Cisco ISE/ACS for example will log it in system logs vs the typical authentication logs since we haven't even gotten to the actual client's authentication yet. – PHELMS Feb 25 '17 at 07:32
  • Thanks for response. My basic query still remains open. I can see radius request in wireshark traces but not in application logs. Only if radius server receives request - it may drop or process it as per pre-defined logic. But it is not receiving radius request itself. – Vijay Gharge Feb 25 '17 at 07:43
  • I'm not sure which radius server you are using so it is really hard to help troubleshoot this from my end. What I am trying to say is that it might not be in your application logs, it might be on the server logs instead (Windows Event Viewer, /var/log/messages, etc.) Beyond that I could only recommend the basics - ensure correct radius port is being used, proper IP that radius is listening on (netstat -a). I can guarantee you that if you are seeing the packet hit the server itself, and you have something listening on the port properly - it will hit the application. – PHELMS Feb 25 '17 at 09:35
  • As Patrick has said, without knowing the specific radius server being used it can be difficult to diagnose. The best generic suggestion I can make is to thoroughly check ALL the RELATED logs on your servers for unusual entries. For example, I've seen the exact situation you're describing on my Amdocs AAA servers and jumped to the same conclusion you did - that packets were being dropped somewhere in the upper layers in the stack. They weren't. Amdocs was dropping the packets and logging it in RADIUS_syslog while we were making our assumptions from not seeing anything in RADIUS_oplog. – Brandon Xavier Feb 25 '17 at 12:10
  • It may also be worth checking if the firewall (iptables?) is dropping any packets? Certainly the Kernel to toss packets even when you see them hitting with Wireshark. – Mark Riddell Mar 08 '17 at 21:09
  • we have found dropped packets count increasing in /proc/net/udp6 only for 1813 (radius accounting) port. In wireshark I can see some packets shown as "malformed packets" & few packets which look absolutely fine but they are not visible in application logs at all. We have opened case with REDHAT for further analysis. Increasing net_dev_budget value was one of the suggestion. But no fix yet. – Vijay Gharge Mar 18 '17 at 09:19
  • Issue got resolved after fixing issue at source end. – Vijay Gharge May 11 '17 at 05:23