Documentation Downloads Knowledge How-To Hub Forums Cases Assets Warranty
Skip to main content
steve_bluck

8 Messages

 • 

174 Points

Tue, Feb 18, 2020 9:47 PM

vSZ-H "Authentication server not reachable" alarm with unusual IP

Since upgrading to 5.1.2.0.302 we have been getting several oddities, one of which is two alarms:
Authentication Server [172.23.0.110] not reachable from Radius Proxy [172.23.0.185] on Virtual SmartZone [128.149.95.207]
Authentication Server [172.23.0.116] not reachable from Radius Proxy [172.23.0.185] on Virtual SmartZone [128.101.127.45]
The two 172.23.0.0/23 IP's are correct but, in order to troubleshoot, I'm wondering where the Virtual SmartZone IP is coming from. The vSZ-H is exposed to the Internet due to having some remote AP's.

Question

 • 

Updated 

6 days ago

39

4

Responses

albert_pierson

Official Rep

 • 

174 Messages

 • 

4.8K Points

a year ago

Hi Steve,

RADIUS proxy requests should be sent out the Management interface of a 3 interface (control/AP;management;cluster) vSZ-H.  I would expect 172.23.0.185 to be the management IP

Getting a Packet Capture on the port connecting the management port would be the best way to understand the RADIUS traffic.  It is also good to check that against the RADIUS logs in the server.

You can put the RADIUS proxy process into debug logs under Diagnostics::Application Logs and settings and then highlight that line and use the first tab on the top "download logs" to download all the RADIUS proxy logs ... BUT putting any log into debug mode can affect operation so it should be done only when diagnosing and better at low traffic times.

There is also a very useful Authentication statistics page under Diagnostics where you can see if Access rejects, timeouts and accepts are getting incremented.  You can clear any particular listed RADIUS under this page to see statistics happening in real time.

I hope this helps.

Albert

1

steve_bluck

8 Messages

 • 

174 Points

Thanks for the quick reply, I shall do some debugging as suggested & update the post with the results

Like

a year ago

0

steve_bluck

8 Messages

 • 

174 Points

a year ago

Hi Albert,
Turns out that debugging was on.. (now off).
Looking through the many logs I've found clusters like these event all at same time stamp:
[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:312]
Getting ControlBlade ID i.e., bond0 MAC.

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:436]
C-Blade Mac Address:|00:50:56:A5:2D:3C|

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:314]
Control Blade ID:00:50:56:A5:2D:3C
[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:319]
prctl:get process_name successfully. process name is = radiusd

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:340]
SouthBound interface is br0

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:346]
North bound ip is 172.23.0.185

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:359]
South bound ip  is 172.23.0.185

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:372]
Cluster  ip  is 144.99.127.45

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:385]
Management ip is 128.101.127.45

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:378]
Cluster  ip  is NA

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:391]
Management ipv6 is ì

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:399]
Displaying syslog configurations!!!!!!!!!!!!!!!!

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:400]
North bound Ip   :172.23.0.185

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:401]
South bound Ip   :172.23.0.185

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:402]
Cluster Ip       :144.99.127.45

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:403]
ManagementIp     :128.101.127.45

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:404]
North bound Ipv6 :NA

[Mon Feb 17 2020 21:52:16:300][TAIVSZ01][RADIUS][DBG][TID=-2029778176][SyslogInterface.c:405]
South bound Ipv6 :NA
The cluster & management IP are not the ones we have configured, while the 172.23.0.185 is correct for one of the vSZ's (TARVSZ01) in the cluster with 10.12.30.12 (TAIVSZ01) being the other 
If i SSH into each vSZ and do "show cluster ip-list" neither of these IP's are there, and "show control-plane" only has the configured IP's
Any ideas what is going on?
Cheers
Steve

1

0

steve_bluck

8 Messages

 • 

174 Points

Any input???
Message: 
The event detail information is as follow: 
Node IP 	172.23.0.185 in Cluster [CLUSTER1] 
Category 	Authentication 
Event Type 	Authentication server not reachable 
Severity 	Major 
Date and Time 	Fri Apr 17 19:37:17 NZST 2020 
Activity 	Authentication Server [172.23.0.110] not reachable from Radius Proxy [172.23.0.185] on Virtual SmartZone [128.133.191.238] 
--------------------------------------------------------------------------------------------------------------- 
This email was generated automatically by Ruckus Wireless, please do not reply. 

Other IP's

[128.133.191.254] 
[128.149.95.207] 
[128.101.127.45] 
[128.149.95.127] 


Like

9 months ago

0

intern_beheer

2 Messages

 • 

72 Points

2 months ago

We are getting the exact same alarms, with the same 'strange' WAN-ip addresses after 'Virtual smartzone [strangeIP]'.

The authentication servers are in the same network as both Virtual smartzone VM's. Also, we see in our monitoring no outage or other problem with the network or the connection between the smartzones and authentication servers.


So I would say the alarms are a bug, can anyone confirm this?

1

rob_bush

4 Messages

 • 

150 Points

FWIW, I get these messages all the time on a vSZ-Essentials with only a single a single interface per cluster node.  I came here hoping to find a solution too!

Like

2 months ago

0

alexandre_jablonski

8 Messages

 • 

166 Points

6 days ago

I'm getting the same issue as well. Strangly it was google that directed me to this post. In my case the strange IP is 32.111.98.106 and this IP is what google directed me to this post.

I'm ripping my hair out trying to understand this error. I thought maybe its some sort of UDP reflection attack. my vSZ is on GCE and we have port 3799 filtered to only our NAS servers.

0

0

Was this helpful?