About BruceBennett

BruceBennett · ‎04-17-2020

If you see it as an application in your traffic monitoring, then you should be able to create a rule, specifically blocking that application before your allow rule. I had to do the same thing with Webdav and Sharepoint in a recent implementation. If the traffic is only showing up as SSL traffic, then I do not think you can specifically block a program/application. Also, since it is SSL type traffic, you will need to do SSL decryption for that traffic before it would be identified as an application other than SSL. Not to go too far on this response, but if it is not a standard application and you are doing SSL decryption, you may be able to create your own custom application that is specific to that WINSCP traffic and block the traffic as described above. Sorry, I do not know much about WINSCP.

BruceBennett · ‎04-07-2020

Hi @nnaik Your articles are great! They will be very useful for our split tunnels. I was also able to modify the PS a little and pull the ExpressRoute addresses too. That is something that I have needed to be able to do in the past, but was not able to find. (edit: I was wrong, I was not getting the ExpressRoute addresses, I will have to keep working on that.) That only leaves my issue with MS Network Location Awareness. Again, thank you very much!

BruceBennett · ‎04-01-2020

@jdelio Thanks for your response. Unfortunately, we have "Premium Partner Support" and I cannot convince them that this needs to be pushed up to PAN Support. They are convinced this is a Microsoft issue. So we opened a case with Microsoft and they are sure it is not their problem. We are stuck between two stubborn support teams at this point. We will get there, just slower than we wanted.

BruceBennett · ‎03-27-2020

@jdelio I appreciate what you guys are doing here, just took me a while to find it. One issue that we are running into is that once we get connected with GP, our O365 apps like Outlook, will say there is no network connection if you try to use it right away. If you take your time to start Outlook there is no problem. So we tracked it down to MS NLA not checking the internet connection fast enough. What can we do to resolve this issue? Thanks again for your team in this challenging time.

BruceBennett · ‎01-10-2020

@vsys_remo That is a good question, because I don't see "the global protect login option on the windows logon screen". Looking at the windows login screen from both PCs, PC1 does show a "GlobalProtect Status:", while PC2 does not. I do not remember taking any different steps between the two PCs, but definitely does stand out as a difference between the two. I thought that part of the configuration was pushed down from the portal configuration, so I am obviously missing a step or something on PC2. My goal is to be able to push this down to the users with the least amount of interaction possible.

BruceBennett · ‎01-10-2020

I am building out a test environment using GP as always-on/prelogon. The issue that I am seeing is that one test user, this seems to work fine and another test user it does not. Both users are running the same PC type and same Windows 10 updates into the same AD environment for in office authentication. Current GP version 4.1.12 (I am trying to resolve this issue before updating to GP 5.0.x, that update is going to be a test against the locked down nature of the PCs in the environment). PC 1: Once logged into Windows, GP uses Windows SSO and authenticates to the portal/gateway and the PC is on-net. PC 2: Once logged into Windows, GP pops up a window with the user account listed but requires a password to continue with the authentication. I am not sure where to look to see what the difference in how GP is functioning on the two PCs. I feel like I have gone through the systems logs thoroughly, but I must be missing something since both PCs are functioning differently.

BruceBennett · ‎12-13-2019

@MickBall Hi, With your users that are seeing the issue: Is it consistently the same users, or does that change? When the users do see the issue, is it as simple as them closing Outlook and opening it up again to fix it?

BruceBennett · ‎12-10-2019

This is interesting because we use O365 and I see the same kind of thing. With initial connection, if you start up Outlook right away, about 50+% of the time you will get exactly what you described in the initial post. Then, you close Outlook and open it again and all is well. It is like the routing is just not there initially and has to figure it out. Since we are using O365, the addresses are very dynamic, so I cannot add the routes. Your insight has helped me understand what is happening and I will have to see what I might be able to get done. Thanks for the post and your resolution.

BruceBennett · ‎12-02-2019

@BPry How do you determine the right settings, are there general guidelines or some reference available?

BruceBennett · ‎12-01-2019

We had PAN Proffessional Services help us with our Azure deployment and they recommended going with individual firewalls and use Azure for load balancing between them. We went in expecting to run actuve/passive HA, but implemented their recommendation and it has been running great since it was installed. Unfortunately, I cannot give you the details behind why the recommendation to not use HA, other that two different PAN Engineers telling us that HA and Azure just don't work well together.

BruceBennett · ‎11-26-2019

Thank you. I found out today the entry needed to be a PTR record. As soon as I changed the entry to one with a PTR record it started working.

BruceBennett · ‎11-21-2019

I am still having a problem with pre-logon in the mornings, but it is connecting after a logout or reboot. One of the things that you may need to look at is the authentication for your pre-logon. If you have the client certificate as required, that may be part of the problem ( I am speculating). I have that set to none and pre-logon works for me after a logout and reboot, just not after a night with the computer off, booting in the morning. Also, I am sure you have them right, but I messed that up the first time setting it up. Do you have the pre-logon agent config as the first config? I am still chasing my demon related to the initial boot of the day, and hope that someone else responds to the thread and has the magic answer, but I wanted to try and help since we are chasing similar issues. Bruce.

BruceBennett · ‎11-19-2019

Thank you for the replies, I appreciate the help. I have decided to back out the internal gateway changes I made and go with no internal gateway for further testing. Unfortunately, I am not going to get to test this with an internal user until next week. Based on the comments, it looks like I was headed the right direction. Testing config: no internal gateway, block access to external gateway, internal host detection enabled. Thanks again to everyone that replied!

BruceBennett · ‎11-18-2019

@vsys_remo That is how I understood what I had read, that I did not have to define an internal gateway as long as the DNS lookup was working. But some working in your response has me questioning it a little. I am confident that I put in the FQDN and IP address correctly, but you mentioned "It tries to resolve the specified IP and if the specified name is coming back from the DNS". if I lookup the address by FQDN I get the IP address, but if I try to look up the IP address, I do not get the FQDN. The direction of that lookup seems odd, but would explain why it is not seeing it as internal. @SteveCantwell I have setup an internal gateway for testing, but it just does not seem like it is necessary, based on Remo's response and the configurations I have looked at. The internal gateway that I setup is pretty basic and will not create a tunnel, so I think it addresses what I need, but will have to wait for my internal test user to become available for testing again. Thank you both for the responses. This one has just got me twisted a bit. I think I am following the steps, and even talking through them with my PAN contact, but things are just not flowing as expected.

BruceBennett · ‎11-18-2019

I am trying to setup GP as always-on (pre-logon) when the user is external and not connect while internal. My understanding was that the internal host detection setting was suppose to let the client know that it was internal and not try to connect to the external gateway. That does not seem to work, or most likely I just did not understand the way it works. Goal: user auto-connects to GP while external and does not connect to GP while internal Current config: external gateway defined and working, internal host detection defined, no internal gateway defined, users can reach the external gateway while connected internal. If I setup a rule to block access to the external gateway while the user is internal the user gets the error message that the gateway/portal is not reachable. Current experience: External: user connects to external gateway is connecting without issue Internal: user still connects to external gateway through the Internet gateway Things tried: add rule to block access to external gateway (user gets message that gateway/portal is not accessible) add internal host detection (does not seem to make any difference) read as many docs and links that I can find to configure this properly I have not setup an internal gateway because I cannot figure out how to set it up to so that the traffic does not go through GP while the user is internal. Any ideas are appreciated.

BruceBennett · ‎11-10-2019

We also have some applications that are using ports other than the standard ports. What we have done is to change the rule associated with the application to use the standard application and we set the specific ports we are using as the service in that rule. This way we get the traffic identified and limit it to our ports.

BruceBennett · ‎11-08-2019

This will be interesting to learn myself. We have a couple of firewalls with two VSYS and the ARP table, with the "show arp all" command it does not have any distinction for VSYS, only interfaces. Thinking about it, the ARP table is showing layer 2 information, tied to interfaces, so I am not sure it would matter if there were separate tables.

BruceBennett · ‎11-08-2019

Before logging a ticket as a potential bug issue, I recommend that you upgrade to 8.1.10 as the recommended current 8.1.x version, link below to the PAN-OS Software Release Guidance. After that upgrade, verify that you are seeing the same issues, and if you are open the ticket at that time. https://live.paloaltonetworks.com/t5/Customer-Resources/Support-PAN-OS-Software-Release-Guidance/ta-p/258304

BruceBennett · ‎11-06-2019

I have had to replace 2 firewalls and the doc is pretty good. I skipped over the backup portion because I have regular backups to work with. The biggest gotcha I ran into was making sure not to overwrite the good config with the blank one when syncing the firewall configs, I have done that. The backups do make that easier to recover from, but it is an outage that you did not plan for. The second pain was transferring the licenses. I did lean on PAN Support a little for that the first time. The second time was a bit easier.

BruceBennett · ‎11-03-2019

You should be good with just the updates.paloaltonetworks.com as the destination url, if you are just getting app and software updates. If you have other things like URL filtering also running on TV he firewall, you will have other URLs that you will need to bypass the SSL intercept.

BruceBennett · ‎11-02-2019

You will need to uncheck the verify box, or set that source and url as no decrypt in a rule before your general decrypt rule.

BruceBennett · ‎11-01-2019

Hi Shehan, The link you provided actually answers your first question, 9.0.4 is the preferred OS for firewalls and Panorama. As for having Panorama one version higher, my understanding is that Panorama must be at the same level or higher to manage the firewalls. The key being "at the same level". I know I try to keep Panorama up to the preferred version listed, but I cannot do the same with my firewalls, as it is a challenge to plan the changes that often. The important thing is that you are safe running the same OS version on Panorama as you are on the firewalls.

BruceBennett · ‎10-31-2019

An update for anyone that looks this up later. This is now solved. We have a mixed environment that is very restrictive, including SSL intercept. In the system logs, we were seeing "CURL ERROR: SSL certificate problem: self signed certificate in certificate chain". In the CLI we were seeing the following with the "tail follow yes mp-log devsrv.log" command: 2019-10-29 22:42:03.319 +0000 Warning: pan_cloud_agent_get_curl_connection(pan_cloud_agent_connect.c:2609): cannot elect a cloud 2019-10-29 22:42:03.319 +0000 curl error: SSL certificate problem: self signed certificate in certificate chain 2019-10-29 22:42:03.320 +0000 Failed to open connection with the cloud after 12360 consecutive tries. 2019-10-29 22:42:04.420 +0000 CLOUD_ELECTION: in wait_t 0 secs. 2019-10-29 22:42:04.544 +0000 Error: verify_cb(pan_ssl_curl_utils.c:614): Error with certificate at depth: 2 2019-10-29 22:42:04.544 +0000 Error: verify_cb(pan_ssl_curl_utils.c:616): Basic Validation of x509 cert Fail ; Code : 19 ... 2019-10-29 22:42:04.544 +0000 Error: verify_cb(pan_ssl_curl_utils.c:625): Failed to validate x509 cert from ctx: (19) self signed certificate in certificate chain 2019-10-29 22:42:04.544 +0000 Warning: pan_cloud_agent_collect_cloud_info_cb(pan_cloud_agent_connect.c:1957): cloud elect connection close I found the available docs were not complete for the changes between 8.x and 9.x PanDB process. In the end, I found that 8.x and 9.x are using different destinations for updates and since 9.x does not use a seed file, it has to reach the destination to get everything going. Here are the destinations that are being used for both: 8.x PanDB - 65.154.226.123 "dl1prod.urlcloud.paloaltonetworks.com" 9.x PanDB - 65.154.226.124 "pandb2qa.urlcloud.paloaltonetworks.com" In the end, it was the SSL intercept that was keeping the access to pandb2qa.urlcloud.paloaltonetworks.com from working. Once SSL intercept was removed everything started working within the next 10 minutes. While you can turn off the "verify update server identity" for updates, this does not appear to be an option with the PanDB access, the certificate chain is verified and will not work with an SSL intercept in the middle. Hopefully I put in enough key words for this to be found if someone else is running into this issue.

BruceBennett · ‎10-22-2019

Unless you are you trying to change the port as part of the translation, you can define the port range as a services object, and then refer to it on the "Original Packet" page of the NAT rule, where you would identify the destination zone and interface. Then your NAT rule will only apply to traffic going to that destination NAT address when it is bound for those ports.

BruceBennett · ‎10-21-2019

I wish I had an answer for you. I see the language in the link that says you should be able to add the 2TB drive without any issues, "If the appliance is in Legacy mode, you can add one virtual logging disk of up to 8TB on ESXi 5.5 and later versions or one disk of up to 2TB on earlier ESXi versions". I just know that the issues that I ran into that PAN support told me that I had to upgrade the mode from legacy to panorama to be able to see the new drive. Good luck.

BruceBennett · ‎10-19-2019

I ran into the same issue when I upgraded from 7 to 8.1. To add the additional logging storage, you have to upgrade your Panorama instance from "legacy" mode to "panorama" mode. Until that is completed, which took me several tries, you will not be able to see the additional drive space. Check out this link for the process: https://docs.paloaltonetworks.com/panorama/8-1/panorama-admin/set-up-panorama/set-up-the-panorama-virtual-appliance/set-up-the-panorama-virtual-appliance-with-local-log-collector.html

BruceBennett · ‎10-15-2019

I have a couple of firewalls that are running Pan-OS 9.0.3 that I cannot get the pandb-database to install and update. At least I cannot prove that it is downloading and active. Until 9/30/19, the 9.0 docs for this were the same as the 8.1 docs. According to the new docs, it looks like PANDB is active, but when I check the status on 9.0, it shows a DB version of 0000.00.00.000. Below are the results from the command "show url-cloud status" for my 9.0 and 8.1 firewalls. 9.0 PAN-DB URL Filtering License : valid Cloud connection : not connected URL database version - device : 0000.00.00.000 URL protocol version - device : pan/0.0.2 8.1 PAN-DB URL Filtering License : valid Cloud connection : not connected URL database version - device : 20190909.20113 URL protocol version - device : pan/0.0.2 When I look in monitor for the 8.1 firewall, I can see url-categories. On the 9.0 firewall, the only url-categories I get are "any" and "not-resolved". That is another indicator that is showing that I do not have a url-database. I have tried several things, especially when the 9.0 docs were not up to date, including trying to manually install using "request url-filtering install pandb-database", which fails because there is no image uploaded. But, if you try to download the database using the "request url-filtering download" command, you can no longer specify "request url-filtering download paloaltonetworks region North-America", in 9.0 once you get to download in the command, the only options available (just pressing tab) comes out with "request url-filtering download status vendor brightcloud". I have the exact same issue on two different 9.0 firewalls, so it does not seem to be something with the firewall, and I have tried this with 9.0.3 and currently with 9.0.3-h3, same results. Unfortunately, I cannot take the firewalls down to 8.1.x and then run the update/download because we are using GRE tunnels on these firewalls, so that is not a viable option.

BruceBennett · ‎10-09-2019

You can download the Pan-OS updates from the support portal, just log in to your support account and download them under the updates tab (https://support.paloaltonetworks.com/Updates/SoftwareUpdates/25603). I do believe that the updates are limited to the series of devices you have already registered, but they are there for the download at that link.

BruceBennett · ‎10-07-2019

Hi, I do not have any experience with Traps, but I do have a lot of experience with app dependencies. I can tell you that you can put in the app-ids successfully without having to have all of the dependencies in place. I have a pair of firewalls that I get nearly 100 warnings related to app-id dependencies. There are several apps with the dependency of web-browsing that I was just not going to add to the rules. Luckily, I was working with PAN Professional Services for this project and confirmed with the Engineer that the dependencies are not "required", they are "recommended", no matter how annoying the warnings are. He did add, if you are having issues related to those rules, you may have to add the dependencies for troubleshooting, but they are not required to run properly. I do have to say, I do not like the warning that I get with each commit, as I need to read through to make sure nothing is new in there from the latest changes, but it is better than adding in all of the dependencies and opening more than I want open. Hope that was helpful

BruceBennett · ‎10-07-2019

@CRDF18 That initially got me too. After looking at the logs and seeing that the traffic accessing the gateway was in the same zone, I went in and created the intrazone rule to block everything other than the specific applications needed, including removing ping access to the gateway. That cut down on a lot of probing traffic. I still think that there are benefits to the Zone Protection Profiles, because you are still open to the Internet, but at least the basic "probe and test" traffic is gone. Next step for me is the Zone Protection Profiles, those take a bit more work to get setup correctly.

Date Registered	‎05-27-2016 12:32 PM
Date Last Visited	Thursday
Total Messages Posted	32
Total Likes Received	11

Online Status	Offline
Date Last Visited	Thursday

Strata

Prisma

Cortex

About BruceBennett