This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
About GeorgePalo
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- LIVEcommunity
- About GeorgePalo
05-24-2021
12Posts
2Likes
0Solutions
May 24, 2021Last Visited
User
Activity
User
Profile
Latest posts by GeorgePalo
| Subject | Views | Posted |
|---|---|---|
| 1098 | 05-20-2021 05:20 AM | |
| 1422 | 05-11-2021 09:03 AM | |
| 1467 | 05-11-2021 06:42 AM | |
| 1245 | 05-07-2021 03:01 PM | |
| 2246 | 05-07-2021 09:05 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 05-07-2021 09:05 AM | |
| 1 Like | 05-07-2021 08:41 AM |
Posts I Liked
| Subject | Likes | Author | Latest Post |
|---|---|---|---|
| 1 Like | |||
| 1 Like | |||
| 1 Like | |||
| 1 Like |
User Badges
Community Statistics
| Member Since | 05-06-2021 12:25 PM |
| Date Last Visited | 05-24-2021 01:29 AM |
| Posts | 12 |
| Total Likes Received | 2 |
05-20-2021
05:20 AM
I'm testing this and have questions... Where exactly is the root certificate stored on Windows and Mac when 'Install in local root certificate store' is selected under the agent configuration? My understanding is that the firewall pushes the root-ca down to the client upon connecting. I can't see any new certificates added in Keychain on Mac or via mmc on Windows. Also would this be considered a less secure option because you are pushing down a root certificate to the endpoint meaning that they only require a correct username and password to connect.
... View more
05-11-2021
09:03 AM
Yeah that makes sense. Do you have any more information about how to set the number of authentication failures before lockout on the portal? Thanks,
... View more
05-11-2021
06:42 AM
I want to make my GP portal more secure by adding User-ID to my GP inbound rule so that only users in the AD group can authenticate. At the moment source user is just set to 'any' and the VPN is working fine. When I add the group as in the attached image it breaks. I'm guessing there are some extra configuration steps i'm missing here... Note that the group mapping is working fine in other rules once users are authenticated. I'm just wondering if I can utilise user-id at the first step in the authentication process.
... View more
05-07-2021
03:01 PM
Is there a way to stop GlobalProtect from deleting the local default route upon disconnect? I've noticed after disconnecting from the VPN it deletes the default route in the local routing table thus meaning I have no internet connectivity unless I disable and re enable my network connection. I have split tunnelling configured to exclude '0.0.0.0/0' and to include a couple of private IP ranges on the remote network as I don't want all traffic to be backhauled through the VPN. The tunnel is working perfectly. Just wondering why it doesn't restore the correct default route upon disconnect. Client version is 5.2.5-66 running on Big Sur 11.3
... View more
05-07-2021
09:05 AM
1 Kudo
Holy moly it worked. I added the domain in the auth profile and left the username modifier as the default. I tried this yesterday but changed the modifier to %USERDOMAIN%/%USERINPUT% and it didn't work. Thanks all for your help on this.
... View more
05-07-2021
08:41 AM
1 Kudo
Thanks... heres some output:
... View more
05-07-2021
04:05 AM
Thanks for your help Mick
... View more
05-07-2021
04:01 AM
At present anyone connecting in via VPN can access the network via an 'allow any' rule from 'SSL_VPN' zone to the 'trust' zone. I've placed a rule above that rule to deny access to one IP address on the network if the source user is in the 'hpslab\globalprotect-vpnusers' group. This group has been pulled from the AD server and contains the user that I'm logged in via the VPN to test with. So as it stands at the moment I can still access the '192.168.50.1' IP and the deny rule isn't working.
... View more
05-07-2021
03:41 AM
If I enter the domain in the auth profile 'User Domain' field then it messes up the VPN setup and the user can no longer connect. At the moment the user authenticates to the LDAP server successfully when connecting via GlobalProtect and can access resources on the network. This tells me there is nothing wrong with reaching the AD server and authenticating the user in the user group. The user gets an IP and can access resources. When logged in as the user via the GlobalProtect VPN I can see in the traffic log it's successfully showing the correct 'source user' as I connect to different network resources. What I don't understand why is if I then try to create a rule blocking that user from accessing a specific IP on the network it doesn't work. I know the rule is working because if I remove the 'Source User' part of the rule I get hits and it shows the correct user in the log.
... View more
05-06-2021
04:40 PM
The output of the commands you recommended shows that the user with the IP address is indeed the same as the user in the AD group. All output is as expected. This is a lab setup so I only have one group and I can see the username is correct. No I'm not overriding domain in auth profile or group mapping. I thought the firewall automatically detected the domain from the server profile? I've left 'User Domain' blank and 'Username Modifier' as the default '%USERINPUT%' in auth profile and group mapping.
... View more
05-06-2021
01:52 PM
Yes the user has an IP mapping. The user is accessing via GlobalProtect VPN which drops the user into 'VPN_Zone'. There's no issues with VPN connectivity and the user can access everything in the 'trust' zone which I can confirm in the logs. Yes their username is showing under 'src user'. I then place a rule above the 'allow all' rule I have for VPN users to access resources in the 'trust zone'. This deny rule to block access to a specific IP address contains the users group on the AD directory. The same group that contains the user that is connected via the VPN successfully.
... View more
05-06-2021
12:30 PM
Hi, I have searched and found similar posts but none seem to have a working solution for this... I have a simple security policy to deny access to a VM located in the 'trust' zone if it matches a user in the user group created on the AD server. I've confirmed with 'show user group name' that the firewall can indeed see the correct users in the group but when applying that group to the deny policy i'm not getting a hit. any ideas? Thanks,
... View more
LEGAL NOTICES
Copyright 2007 - 2022 - Palo Alto Networks