About BPry

BPry · ‎02-09-2023

@ErinWest, I'd likely start with your AM or SE on your account to start the ball rolling, as I'd assume these are technically under feature requests.

BPry · ‎02-09-2023

@Keerthigav, Assuming this is about XSOAR, https://xsoar.pan.dev/docs/reference/scripts/wait-and-complete-task

BPry · ‎02-06-2023

@PradeepKShing, Just as a disclaimer to @Raido_Rattameister's suggestion (which is the only way you'd get something like this to actually work), this could also capture way more traffic than what you actually want. I'd highly recommend checking what the FQDN objects would actually include before adopting this solution and deciding if that'll actually work for you in this case. It's possible depending on the site that you'll be including a fair bit more traffic than you actually intent to.

BPry · ‎02-06-2023

@Shadow, Correct. If you just want to capture everything risk 3 and higher, application filters would be the way to actually accomplish this. Just keep in mind what you're actually capturing making such a broad application filter and where you intend to use this new group. There's a whole lot of applications with a risk of 3+ that you might not think about (essentially anything that deals with file transfers, video conferencing applications, SMTP, ssl and web-browsing themselves) that would be captured in this filter.

BPry · ‎02-06-2023

@KelvynYeo, Whenever you use categories as match criteria, the first such rule will get hit in the rulebase as the firewall has to allow enough traffic to pass to see what the domain is going to be. Once it can actually identify the domain in question, it'll continue through the rulebase as you'd expect to verify if there's a matching entry.

BPry · ‎02-06-2023

@Malen_Franks, There was a really old bug in a previous version of PAN-OS (like in the 8.0 or 8.1 days early in that code branch) that you'd occasionally see this message. A commit force at the time fixed the issue until the root cause was actually addressed via an update. If a simple commit force doesn't fix things, you can run 'debug device-server reset id-manager type all' and then do a commit force to completely rebuild the idmgr table, which should clear this error message.

BPry · ‎02-06-2023

@mateuszga, In a situation like this, you're better off managing the client off of the portal itself through another software deployment options (SCCM as an example). This way you can target specific collections however you want, without the limitations of what the firewall presents. This isn't the best solution honestly, and I've seen SCCM and similar solutions cause a few issues during the upgrade process. If you choose to use the above method, I'd honestly split it across portals if you can get away with it. Have one portal for clients that can actually still receive updates directly through GlobalProtect (supported devices), and then have another one for everything else. You can direct the endpoints to the proper portal through Group Policy, but this allows you to actually keep using "normal" upgrade methods for the supported endpoints.

BPry · ‎02-03-2023

@millc5, If you have your own personalized email domain (IE: not gmail.com or similar service), you should be able to setup an account with your vendor and get things registered to yourself without issue. I know that CDW will allow you to easily process this order, you'd just want to ensure you aren't using a free email to avoid issues creating your actual PAN account since that would cause some issues and require you to reach out to support and have your account built manually on the backend.

BPry · ‎02-03-2023

@Pras, If you aren't seeing the associated log on the device itself, it sounds like something with the log-receiver process is just continually stuck processing. You can try restarting that process itself via the 'debug software restart process log-receiver' and seeing if that clears things up if you haven't tried that already. I've assumed that you've tried restarting both units to see if it clears things, but if not that would be my next step. If neither of those things work I'd definitely pass this to TAC to help troubleshoot. You shouldn't be getting email notices if you don't have an associated system log, so something is definitely not being processed properly.

BPry · ‎02-03-2023

@walter35161, You don't appear to be logging your interzone-default policy, for troubleshooting I'd enable that so you can ensure that the traffic is actually being processed properly and isn't getting dropped. Couple things I would look at: Traffic Logs - Do you see this traffic in your current traffic logs at all? If you have it recorded in the logs as being allowed, make sure that you've actually verified via the detailed log view that things are routing properly and going out the proper interface. If you don't have records prior to enabling the interzone-default logging, this traffic wasn't matching your rules and getting dropped. Routing - Kinda covered this above, but make sure that your traffic is actually routing properly via your traffic logs.

BPry · ‎01-31-2023

@amar, It's been a long time since I've worked with Checkpoint in any real capacity (currently I'm more migrating people's configurations from CheckPoint to PAN), but I'd be verifying that the return traffic is actually hitting your HO firewall from the BO. If you aren't seeing the return traffic it's dying on the vine and you'll need to address the BO routing, but if it's making it back to the HO you have some other issue happening with routing or policy that you'll need to address on the HO side of things. So to start with I guess, are you seeing the return traffic make it back from the BO to the HO?

BPry · ‎01-31-2023

@Pras, Just to verify; when you say that you're getting alerts through syslog emailed to you, you simply mean through your log- settings you have it set to email you correct? Do you have the system emailing you directly, or do you pass this to a SIEM and have that emailing you alerts? I've answered this assuming that it's the first and that you have the firewall emailing you system-critical alerts and not passing those alerts through a SIEM. As long as that's the case, I think you'll have to open a TAC case and see if you aren't running into some sort of weird bug. The fact that you're still getting alerts when you've negated the subtype is just weird, and it shouldn't be happening. Lastly have you verified that the alerts you're getting are actually present in the system logs? Just verifying that something hasn't gotten "stuck" and keeps resending alerts that the firewall itself isn't actually identifying.

BPry · ‎01-31-2023

@Pras, Think of the compatibility matrix in this case as more of a listing of what PAN validates things against. Just because you're running an unsupported version of ESXi doesn't exactly mean things will stop working, it just means that PAN isn't validating that it'll work and you're running in an unsupported configuration. Depending on the reason for the auto-commit failure, this could be completely unrelated to the unsupported version of ESXi being utilized. I'm personally not a fan of upgrading VM series across major versions due to issues I've run into in the past, so I always simply rebuild the VMs on the new major version and then migrate the IPs or traffic to the new hosts. The downside of you running in this unsupported manner is that TAC is going to use that to stop troubleshooting as soon as they notice you aren't running on an approved version of ESXi, as it's not validated to actually function properly. That's why you generally want to validate the compatibility matrix prior to an upgrade; unsupported configurations aren't going to get a lot of attention if you run into an issue, even if the root issue is unlikely to be due to the hypervisor.

BPry · ‎01-31-2023

@OgilvyLee18, This shouldn't be an issue at all. Can you install the 6.0.4 or 6.0.5 agent? I know that these units work perfectly fine on M1 devices we have deployed, and It's what I have installed on my own equipment without any issues. I've only tested 6.1.0 on m1 hardware, not specifically m2, but it's worked without any issue.

BPry · ‎01-31-2023

You can verify the action taken by looking at the associated threat logs on the firewall. If it says 'alert' then the firewall didn't block the activity. Personally my default assigned profile has critical and high severity alerts set to reset-both for client and server traffic. This voids the default action so that whatever signatures match this severity aren't allowed by default, and then I can make overrides as required. The downside to this method is that sometimes PAN will set a disruptive signature to alert at first to verify that they don't have any false positives before they change the default action; in this instance if I were to see false positives I need to manually override these specific signatures.

Member Since	‎05-26-2016 07:16 AM
Date Last Visited	‎02-24-2026 02:19 PM
Posts	6,520
Total Likes Received	2296

Online Status	Offline
Date Last Visited	‎02-24-2026 02:19 PM

Unlock your full community experience!

About BPry