About DPoppleton

DPoppleton · ‎01-29-2020

Those are the PAN-DB webcrawlers. I opened a case about this about a month ago.

DPoppleton · ‎01-16-2020

Me too. We had 16 out of 18 firewalls not updating, but they all grabbed the last update without a problem.

DPoppleton · ‎01-13-2020

We are going to have a hybrid environment and need to allow some O365/Exchange traffic inbound from their cloud. They have a JSON list they publish. Can I use that as an EDL to allow the traffic inbound? Or do I need to filter that through something else?

DPoppleton · ‎01-10-2020

Wow, we just noticed this the other day. Since the 12/17 our updates have been failing. Do it manually and it worked fine. I opened a case but they said to restart the management plane.

DPoppleton · ‎09-20-2019

We block the "unknown" category in web browsing. This recently became an issue when an application needed to be accessed by its IP address. If the user hacked his HOSTS file to set the name test.test.test to that IP address, he was able to get to the application. It looks like any URL with the top level domain of 'test' is allowed as "Computer and Internet info". Is this expected behavior?

DPoppleton · ‎08-02-2019

Do you have the URL category applied to a security group profile, and that profile bound to your web-browsing rule?

DPoppleton · ‎08-01-2019

In some cases I have had to put allowed URLs in like this for an entire domain to work: *.allowedURL.*

DPoppleton · ‎06-17-2019

Level 1 support has gotten really bad, and asking to escalate doesn't seem to help. My last few cases have been to change some App-IDs (applications not getting identified correctly) and it could take 2 weeks to get passed to the correct team.

DPoppleton · ‎03-26-2019

@Brandon_Wertz wrote: Good point...Install away!! Hit those bugs before I do. That way when I upgade at 9.0.6+ I don't hit a bug no one has seen yet. I hit a bug in 8.0.15 no one had found yet...

DPoppleton · ‎03-18-2019

Can you share screenshots of the rule? Just looking at the logs, I only see 3 62-byte packets, and the traffic is incomplete. It looks like 3 SYN packets that go nowhere.

DPoppleton · ‎02-25-2019

We changed the target from an FQDN to an IP address and it is working. So it looks like another bug with FQDN. We're not going to celebrate yet as we will give it a few days to ensure it stays working, but it is looking good.

DPoppleton · ‎02-22-2019

It's 8.0.15. I was kind of hoping all the bugs would have been found by now.

DPoppleton · ‎02-22-2019

We have another test window on Monday... I'll let you know how it goes.

DPoppleton · ‎02-22-2019

@BPry the destination is a FQDN. I verified that the name resolved in the firewall by using "request system fqdn show" but I was wondering as well if there is failure with that somewhere.

DPoppleton · ‎02-22-2019

We tried that already. A rule with just the server as the source, and the object it was trying to go to as the destination, any application with a service of tcp/50000. Still fell through to the deny rule at the end as unknown-tcp.

DPoppleton · ‎02-22-2019

It's a pretty simple rule, and worked on 7.1:

DPoppleton · ‎02-22-2019

The rule that is the deny rule is the last rule, catch all.

DPoppleton · ‎02-22-2019

Application and Service are both set to any. And it is the first rule, as this is a very important connection.

DPoppleton · ‎02-22-2019

We are migrating from some 200's running 7.1.x code to 220's running 8.0.x code. We had a rule that was working fine, allowing any traffic from a server to another server. We didn't define any apps or tcp ports. We have that rule in the new firewall, but it is now being blocked as "unknown-tcp". We added a rule allowing any traffic between the servers over the port they use. It still is blocking it as unknown-tcp. Why did this work in 7.1 but not in 8.0? I've gone through the release notes and there is nothing about application ID changes that would effect this. Is an application override the only way to get this to work?

DPoppleton · ‎02-01-2019

Never mind, continued search and I turned up these commands: request system external-list show type predefined-ip name panw-highrisk-ip-list request system external-list show type predefined-ip name panw-known-ip-list

DPoppleton · ‎02-01-2019

Is there an easy way to see what IP addresses are in the PAN Known Malicious IP Addresses or High-Risk IP Addresses feeds? Like a URL with a text or xml of them? I know I can do it in the GUI but I was looking for a quicker way.

DPoppleton · ‎12-13-2018

This isn't caused by the firewall.... I seem to remember a problem with the MLSD command with certain clients or servers while running a passive FTP connection. Try it as an active connection and I think it would work.

DPoppleton · ‎12-07-2018

Have you found a solution to this issue yet?

DPoppleton · ‎12-04-2018

That screen shot shows the application as FTP, which means the FileZilla client isn't encrypting. The client may need to be set to use SFTP (and the firewall will see that as SSH, so you will need to add that application to your rule.)

DPoppleton · ‎12-04-2018

I've had to add the SSH application to many SFTP rules, as the firewall usually sees that. Look in your Unified Logs and it should show you why it was denied.

DPoppleton · ‎10-22-2018

Thanks, Otakar. These are all IP lists though. I was looking for something for DNS sinkholing or blocking requests for malicious domains.

DPoppleton · ‎10-22-2018

Does anyone know any free External Dynamic Lists for DNS signatures to use in conjunction with the Palo DNS Signatures? We would like some extra protection for our anti-spyware protection.

DPoppleton · ‎10-12-2018

https://live.paloaltonetworks.com/t5/Customer-Advisories/Important-customer-information-regarding-PAN-DB/ta-p/235081 Dear Palo Alto Networks customer, On Thursday, October 11, 2018 at 7:01 AM PT, a Microsoft URL used by Office 365 (secure.aadcdn.microsoftonline-p.com) was inadvertently categorized from “Computer-and-internet-info” to “Phishing,” which may have impacted the availability of Office 365. As soon as we discovered the issue at 10:22 AM PT, we re-categorized the URL to “Computer-and-internet-info,” restoring access to impacted users. During the impacted timeframe, customers who have PAN-DB policies to block the “phishing” category would have been unable to access secure.aadcdn.microsoftonline-p.com, potentially preventing authentication to Microsoft Office 365. Root Cause We immediately began investigating the root cause of this important issue and determined it was due to a human error that resulted in the re-categorization from “Computer-and-internet-info” to “Phishing.” We apologize for any inconvenience this may have caused and thank you for your patience as we worked to resolve this issue. Should you have any questions, please don’t hesitate to reach out to your support provider or the Palo Alto Networks Support Team at https://support.paloaltonetworks.com. 10:22am PDT? That's around the time I submitted the URL re-classification 😉

DPoppleton · ‎10-11-2018

Where is the "Customer Advisory Board"?

DPoppleton · ‎10-11-2018

Looking deeper in my logs it looks like we started blocking when our URL DB was upgraded to 20181010:40185

Date Registered	‎10-05-2016 10:38 AM
Date Last Visited	yesterday
Total Messages Posted	67
Total Likes Received	16

Online Status	Offline
Date Last Visited	yesterday

Strata

Prisma

Cortex

About DPoppleton