- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
01-27-2023 03:37 AM
We have configured Radius on our VM Palo but its not working. Provided screenshots of configuration we have on the FW and output of test command. Routing is defiantly in place as we can ping Radius server, however no traffic on 1812 reaching PacketFence Radius server. When done tcp dump - I can clearly see it's capturing pings but nothing for port 1812.
Palo Support not being helpful as for now just keep sending me unrelated articles... So hopefully get some advice here 🙂
Target vsys is not specified, user '*******' is assumed to be configured with a shared auth profile.
Egress: x.x.208.14
Authentication to RADIUS server at x.x.65.40:1812 for user '*******'
Authentication type: PAP
Now send request to remote server ...
RADIUS error: bind: Cannot assign requested address
Authentication failed against RADIUS server at x.x.65.40:1812 for user '*********'
Authentication failed for user '****'
01-27-2023 05:13 AM - edited 01-27-2023 05:14 AM
Monitor > Logs > System
Filter: ( subtype eq auth )
Do you see auth attempts in logs? What is in log description?
By default traffic sourced from Palo goes out from mgmt interface.
Assuming radius server IP is 1.2.3.4 does command "ping host 1.2.3.4" get replies?
Is Palo mgmt interface and radius server in same subnet or does this traffic traverse firewall?
If it traverses firewall do you see those sessions in traffic log?
01-27-2023 05:19 AM
ping is going through to radius - I have even add "source" in command to be sure is coming out of management interface.
We can see Auth logs as well but obviously not succesfull :
( description contains 'failed authentication for user \'*****\'. Reason: Authentication request is timed out. auth profile \'PF-Radius\', vsys \'shared\', server profile \'PF-Radius\', server address \'x.x.65.40\', auth protocol \'PAP\', From: x.x.x.x' )
01-27-2023 05:27 AM
If this traffic traverses firewall you can check Monitor > Logs > Traffic if those sessions are permitted, and if packets are sent and received.
You can also take packet capture https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/monitoring/take-packet-captures/take-a-pac...
01-27-2023 05:30 AM
Yep, we have checked monitor and no intersting traffic was there. Will try to setup capture to see it there. Just wondering if tcp dump from command line is sufficient an that was already done - we could see ping to radius server but nothing on 1812.
01-27-2023 05:33 AM
All services (including radius) are configured to use default (mgmt interface)?
Device > Setup > Services > Service Route Configuration
01-27-2023 06:01 AM - edited 01-27-2023 06:02 AM
Hi @T_Wojtasinski ,
The "RADIUS error: bind: Cannot assign requested address" is your issue. I have not seen that one, and it is difficult to interpret.
From your posts, it sounds like the network is fine, and the NGFW is not blocking the traffic. You may want to try these steps.
Once done, please test with the "test authentication authentication-profile" CLI command. It gives very specific errors if it fails.
Thanks,
Tom
01-27-2023 06:10 AM
Good catch @TomYoung about "RADIUS error: bind: Cannot assign requested address".
Device > Setup > Services > Service Route Configuration is set to default to use mgmt interface?
Management interface is up and connected?
01-27-2023 06:13 AM
Thanks for coming back - I think it might be the case. As this setup was done before my time - did not check that.
Looks like there is a some misconfig(attached screenshots) - in IPV4 section - there is a wrong IP (other FW) but I'm not able to change this IP. In "destination" new Radius IP(x.x.65.40) was missing so I've aded it(x.x.209.15 but I think it should be x.x.209.14 without specifying interface) - but still no luck.
Now I found another issue - mgmt IP of the FW is x.x.209.14 but mgmt interface is configured with x.x.209.15.
So to log to the box we're using .15 but mgmt traffic is .14 - that might be "source" of all troubles.
01-27-2023 06:33 AM
Hi @TomYoung
It's a PacketFence Radius in AWS and all configuration there in place(we could see ping from Palo on this server).
Secret is ok as well. We have done tcp dump so we could see ping response from the PF Radius but no 1812 as it was not reaching there. Output from "test" command is in original post.
As this VM Palo was configured before my time in this company - I found "couple" of issues.
mgmt IP of the FW is x.x.209.14 but mgmt interface is configured with x.x.209.15.
So to log to the box we're using .15 but mgmt traffic is .14 - that might be "source" of all troubles.
Also looks like there is a misconfig with service routes for Radius - its not allowing me to change existing IP's/setup(I'm "Superuser")
thanks
Tom
01-27-2023 06:49 AM
yeah, I think these double IP management setup causing issue...
Its a VM Palo in AWS so not sure whether I should change mgmt to .15 - same as interface or change IP on interface to .14 - mgmt IP address (both screen attached) - and if reboot of FW or instance required.
01-27-2023 06:52 AM
Mgmt interface IP and dataplane interface IP can't be the same so you need to keep them different.
Your issue is in service routes.
Take screenshot of current status.
Set all to default and click OK (do not commit).
Go back and set according to your need and then commit.
01-27-2023 07:06 AM
I've just added screenshots with current setup (2 newest). Unfortunately even with bringing it to default , when trying to reconfigure - it's bringing up wrong 208.14 IP. If I put mgmt interface IP - it will accept as its autofilling but whatever I type in box- its not accepting it - just coming with wrong .208.14 or other preconfigured staff
01-27-2023 07:11 AM
If you don't choose source interface then it is normal that it comes up with .14 because your firewall mgmt interface is configured with .14.
Your second screenshot shows that you have chosen ethernet1/2 as source and IP as .15
So what is still the problem?
01-27-2023 07:16 AM
The IP in first section is wrong - someone put x.x.208.14 whereas this FW is x.x.209.14 mgmt IP.
Question is if I should use mgmt IP here or mgmt interface with .209.15?
In service route should I put source interface with x.x.209.15 ? Radius server expecting traffic from mgmt IP - x.x.209.14(or its irrelevant)
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!