John Whitten
2017-05-04 16:28:15 UTC
Hello everybody,
My company is presently running PF 6.5.0 and generally things seem to be working well. Recently though I've experienced a problem (actually on two separate occasions) with PF's ability to regulate CLI admin access to switches. Specifically we are using Cisco 2960's (I think both of them were 2960G models). In both instances, I deleted the switch from the switch group and then had a reason to reconnect it to the switchgroup, which all seemed to go okay without issues, but was then subsequently unable to login (ssh) into those switches from the command line. PF refused the access and wrote a rejected record in the audit log. There is a very, very slight difference in the log entry, as viewed in "Details" in the auditing area. I will include an example of both below. Note that in the "Bad Switch" version, the calling host's IP address is placed into the "MAC Address" field in the "Switch Information" entry. And there is no RADIUS reply. I have actually traced the FreeRADIUS process and it is returning "Rejected" with a "Mac is empty" message, similar to the one pasted below:
Thu May  4 12:04:37 2017 : ERROR: (307318) rest: ERROR: {"Reply-Message":"Mac is empty","reply:PacketFence-Authorization-Status":"allow"}
It is useful to keep in mind that I have 16 of these switches set up and running daily in PF. Two of them have developed this condition and in both situations, the only thing which occurred on my part was deleting them from the "switches" configuration (in the gui) and then adding them back using the same gui a few minutes later, in the same manner I had originally added them, by cloning one of the other entries. And this is the method I have used to add all of the switches and all of them were originally working-- permitting admin login from the cli-- without issue.
I have combed through all of the config files and the database tables looking for something that's different and I can't find a thing. In the logs there is one difference- which I described above. The Radius and PacketFence logs had only once difference in the setup between the "Good Switch" and the "Bad Switch" which are readily obvious in the portions I've included below. The only thing I can find in the code seems to be in the "radius.pm" module at about line 120 where it says:
 my ($nas_port_type, $eap_type, $mac, $port, $user_name, $nas_port_id, $session_id) = $switch->parseRequest($radius_request);
  if (!$mac) {    return [$RADIUS::RLM_MODULE_FAIL, ('Reply-Message' => "Mac is empty")];  }
Then later, when it goes to show the log entries, it instead puts in the calling host's IP address (instead of the MAC address).
Bear in mind that the access from the calling host to the switch was identical for both switches. E.g.
ssh admin@(switch_ip)
Followed by the appropriate password to login. The "Good Switch" accepted it, the "Bad Switch" rejected it.
Does anybody have any thoughts about what could be happening or how to troubleshoot this issue further?
Thanks
John Whitten
Good Switch, No issues:
Switch Information:
| MAC Address | ( blank ) Â <-- Blank, no entry |
| Auth Status | Accept |
| Auth Type | Accept |
| Auto Registration | no |
| Calling Station ID | |
| Computer name | N/A |
| EAP Type | |
| Event Type | Radius-Access-Request |
| IP Address | |
| Is a Phone | no |
| Node status | N/A |
| Domain | |
| Profile | N/A |
| Realm | null |
| Reason | |
| Role | N/A |
| Source | N/A |
| Stripped User Name | admin |
| User Name | admin |
| Unique ID
|
RADIUS Log:
| RADIUS Request | User-Name = "admin"User-Password = "******"NAS-IP-Address = 172.23.3.101NAS-Port = 1NAS-Port-Type = VirtualEvent-Timestamp = "May 4 2017 12:02:14 EDT"NAS-Port-Id = "tty1"Stripped-User-Name = "admin"Realm = "null"FreeRADIUS-Client-IP-Address = 172.23.3.101SQL-User-Name = "admin" |
| RADIUS Reply | Reply-Message = "Switch enable access granted by PacketFence"Cisco-AVPair = "shell:priv-lvl=15"PacketFence-Authorization-Status = "allow" |
Switch Information:
| Switch ID | N/A |
| Switch MAC | N/A |
| Switch IP Address | N/A |
| Called Station ID | |
| Connection type | N/A |
| IfIndex | N/A |
| NAS identifier | |
| NAS IP Address | 172.23.3.101 |
| NAS Port | 1 |
| NAS Port ID | tty1 |
| NAS Port Type | Virtual |
| RADIUS Source IP Address | 172.23.3.101 |
| Wi-Fi Network SSID |
Bad Switch, Can't Login:
Node Information:
| MAC Address | (1.2.3.4) Â <-- Not blank, contains calling host ip addr |
| Auth Status | Reject |
| Auth Type | Accept |
| Auto Registration | no |
| Calling Station ID | 1.2.3.4 |
| Computer name | N/A |
| EAP Type | |
| Event Type | Radius-Access-Request |
| IP Address | |
| Is a Phone | no |
| Node status | N/A |
| Domain | |
| Profile | N/A |
| Realm | null |
| Reason | rest: Server returned: |
| Role | N/A |
| Source | N/A |
| Stripped User Name | admin |
| User Name | admin |
| Unique ID |
RADIUS Log:
|
| request_time | 0 |
| RADIUS Request | User-Name = "admin"User-Password = "******"NAS-IP-Address = 172.23.3.204NAS-Port = 1Calling-Station-Id = "1.2.3.4"NAS-Port-Type = VirtualEvent-Timestamp = "May 4 2017 12:04:37 EDT"NAS-Port-Id = "tty1"Stripped-User-Name = "admin"Realm = "null"FreeRADIUS-Client-IP-Address = 172.23.3.204Module-Failure-Message = "rest: Server returned:"Module-Failure-Message = "rest: {\"Reply-Message\":\"Mac is empty\",\"reply:PacketFence-Authorization-Status\":\"allow\"}"SQL-User-Name = "admin" |
| RADIUS Reply |
Switch Information:
| Switch ID | N/A |
| Switch MAC | N/A |
| Switch IP Address | N/A |
| Called Station ID | |
| Connection type | N/A |
| IfIndex | N/A |
| NAS identifier | |
| NAS IP Address | 172.23.3.204 |
| NAS Port | 1 |
| NAS Port ID | tty1 |
| NAS Port Type | Virtual |
| RADIUS Source IP Address | 172.23.3.204 |
| Wi-Fi Network SSID |
My company is presently running PF 6.5.0 and generally things seem to be working well. Recently though I've experienced a problem (actually on two separate occasions) with PF's ability to regulate CLI admin access to switches. Specifically we are using Cisco 2960's (I think both of them were 2960G models). In both instances, I deleted the switch from the switch group and then had a reason to reconnect it to the switchgroup, which all seemed to go okay without issues, but was then subsequently unable to login (ssh) into those switches from the command line. PF refused the access and wrote a rejected record in the audit log. There is a very, very slight difference in the log entry, as viewed in "Details" in the auditing area. I will include an example of both below. Note that in the "Bad Switch" version, the calling host's IP address is placed into the "MAC Address" field in the "Switch Information" entry. And there is no RADIUS reply. I have actually traced the FreeRADIUS process and it is returning "Rejected" with a "Mac is empty" message, similar to the one pasted below:
Thu May  4 12:04:37 2017 : ERROR: (307318) rest: ERROR: {"Reply-Message":"Mac is empty","reply:PacketFence-Authorization-Status":"allow"}
It is useful to keep in mind that I have 16 of these switches set up and running daily in PF. Two of them have developed this condition and in both situations, the only thing which occurred on my part was deleting them from the "switches" configuration (in the gui) and then adding them back using the same gui a few minutes later, in the same manner I had originally added them, by cloning one of the other entries. And this is the method I have used to add all of the switches and all of them were originally working-- permitting admin login from the cli-- without issue.
I have combed through all of the config files and the database tables looking for something that's different and I can't find a thing. In the logs there is one difference- which I described above. The Radius and PacketFence logs had only once difference in the setup between the "Good Switch" and the "Bad Switch" which are readily obvious in the portions I've included below. The only thing I can find in the code seems to be in the "radius.pm" module at about line 120 where it says:
 my ($nas_port_type, $eap_type, $mac, $port, $user_name, $nas_port_id, $session_id) = $switch->parseRequest($radius_request);
  if (!$mac) {    return [$RADIUS::RLM_MODULE_FAIL, ('Reply-Message' => "Mac is empty")];  }
Then later, when it goes to show the log entries, it instead puts in the calling host's IP address (instead of the MAC address).
Bear in mind that the access from the calling host to the switch was identical for both switches. E.g.
ssh admin@(switch_ip)
Followed by the appropriate password to login. The "Good Switch" accepted it, the "Bad Switch" rejected it.
Does anybody have any thoughts about what could be happening or how to troubleshoot this issue further?
Thanks
John Whitten
Good Switch, No issues:
Switch Information:
| MAC Address | ( blank ) Â <-- Blank, no entry |
| Auth Status | Accept |
| Auth Type | Accept |
| Auto Registration | no |
| Calling Station ID | |
| Computer name | N/A |
| EAP Type | |
| Event Type | Radius-Access-Request |
| IP Address | |
| Is a Phone | no |
| Node status | N/A |
| Domain | |
| Profile | N/A |
| Realm | null |
| Reason | |
| Role | N/A |
| Source | N/A |
| Stripped User Name | admin |
| User Name | admin |
| Unique ID
|
RADIUS Log:
| RADIUS Request | User-Name = "admin"User-Password = "******"NAS-IP-Address = 172.23.3.101NAS-Port = 1NAS-Port-Type = VirtualEvent-Timestamp = "May 4 2017 12:02:14 EDT"NAS-Port-Id = "tty1"Stripped-User-Name = "admin"Realm = "null"FreeRADIUS-Client-IP-Address = 172.23.3.101SQL-User-Name = "admin" |
| RADIUS Reply | Reply-Message = "Switch enable access granted by PacketFence"Cisco-AVPair = "shell:priv-lvl=15"PacketFence-Authorization-Status = "allow" |
Switch Information:
| Switch ID | N/A |
| Switch MAC | N/A |
| Switch IP Address | N/A |
| Called Station ID | |
| Connection type | N/A |
| IfIndex | N/A |
| NAS identifier | |
| NAS IP Address | 172.23.3.101 |
| NAS Port | 1 |
| NAS Port ID | tty1 |
| NAS Port Type | Virtual |
| RADIUS Source IP Address | 172.23.3.101 |
| Wi-Fi Network SSID |
Bad Switch, Can't Login:
Node Information:
| MAC Address | (1.2.3.4) Â <-- Not blank, contains calling host ip addr |
| Auth Status | Reject |
| Auth Type | Accept |
| Auto Registration | no |
| Calling Station ID | 1.2.3.4 |
| Computer name | N/A |
| EAP Type | |
| Event Type | Radius-Access-Request |
| IP Address | |
| Is a Phone | no |
| Node status | N/A |
| Domain | |
| Profile | N/A |
| Realm | null |
| Reason | rest: Server returned: |
| Role | N/A |
| Source | N/A |
| Stripped User Name | admin |
| User Name | admin |
| Unique ID |
RADIUS Log:
|
| request_time | 0 |
| RADIUS Request | User-Name = "admin"User-Password = "******"NAS-IP-Address = 172.23.3.204NAS-Port = 1Calling-Station-Id = "1.2.3.4"NAS-Port-Type = VirtualEvent-Timestamp = "May 4 2017 12:04:37 EDT"NAS-Port-Id = "tty1"Stripped-User-Name = "admin"Realm = "null"FreeRADIUS-Client-IP-Address = 172.23.3.204Module-Failure-Message = "rest: Server returned:"Module-Failure-Message = "rest: {\"Reply-Message\":\"Mac is empty\",\"reply:PacketFence-Authorization-Status\":\"allow\"}"SQL-User-Name = "admin" |
| RADIUS Reply |
Switch Information:
| Switch ID | N/A |
| Switch MAC | N/A |
| Switch IP Address | N/A |
| Called Station ID | |
| Connection type | N/A |
| IfIndex | N/A |
| NAS identifier | |
| NAS IP Address | 172.23.3.204 |
| NAS Port | 1 |
| NAS Port ID | tty1 |
| NAS Port Type | Virtual |
| RADIUS Source IP Address | 172.23.3.204 |
| Wi-Fi Network SSID |