topic Re: VWire Radius (NPS) via Mgmt in General Topics

VWire Radius (NPS) via Mgmt

annielee — Fri, 07 Jan 2022 01:24:44 GMT

Happy 2022 !

We've just setup VWires for our branches firewalls (A/A Layer 2), no ip address on any interfaces except :

- Mgmt (routable and managed by Panorama)

- HA1-3 (non-routable address)

Most of the device management (SNMP, NTP and etc via Mgmt IP) works fine except for Radius authentication, we did some troubleshooting :

- tested on the firewall with 'test authentication radius' cli and it worked successfully

But when we try to logon to the firewall, it failed and doesnt reach the Radius and upon checking, the firewall is using the HA address as the source.

Might be something i missed, but ive looked everywhere unless this is not supported for VWire design.

Re: VWire Radius (NPS) via Mgmt

PavelK — Fri, 07 Jan 2022 03:56:54 GMT

Thank you for post @annielee and Happy 2022!

I have one site running with identical setup (VWire - no interface IP address, A/A HA, Panorama managed). The only difference is I am using TACACS+ instead of RADIUS. From what you have described this should be working and I do not see any reason why this should not be supported.

Could you please check that management interface is configured under: Device > Setup > Services > Service Route Configuration > Use Management Interface for all.

Also, could you please check in log: tail follow yes mp-log authd.log whether it can uncover more details?

Kind Regards

Pavel

Re: VWire Radius (NPS) via Mgmt

annielee — Sat, 08 Jan 2022 02:05:04 GMT

Thanks for your reply.

Yes, ive checked the Service Route and its using Mgmt Interfaces for all. Below are the debug, and it mentioned cannot bind interface.

2022-01-08 11:38:32.108 +1100 debug: _start_async_auth(pan_auth_service_handle.c:293): enqueued into not send queue: elapsed secs: 3 (max allowed secs (timeout) 60)
2022-01-08 11:38:32.109 +1100 debug: pan_authd_radius_create_req_payload(pan_authd_radius.c:236): username: annielee
2022-01-08 11:38:32.109 +1100 debug: pan_make_radius_request_buf(pan_authd_radius_prot.c:398): RADIUS request type: PAP
2022-01-08 11:38:32.109 +1100 debug: _create_rw_sock(pan_authd_conn_mgmt.c:1448): create a UDP socket: 15
2022-01-08 11:38:32.109 +1100 Error: _create_rw_sock(pan_authd_conn_mgmt.c:1477): Failed to bind to client side sock: errno=126(Cannot assign requested address)
2022-01-08 11:38:32.109 +1100 Error: _create_rw_sock(pan_authd_conn_mgmt.c:1499): reached max number of retries (3) to connect to server :0
2022-01-08 11:38:32.109 +1100 Error: _try_fd_create_if_not(pan_authd_conn_mgmt.c:517): _create_rw_sock()
2022-01-08 11:38:32.109 +1100 Error: pan_authd_conn_mgmt_enqueue_req(pan_authd_conn_mgmt.c:589): _try_fd_create_if_not() for conn context id: 2
2022-01-08 11:38:32.109 +1100 Error: _start_async_auth(pan_auth_service_handle.c:283): pan_authd_conn_mgmt_enqueue_req(): rad req id: 188; seq num: 188 ; authd global id 7044706393709871124
2022-01-08 11:38:32.109 +1100 debug: _start_async_auth(pan_auth_service_handle.c:293): enqueued into not send queue: elapsed secs: 3 (max allowed secs (timeout) 60)
2022-01-08 11:38:32.109 +1100 debug: pan_authd_radius_create_req_payload(pan_authd_radius.c:236): username: annielee
2022-01-08 11:38:32.109 +1100 debug: pan_make_radius_request_buf(pan_authd_radius_prot.c:398): RADIUS request type: PAP
2022-01-08 11:38:32.109 +1100 debug: _create_rw_sock(pan_authd_conn_mgmt.c:1448): create a UDP socket: 15

Re: VWire Radius (NPS) via Mgmt

PavelK — Fri, 14 Jan 2022 07:31:53 GMT

Thank you for reply @annielee

Would it be possible try to change interface to any and select management IP address from drop down list?

Also, could you please tell me what PAN-OS you are running?

Thank you

Pavel

Re: VWire Radius (NPS) via Mgmt

laurence64 — Fri, 14 Jan 2022 08:49:29 GMT

Hi @annielee

That really looks like an issue with the management interface and the HA setup, the daemon is trying to allocate the IP to make the request from to the socket but cannot, the only thing I can think is that when you do the test authentication it is actually sourced from the local box you are on at the time.

You could check at the RADIUS end to see which IP is being presented as the client when the test succeeds, if that is the case it could well be an issue with floating IP allocation for the Active/Active HA to communicate to the RADIUS server, I am not really used to Active Active deployments but thought I would suggest that anyway.

Hope you get it worked out!