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
About TBardIPsoft
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About TBardIPsoft
05-17-2022
3Posts
1Like
0Solutions
May 17, 2022Last Visited
User
Activity
User
Profile
Latest posts by TBardIPsoft
| Subject | Views | Posted |
|---|---|---|
| 1711 | 08-12-2021 09:19 AM | |
| 4494 | 03-05-2018 04:52 AM | |
| 4540 | 02-13-2018 08:04 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 02-13-2018 08:04 AM |
Posts I Liked
| Subject | Likes | Author | Latest Post |
|---|---|---|---|
| 3 Likes |
User Badges
Community Statistics
| Member Since | 05-03-2017 07:12 AM |
| Date Last Visited | 05-17-2022 02:05 PM |
| Posts | 3 |
| Total Likes Received | 1 |
08-12-2021
09:19 AM
This can work for most commit issues as well (from my experience). I would like to add a note on what I was seeing here to maybe help others. I have "Group Mapping Settings" pushed from Panorama to my devices globally, sadly the "Groups Included List" does not work properly when pushed to devices. I have to go in and override the mappings on each device removing the include groups and adding them back in the override. A commit force does work from the local device but when pushing the Template and Group Config you still get: Details: . vsys1 . Error: Failed to add group to id manager . Error: Failed to parse security policy . (Module: device) . Commit failed This is where the override comes in to fix this on the Panorama push. The issue here is the firewall(s) don't have the group mapped that is being used in the security policy. Again this is because Panorama does not properly populate the included groups in the Group Mapping config.
... View more
03-05-2018
04:52 AM
I forgot about this post. Yes, you are correct in the metric change. We did also use the "no direct access to local network" setting and it had not worked before. I had messed with this tunnel on my own time on a non-corporate system and it appears to work however. I am still waiting on the other business unit to do additional testing but time tends to go slow here. Something that is different between a non-corporate system and a corporate system is that the corporate systems use certificates to access another GP-VPN tunnel. I am curious to know if this is somehow causing issues with our testing in some way. I was able to validate that they had the right client config though. You are also correct in having more issues by having users with admin access. In our set up the assumption is that the end user has admin access since they are outside contractors. I have actually discussed this with the business around requiring full-tunnel for this VPN since either way at some point they will have access to uncontrolled networks.
... View more
02-13-2018
08:04 AM
1 Kudo
I have already contact Palo Alot Networks support about this issue and their comment back to me was "you need to protect the route preference/configuration from the host side." The issue that I am facing is that we have third parties that are not managed by our company however need access to medical systems to support our customers. In order to allow these individuals access they use our VPN to connect to the customer site. The current VPN solution that we have does this without any issues. While testing full tunnel with GP-VPN we discovered that you are able to change your default route via the cmd command < route change >. This allows you to stay connected to the GP-VPN for network access (Even with "Enforce GlobalProtect Connection for Network Access" = Yes) while having access to your local Internet connection effectivly changing the full tunnel to a split tunnel. Since there are no other monitoring settings for the GP-VPN that can detect and prevent this change the only way to stop this action is via managing the client itself. However this brings us back to the point that the support of of some of these devices is being done by third parties of which we do not manage. Does anyone have any suggestions or solutions? Maybe there is some magic check box that I am missing somewhere in GP that will prevent this action from working on the host? Anything would be helpfull at this point, but I have a feeling I will just have to tell them that we need to be able to manage all endpoints that are using this VPN connection for support. Which in my openion should be the case already.
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
05-17-2022
02:05 PM
|
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks