This website uses cookies essential to its operation, for analytics, and for personalized content. By continuing to browse this site, you acknowledge the use of cookies.
For details on cookie usage on our site, read our Privacy Policy
For details on cookie usage on our site, read our Privacy Policy
About cosx
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- LIVEcommunity
- About cosx
01-14-2019
26Posts
3Likes
0Solutions
Jan 14, 2019Last Visited
User
Activity
User
Profile
Latest posts by cosx
| Subject | Views | Posted |
|---|---|---|
| 1951 | 11-12-2015 04:51 PM | |
| 3129 | 11-12-2015 04:46 PM | |
| 1962 | 11-11-2015 01:18 PM | |
| 1904 | 10-16-2015 03:54 PM | |
| 2213 | 03-27-2015 09:18 AM |
My Liked Posts
| Subject | Likes | Posted |
|---|---|---|
| 1 Like | 11-30-2012 02:49 PM | |
| 1 Like | 03-26-2015 02:10 PM | |
| 1 Like | 08-26-2013 03:44 PM |
User Badges
Community Statistics
| Member Since | 06-14-2011 01:52 PM |
| Date Last Visited | 01-14-2019 01:28 AM |
| Posts | 26 |
| Total Likes Received | 3 |
11-12-2015
04:51 PM
Running 6.1.2 and keep up-to-date with the application-threat updates.
Yeah, it all worked fine when we weren't allowing quic. We didn't start seeing problems until we expressly allowed it.
... View more
11-12-2015
04:46 PM
If you are using a loopback address that is in the same range as the Ethernet interface, are you sure that the provider router is finding the loopback via ARP? Since the address is local to the provider's address on that link, it is going to try to resolve it directly rather than route it to your firewall on the next-hop address.
FWIW, we terminate a bunch of VPNs on a loopback, and it works fine. The loopback is "behind" the firewall from the provider router's point of view, so it routes to the firewall as the next hop.
... View more
11-11-2015
01:18 PM
We started getting complaints from users that various Google services were showing intermittent disconnects. I think we've tracked it down to the QUIC protocol not being accurately identified by the PAN firewalls and getting blocked. I see 443/udp traffic from the hosts in question getting dropped as "unidentified-udp" mixed in with the allowed "quic" traffic on the same ports to the same general set of Google servers. Google has been rolling out QUIC for a while now, but we only recently allowed it in the firewall. It's been since then that we've seen the Google issues start.
I am considering adding a rule allowing "any" application out on 443/udp as a workaround. Has anyone else seen similar problems? That is, do you allow "quic" out to the Internet, but otherwise would drop 443/udp and see or not see this issue? Did you implement a workaround like this or something else? (BTW, I am not overly concerned about the security implications. PAN firewalls don't understand the QUIC traffic like HTTPS to guess at the Google "applications" inside.)
... View more
10-16-2015
03:54 PM
From what I understand, you need to explicitly allow "depends on" apps for a given app to work,
https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Check-if-an-Application-Needs-Explicitly-Allowed/ta-p/61893
However, what if I want to only allow the "child" application, but not the parent?
My example is "logmein." We explicitly block it since it violates policies to have employees to set up their own remote access into our network. However, Microsoft uses LogMeIn as a support tool. I think that functionality is the "logmeinrescue" application.
So how can I set up my security policy to allow logmeinrescue, but not allow generic logmein? I'm not sure if it is possible.
... View more
03-27-2015
09:18 AM
Yes, I can limit source IP addresses at either the Interface Mangement level or within the Security Policy. But any administrator will then be able to access from the allowed IP addresses. I want to restrict some IP addresses to only certain administrators. For example, the administrator "johndoe" can only access HTTPS or SSH management via the management interface and/or from 10.100.0.0/16. Another user, "joefailsafe," can get in over an Internet-facing interface from <some-public-internet>/29 addresses. Whether joefailsafe also has access via the management interface and internal IPs, I don't care. What I do not want is for johndoe to be able to get in from the Internet at <some-public-internet>/29. Using the features mentioned in the two previous responses, there is no difference in accessibility for johndoe and joefailsafe. (Again, I'm not sure that there is a way to do this in PANOS. I thought I had seen the feature somewhere, but now I'm pretty sure I must have imagined it or be confusing our firewalls with some other device/OS.)
... View more
Contact Me
| Online Status |
Offline
|
| Date Last Visited |
01-14-2019
01:28 AM
|
Latest Tags
No tags yet
LEGAL NOTICES
Copyright 2007 - 2023 - Palo Alto Networks