About OwenFuller

OwenFuller

Does the "forbidden" message look like a typical web browser error message, or a Palo Alto block message? Have you checked your logs for any blocks?

OwenFuller

I'm not sure if this applies in your case, but I saw something similar when a user had two client certificates which matched the certificate profile. We solved it by deleting one of the unneeded certificates.

OwenFuller

You might want to look at a product like TeamViewer for your purposes, which can allow you to access your home computer from your phone or another computer without needing to open up ports on your firewall. While it's not a Palo Alto solution, I think it fits your use case better.

OwenFuller

Yes, the same for me. I just click on the link in the left-hand side bar though, and it takes me right to the details: GlobalProtect App 5.2 Release Information

OwenFuller

I remember running into this a few years ago, but I don't remember exactly what caused it. The issue with the web portal might be due to the web browser looking only in the user certificate store. You could try putting the client cert you put in the machine store in the user store as well. As to why the cert profile is not enforced on the connection from the GP agent, I'm not sure what to suggest here other than to make sure you actually committed the changes on firewall, or committed/pushed from Panorama.

OwenFuller · ‎08-17-2020

You can disable the weak ciphers w/ CLI commands. This Reddit thread has a good walk-through. When I followed it, I got up to an A- on the SSLLabs evaluation. https://www.reddit.com/r/paloaltonetworks/comments/hexquf/global_protect_and_cipher_suites/

OwenFuller · ‎08-13-2020

That's a great idea @RamprakashRT. I didn't even think about using a loopback. I'm going to have to try that next time we're building out a test portal or migrating users to a new config.

OwenFuller · ‎08-12-2020

Do you only have a single IP address from your ISP? If you have multiple addresses (or can request another block of IPs from the ISP), you can add one of them to the public interface I’d the firewall with a /32 mask, and use it for the second portal. For example, if your main address in the block is 10.0.0.1/28, you could add 10.0.0.2/32 on the same interface, and assign it to the second portal. If additional IPs are not an option, then you probably need to look at certificate authentication that or Connect Before Login using GP version 5.2 as previously mentioned. I was able to find the documentation: User Guide - https://docs.paloaltonetworks.com/globalprotect/5-2/globalprotect-app-user-guide/globalprotect-app-for-windows/use-connect-before-logon-followed-by-the-authentication-method.html Configuration - https://docs.paloaltonetworks.com/globalprotect/10-0/globalprotect-admin/globalprotect-apps/deploy-app-settings-transparently/deploy-app-settings-to-windows-endpoints/deploy-connect-before-logon-settings-in-the-windows-registry.html (Edited to include the link to the configuration page)

OwenFuller · ‎08-12-2020

@Rajendranahak I think the solution @RamprakashRT is probably the easiest. My organization currently runs multiple portals (one has pre-logon, and the other doesn't) on different IP addresses to meet this need. I will also throw out that starting in GlobalProtect 5.2, it is possible to do user logon to GlobalProtect before doing Windows logon. Palo Alto was calling this Connect Before Logon (CBL) in the beta testing. I'm not sure what your use case is for needing pre-logon. If you're needing the ability for a machine to be connected in order to run GPOs or login scripts, then this might be a viable option that lets you get away from the pre-logon user. From my own testing, the feature works well, but as 5.2 just went General Availability, I'm not sure whether the steps to configure it have made it into the documentation yet.

OwenFuller · ‎08-10-2020

@shafi021 it looks like @BPry got you taken care of with his reply. I would just add that even if your firewall isn't using a public IP, and your ISP was doing a source NAT on your outbound traffic, I wouldn't expect it to be doing any source NAT on the return traffic. You would most likely see that the return traffic has the proper public IPs. Also, the return traffic for established connections (those initiated from your LAN to the Internet) should be allowed anyway. You would most likely only have an issue w/ RFC1918 traffic going from your Public zone to your LAN zone if you were both 1) using private IPs on your firewall's Public interface because your ISP is doing source NAT, and 2) needing some other device on the network between your firewall and ISP's device (the Public zone according to the firewall, but the private side according to the ISP's NAT device) to the firewall's LAN zone. If you're interested in a more comprehensive BOGO list than just RFC1918, I'm a fan of CYMRU's Full Bogon list, which also includes public IP ranges not yet allocated by IANA. It can be used as an external dynamic list (EDL) on the Palo Alto firewall. https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/

OwenFuller · ‎08-06-2020

Yes, we have gotten ours up to A- by running the following commands on our firewalls in config mode (substitute your profile names as appropriate): set shared ssl-tls-service-profile GlobalProtect protocol-settings auth-algo-sha1 no set shared ssl-tls-service-profile GlobalProtect protocol-settings keyxchg-algo-rsa no Source: https://www.reddit.com/r/paloaltonetworks/comments/hexquf/global_protect_and_cipher_suites/

OwenFuller · ‎08-06-2020

Do you have a NAT policy in place for the Gateway B traffic that's going to the Internet, as well as a security policy to permit the traffic?

OwenFuller · ‎07-08-2020

I might be misunderstanding what your issue is, but I'll give it a try. In your portal configuration, do you have a anything configured under Authentication > Certificate Profile? This will cause the portal to prompt you for a client certificate. The certificate profile needs to be configured with the CA cert and key that signed your client certs in order to match it, and allow access to the portal. If that's not what you're experiencing, please elaborate or provide screenshots.

OwenFuller · ‎07-08-2020

You need to enable User-ID redistribution. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/user-id/deploy-user-id-in-a-large-scale-network/redistribute-user-mappings-and-authentication-timestamps/configure-user-id-redistribution https://docs.paloaltonetworks.com/panorama/9-0/panorama-admin/panorama-overview/user-id-redistribution-using-panorama

OwenFuller · ‎07-08-2020

This feature is currently only available in the 5.2 beta.

OwenFuller · ‎06-25-2020

Yes, this is perfectly possible. We do this w/ our SAML authentication. If you add a certificate profile under your-GP-portal (or gateway) > Authentication > Certificate Profile, any client that connects to that portal/gateway will need a cert signed by that CA. You can still use SAML authentication for the user. From the documentation: Certificate Profile ( Optional ) Select the Certificate Profile the gateway uses to match those client certificates that come from user endpoints. With a Certificate Profile, the gateway authenticates the user only if the certificate from the client matches this profile. If you set the Allow Authentication with User Credentials OR Client Certificate option to No , you must select a Certificate Profile . If you set the Allow Authentication with User Credentials OR Client Certificate option to Yes , the Certificate Profile is optional. The certificate profile is independent of the OS.

OwenFuller · ‎06-25-2020

If I'm understanding what you are trying to do, you are trying to connect from your office computer to your home computer with RDP? Your home computer is likely not using a publicly routable IP address. Instead, it's probably using an address reserved for use on private networks such as 192.168.x.x or 10.x.x.x. You cannot find these on the Internet. They are only for use on internal networks. If this is the case, your router has a public IP address on the connection to your ISP, but hides all the private addresses on the inside using network address translation (NAT). In order to access the computer inside your network, you would have to enable port-forwarding on the router. The steps for doing this vary from one manufacturer to another, and if you are not very technical, you should probably have someone who is help you set this up. Alternatively, you might consider a product like TeamViewer. However, both of these are outside the scope of this forum. You will not be able to use GlobalProtect to connect to your home network, unless you're running a Palo Alto firewall.

OwenFuller · ‎06-25-2020

This should be possible. First, enable group mapping using the documentation @domari mentioned. Make sure you add the included groups to the group mapping profile in distinguished name format (e.g. cn=groupe1,ou=myou,o=mydomain,o=local) in lower case. I have seen them fail time and time again if you use uppercase letters, or enter them in mydomain\somename format. Verify that your firewall is seeing the groups, and members using the steps here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVcCAK In you have a client IP pool listed under your-GP-gateway > Agent > Client IP pool, then these IPs will apply to all gateway users. You will need to delete this in order to enable separate pools for different groups. Under your-GP-gateway > Client Settings, create a config for Groupe1. Under Source User, add Groupe1 once again using the distinguished name in lowercase (e.g. cn=groupe1,ou=myou,o=mydomain,o=local). Go to the IP Pools tab, and add your pool for Groupe1 users. Under Split Tunnel, add the included subnets you want to allow to be accessed over the VPN. Configure any other settings in the client config you need. Repeat the process for Groupe2 users. You will also need Security Policies which will allow access. You can use the same groups for source users in those policies as well.

OwenFuller · ‎06-16-2020

I would think you could do with a Dynamic IP NAT to achieve the 1:1 NAT you're wanting (see https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/networking/nat/source-nat-and-destination-nat/source-nat.html ). However, I think if you're doing this on the corporate side, you're going to have a problem with conflicting routes (10.10.10.0/24 is both down the tunnel, and on the LAN). If you could do this at the customer side before it crosses the tunnel, that might be better. EDIT: Actually, the more I think about it, that's going to cause the same problem on the other side then. Maybe you'll have to NAT both directions with two different pools that don't conflict with the 10.10.10.0/24 address. Maybe you translate 10.10.11.0/24 to 10.10.10.0/24 on the corp side, and you translate 10.10.12.0/24 to 10.10.10.0/24 on the client side or something like that.

OwenFuller · ‎06-05-2020

In my experience, policy optimizer is incredibly buggy, and the data isn't completely trustworthy. This seems to be one of those bugs. I was looking back on some internal notes from when I ran into this a few months ago. I found something else that makes this even more odd. When you run the clear policy-app-usage-data ruleuuid command in the firewall CLI, you get the error message, and the total apps displayed in the Apps Seen column doesn't change. However, the detailed list of apps does seem to get flushed. It's deceiving, but if you're trying to see which apps have hit the rule since it was last cleared, it still might be somewhat useful. It's frustrating though. Before: Before clearing usage data After: After clearing usage data

OwenFuller · ‎06-02-2020

Have you tried uninstalling the client, rebooting, and re-installing? I believe that was another solution that worked for us. The problem only seemed to affect clients upgraded from 5.0, not clean installs.

OwenFuller · ‎06-02-2020

I think the closest you will get is doing the cookies with the auto-reconnect option. I believe this should still work just fine. It’s not going to do quite what you want in terms of a specific message, but it should still pop up the GP window from the system tray as it tries to reestablish the connection. Beyond that, you might be right to go the feature request route.

OwenFuller · ‎06-02-2020

If you have a large number of rules, and want to save a lot of time over copying them individually in the GUI, it can be useful to export the list of rules from Panorma as a CSV and include the rule UUID column. You can then use a text editor like Notepad++ to prepend clear policy-app-usage-data ruleuuid to each entry, and paste the whole thing into your firewall's CLI. You'll want to run this command before pasting: set cli scripting-mode on

OwenFuller · ‎06-02-2020

I have never configured IP addresses on my GlobalProtect tunnel interfaces. When you specify routes in the Split Tunnel Include section, these will get installed in your computer's route table as "on-link" routes pointing to the IP that your GP interface gets from the pool. It looks something like this: In this case, I'm tunneling everything (0.0.0.0/0), and my GP interface IP address is 172.X.X.X

OwenFuller · ‎06-02-2020

I saw this occasionally on version 5.1.0-75 of the GP agent after we did an upgrade from 5.0.x via SCCM without doing a clean uninstall of the old client. Generally we were able to fix this by simply going to Settings > Sign Out and then reconnecting.

OwenFuller · ‎06-02-2020

Looks like the official advisory is out, and the suggestions are to do the exemptions like most of us have been talking about already: https://live.paloaltonetworks.com/t5/customer-advisories/decryption-errors-created-by-the-expired-addtrust-external-root/ta-p/330976 What a mess. Good luck w/ your exemptions everyone!

OwenFuller · ‎06-02-2020

We only saw about ~50 destinations w/ decrypt-cert-validation as the session-end-reason in our logs, and several seem to be junk we don't really care about. We're opting to leave expiration on for most user traffic. We've created a custom URL category for affected sites which are business-related, and are using it in a separate SSL decryption policy that doesn't block the expired cert. Seems to be the best option to avoid completely disabling cert expiration checking for our purposes.

OwenFuller · ‎06-02-2020

According to the KB article TAC referenced (https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008UFBCA2), the new CA certs are already in the CA store on the firewalls. It's saying that the problem is due to " Some servers that are using certificates signed by these CAs are still including the expired CAs as part of certification chain supplied to the client." It also mentions that "Our NGFW Trusted CA store is already updated with the self-signed certs, and no change is needed to Trusted CA store on PA." However, given that the chains build properly on other systems, and there are know issues with certain clients (see my previous comment), this still seems to be a problem with PANOS (a la OpenSSL) in my opinion. We're going to continue working w/ TAC for answers.

OwenFuller · ‎06-02-2020

As @kalakai said, this problem appears to be related to OpenSSL incorrectly building the trust chain for certificates which used to chain up to the now expired Sectigo CA cert. This article (which we're also providing to TAC on our own case) provides a very detailed explanation for those who are interested: https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020

OwenFuller · ‎05-29-2020

One additional caveat I found while talking w/ my coworker was that we traced the issue to a combination of GP version 5.0.4 and our Wireshark installations, which included npcap version 0.9x with legacy loopback support enabled. If you cannot upgrade GP to a newer version, you might see if the Wireshark/npcap issue applies. You can uninstall npcap, and re-install Wireshark without selecting the legacy loopback support.

Date Registered	‎02-25-2019 08:40 AM
Date Last Visited	2 weeks ago
Total Messages Posted	103
Total Likes Received	32

Online Status	Offline
Date Last Visited	2 weeks ago

Strata

Prisma

Cortex

About OwenFuller