12-11-2020 01:51 PM
We are trying to implement a NAC solution. The basics are that the NAC is connected to the switch stack and upon sensing a device connecting, it checks it for authentication against the NAC and if it fail it quarantines it into a specific VLAN. That part is working.
The next step WOULD be that when the device goes to make a connection somewhere and upon hitting the Palo Alto (They are using the Palo Alto for Layer 3) the VLAN it is in SHOULD route it to the authentication page of the NAC and allow them to login and then the NAC would remove it from the quarantine VLAN and place it in the proper and routable VLAN. This part is not working.
We have tried a few way to get the Palo Alto to direct all traffic in the quarantine VLAN to a specific IP (Internal Auth Page of the NAC) and nothing we have done is getting it to actually do the redirect........
Thoughts, suggestions, help, I am a PA newb, but have configured these with Cisco PBR's all day long and never had an issue............and Google has not been my friend!!
Thanks in advance if you can help
12-12-2020 08:22 AM
Hello @Nonaxium
Change the thought process of where to send the authentication request, and I think it can be accomplished.
The FW already has an authentication policy configuration, so when an unknown user attempts to authenticate, a splash page could be configured, to pop up, as the user to put their credentials into the page, and then the FW can send them to (typically) a LDAP/Radius/Kerberos/MFA.
So, do not make your requests to the NAC, that is too difficult. As you are new to PANW, let's work with what PANW CAN do for you. 😛
https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/authentication/authentication-policy.html
12-12-2020 08:52 PM
As for your redirect question, the firewall isn't really meant to do that. You can do some really kinda hacky things with NAT and destination translation and DNS rewrite, but I don't generally recommend them. Depending on the NAC solution, you can actually get most solutions working well together via the firewalls XML API and the NAC solutions API.
I think @SteveCantwell aactually hints at my recommendation whenever I see someone brining in a new NAC solution to a PAN environment. What are you actually attempting to accomplish? PANs direct answer to NAC is that with GlobalProtect and proper zone isolation you can make a more secure environment without it. There's some proper design discussion that needs to go into that conversation, but just through PAN you can already identify devices and users so what NAC is designed to do becomes a duplication of features you already have if properly implemented.
12-12-2020 09:09 PM
The NAC solution that we are trying to implement is more than just used/machine identification. It provides compliance and regulatory checks, verifies software is not on a known vulnerable version, validates A/V is installed among others.
I would usually implement at a root switch operating at with a static route, but in this instance, the layer 3 device is the PA. I considered setting up an additional virtual network on the PA with a static route just for the NAC to route the quarantine VLAN to the NAC splash page until authentication is done and then the device is removed from the quarantined VLAN and is routing normally.
This is the only thing that I can think of right now. A Palo friend of mine told me that PAN can only PBF from a layer 3 device to a layer 3 device and that is why the redirect to the NAC on a layer 2 switch is not working, but I am still trying to clarify that.
12-12-2020 09:16 PM
Right, but you just described all of the features available via HIP checks in GlobalProtect. I'm not saying at all that you should just abandon NAC solutions that you already have in place, but from your question it doesn't sound like this is actually installed and functional yet. In that instance, I would absolutely be looking at GlobalProtect as your "NAC" solution instead of bringing in a NAC product.
When GlobalProtect is properly configured and using all of the features available in the product, I've yet to see a true reason to keep NAC around outside of existing integrations that it doesn't sound like you have to contend with. Where it's been needed, I'd recommend tying the two products together through the API available through both products. Most NAC integrations with PAN products are done through API; instead of trying to shoehorn the two to work alongside each other, it's often better to try and get them to work in tandem to pass information between the two for VLAN assignment.
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!