Radius authentication not working

[T_Wojtasinski]

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 '****'

Please note you are posting a public message where community members and experts can provide assistance. Sharing private information such as serial numbers or company information is not recommended.

[Raido_Rattameister]

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?

[T_Wojtasinski]

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' )

[Raido_Rattameister]

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...

[T_Wojtasinski]

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.

[Raido_Rattameister]

All services (including radius) are configured to use default (mgmt interface)?

Device > Setup > Services > Service Route Configuration

[TomYoung]

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.

• What RADIUS server are you using?
• Have you configured the management IP of the NGFW as a client on your RADIUS server?
• Have you verified the shared secret?
• Have you checked the logs on the RADIUS server?

Once done, please test with the "test authentication authentication-profile" CLI command.  It gives very specific errors if it fails.

Thanks,

Tom

[Raido_Rattameister]

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?

[T_Wojtasinski]

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.

[T_Wojtasinski]

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 

[T_Wojtasinski]

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. 

[Raido_Rattameister]

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.

[T_Wojtasinski]

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 

[Raido_Rattameister]

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?

[T_Wojtasinski]

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)