- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-12-2022 11:02 PM
We have two types of network. The internal LAN and guest LAN. These are two separated networks
On the internal LAN we have use other policies then the guest LAN. Our employees connect to the guest LAN to avoid the policies on the internal LAN. So I created a block rule on the guest LAN if the user = AD User.
On the internal LAN we have an active directory server and we use user identification.
On the guest LAN I also enabled user identification, but the users don't get recognized and the policies doesn't work.
I think the problem is that from the guest LAN you can't contact the internal AD server, but that is also the purpose.
What can I do to fix this?
04-14-2022 08:39 AM
You have nothing to identify the user if you're restricting access to internal resources, that in my mind is all "by design" when dealing with a guest network. Assuming that you are using issued devices, you could easily use a netsh wlan filter to block the guest SSID on your issued endpoints.
Alternatively you simply make sure that your guest network is blocking the same resources, if not more, than what you allow on the internal network. Essentially making sure that users don't have a reason to ever connect to the guest network.
Another alternative, stop using technology to fix HR problems. If you have a way of identifying these users already setup, and a policy to prevent this sort of bypass, then document it and send it up the chain of command. At the end of the day this isn't a technology failure, it's a process/policy failure. If your internal network is more stringent than your guest network, of course users are going to bypass those restrictions if they can. Either take away their ability to connect to the guest network, make the guest network more stringent than the internal network, or this happens.
04-13-2022 01:21 PM
Hello,
For the past few networks I managed, we set the same restrictions on the guest networks, etc. Actually they were a bit more stringent since we didnt want to apply user-id and policies based on it, etc. So if a person connected to the guest network, they only had access to the internet and the url filters were more stringent.
Regards,
04-14-2022 08:39 AM
You have nothing to identify the user if you're restricting access to internal resources, that in my mind is all "by design" when dealing with a guest network. Assuming that you are using issued devices, you could easily use a netsh wlan filter to block the guest SSID on your issued endpoints.
Alternatively you simply make sure that your guest network is blocking the same resources, if not more, than what you allow on the internal network. Essentially making sure that users don't have a reason to ever connect to the guest network.
Another alternative, stop using technology to fix HR problems. If you have a way of identifying these users already setup, and a policy to prevent this sort of bypass, then document it and send it up the chain of command. At the end of the day this isn't a technology failure, it's a process/policy failure. If your internal network is more stringent than your guest network, of course users are going to bypass those restrictions if they can. Either take away their ability to connect to the guest network, make the guest network more stringent than the internal network, or this happens.
04-14-2022 01:11 PM
You could create dynamic user groups using MAC addresses, so when computers connect to a network the policies associated with the 'user' aka device connects policy is still enforced.
You could also simplify that significantly with Palo's IoT solution, automated device discovery that pushes mappings to the NGFW, and write policies for managed endpoints.
04-20-2022 06:24 AM
Thanks all for this info. I know now which direction I need to go.
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!