About swhyte

swhyte · ‎01-29-2013

The PA does not have an application signature for gmail web messenger, but it does have a signature for gmail-chat and gmail-video-chat. So depending on what the PA actually identifies the traffic as, is what you should add to your policy to be blocked.

swhyte · ‎01-23-2013

Hello, you can currently run custom reports for the specific domains by using the query builder under custom reports. However, I believe you are referring to administrators for the PA...for that you would need to pursue an enhancement request with your sales contact.

swhyte · ‎01-23-2013

hello, Is this still an issue for you? this would require a little additional investigation to see what is going on. Is the user able to connect to netconnect/global protect before the service crashes? If not, a simultaneous packet capture from the client and the PA device along with the collected logs from netconnect/global protect should reveal what is going on.

swhyte · ‎01-16-2013

Hi Ray, Yes...you can certainly configure this on the PA device.

swhyte · ‎01-16-2013

Currently it is possible to tunnel other applications through SSH by enabling port forwarding on SSH. This can be considered a security risk because a user could potentially circumvent the application based security policies on the Paloalto device. The Paloalto device is able to address this risk with the ssh proxy feature. Via a decryption policy, you can configure the PA to decrypt a ssh session and if the users does any ssh port forwarding, remote forwarding or X11, the session will be determined to be ssh tunnel. In turn action can be taken on the ssh tunnel application according to the security policies. It is important to note the following: 1. The same "man in the middle" method for SSL decryption is used for SSH proxy. 2. Also, currently the PA only supports SSH version 2.....(if the client only supports SSH version 1, when it receives the version string from the Paloalto device, it should exit). 3. Content and threat inspection is not done on the SSH Tunnel session.

swhyte · ‎10-24-2012

Hi Scud, not sure if you already got a response on this, but I tried replicating this exact scenario using 4.1.8 panorama and 4.0.13 device. I was not successful in replicating this....creating the zone and adding the option to enable user identification went fine via the context of Panorama. You may have encountered a bug that has since been resolved. You may want to upgrade Panorama to 4.1.7 or 4.1.8 and retest. If you are still having this issue then feel free to call in to support so we can take a deeper look. Perhaps there are other details necessary to properly replicate this. Stephen

swhyte · ‎06-05-2012

Fyi, This happening under conditions when there was some query going on and the key file is being written simultaneously and thus changing/corrupting the the ssh key. The permanent fix for this will be in 4.0.12 which is targeted to be available the week of 6-11-2012.

swhyte · ‎07-04-2011

Hi Sam, the 2000 series Pan is definitely suitable for 4.0.3. The commit times are indeed slower than the higher models due to cpu...but remember that is only for management. If the commit times are taking more than 10 mins then please get techsupport and report this to PA support. Otherwise the development team at Paloalto is aware of the slower commit times and are always working to improve them....so you will see the commit times improve with future releases. thank you, Stephen

swhyte · ‎07-04-2011

Hello Neil, if you can get a packet capture of this traffic, then you can open a case with support and they can refer this to the content team to verify if this is indeed a false positive. thanks, Stephen

swhyte · ‎07-04-2011

The PA may have detected a threat or a file type that you are blocking or QOS may be throttling the session (that is if you have QOS configured). To aid in isolating you can create a policy for these sessions and not add a profile to the policy. If the downloads are still stopping, you can call in to support to aid in troubleshooting this. thanks, Stephen

swhyte · ‎11-22-2010

This is not supported. Stephen

swhyte · ‎11-22-2010

If you must keep the public addresses on the Forefront and absolutely NO NAT. Then what about setting up a virtual wire pair on the paloalto device and plugging the forefront into the trust side of it...You can plug the untrust side of the virutal wire pair into what ever switch you currently have the forefront plugged in to. thanks, Stephen

swhyte · ‎11-17-2010

Hello, the paloalto device will log traffic as long as the traffic matches a policy and that policy is configured to log at session end and/or log as session start. So the only way to avoid the double logging would be to turn off logging at session end and start on the vwire policies.....not sure if you would want to do that though. Stephen

swhyte · ‎11-17-2010

Hello, your sales contact would be the best resource for tracking on a feature request that you submitted. But regarding this feature, it will be in our NICE release which is scheduled to be available by the beginning of 2011. thanks, Stephen

swhyte · ‎11-16-2010

Hello Jambulo, the only way to do this is to create another vulnerability profile, add the desired exception, then create another policy that details your desired granularity (source ip, destination ip, etc..) and add that new vulnerability profile to it. thanks, Stephen

swhyte · ‎11-16-2010

Hello DJ, you will need to create another url filtering profile that contanins all of the blocked cateogories of your main url filtering profile. Then make your desired changes for the other groups (add to the allow list or change the action of which ever category). Then add this new url filtering profile to what ever policy you have created for the specific groups. thank you, Stephen

swhyte · ‎09-17-2010

This is about right. We have several corporate paloalto devices and right now one is at 8mb free and the other is at 21mb free. So this is normal. thanks, Stephen

swhyte · ‎09-17-2010

You MAY be running into a known issue. Can you issue the following command from the cli: >debug dataplane reset ssl-decrypt certificate-cache Then try to go to any ssl sites that your were having problems with before. If you are now able to access the site then you are probably encountering and issue with our ssl certificate cache that is addressed in software version 3.1.5. If not, then please call into support in order that we can take a closer look at this issue. thanks, Stephen

swhyte · ‎09-17-2010

Captive portal supports authentication via radius, ldap, or local db (this would be users configured on the paloalto device). thanks, Stephen

swhyte · ‎09-15-2010

Hello, thanks for the heads up. This is actually good information. Can you send in an email to support@paloaltonetworks.com with this same information. This can then be forwarded to our content team and we can fix this in about 1 week. Can you include the following in your email: serial number of your device software version content version virus version if applicable the pcap the threat id the name of the threat thanks again, Stephen

swhyte · ‎09-15-2010

Hello, memory utiliazation may be high post upgrading to 3.1.x from 3.0.x. The pan device is actually busy converting log files into the correct format for 3.1.x. This should not last forever though. If this lasts more than two days, please call into support. thanks, Stephen

swhyte · ‎09-13-2010

There is currently no way to do this.

swhyte · ‎09-13-2010

Hi, your custom url category action will supercede the brightcloud category action. In a nutshell the logic is as follows: allow list block list custom category brightcloud category thanks, Stephen

swhyte · ‎09-01-2010

Hi Keith, there is no way to track the creation of a CVE through the pan device. You can send in a email to support@paloaltonetworks.com with specific detail on the CVE and support can generate a case to track it with our content team...and then get back to you. thanks, Stephen

swhyte · ‎08-10-2010

Yes, you can do this. Simply, configure a log forwarding profile under device-log destinations-email.Then go to the policies tab. Find all of the policies that you have added a url filtering profile to that blocks urls. Then click on options on those policies, select "new" next to the drop for the log forwarding profile. Then type in a name for the log forwarding profile and select the drop down under "email" and choose the log destination that you previously configured. Also FYI, you can also create a log forwarding profile under objects-log forwarding. Then you can just append it to any policy that you like. thanks, Stephen

swhyte · ‎07-30-2010

Hello Johnny, you can issue the following command from the cli: show system logdb-quota ......take a look at the following document: https://live.paloaltonetworks.com/docs/DOC-1213 It should answer your question. thanks, Stephen

swhyte · ‎07-28-2010

Hi Samuel, this is fine. This has to do with the "passive link state" option in your HA configuration. It is probably set to shut down which is normal. Take a look at the admin guide in reference to "passive link state": Passive Link State Choose from the following options: • auto —Causes the link status to reflect physical connectivity, but discards all packets received. This option is supported in Layer 3 mode. The auto option is desirable, if it is feasible for your network. • shutdown —Forces the interface link to the down state. This is the default option, which ensures that loops are not created in the network.

swhyte · ‎07-28-2010

Hi KH, can you call into support. This is something we will need to take a look at. We will need the techsupport from Panorama. If Panorama is at 100% CPU, we need to check to see if it is due to some process. At the very least, a 'show system resource' output will also help. thanks, Stephen Whyte

swhyte · ‎07-28-2010

You can check in the ms.log via the cli for messages regarding the generation of reports. This may not be very beneficail to you regarding isolating the root of the problem. You will probably need to call into support to take a deeper look at what is going on. However, by far the most common reason why custom reports do not run is because you forgot to select "scheduled" on the report settings.....so please make sure and check that. thanks, Stephen Whyte

swhyte · ‎07-27-2010

Hi Jeff, that is not normal. Hopefully there isn't a duplicate IP in the network. If you are still experiencing this, you should call into support in order that we can take a look.Or you can prepare a techsupport file and specify the exact time of the incident in an email and send that to support. thanks Stephen

Date Registered	‎05-01-2009 11:30 AM
Date Last Visited	‎08-07-2020 07:40 PM
Total Messages Posted	130
Total Likes Received	26

Online Status	Offline
Date Last Visited	‎08-07-2020 07:40 PM

Strata

Prisma

Cortex

About swhyte