About gwesson

gwesson · ‎07-02-2019

Yep: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClklCAC

gwesson · ‎07-01-2019

You might have an exception for Threat ID 40006 in one or more of your security profiles. A simple way to check your whole config for that can be done in CLI: > show config running hit / (forward slash) to begin searching, and enter: 40006 You'll have to scroll up (using the "J" key, may also work with arrow keys) to the top of that entry to find the profile name, and there may be multiple profiles that have it.

gwesson · ‎05-23-2019

There are some debugs, but they can be dangerous to turn on because of the volume of logs it generates (flow basic + proxy basic). I highly recommend opening a case with support to go through the policy and config to see if they can help with a review of your system before diving in to the debugs.

gwesson · ‎05-23-2019

I apologize, I completely missed that in your original post. No, if you see policy deny, then that session was definitely denied. What is the user experience when this happens? Can the site be browsed as normal if you proceed past the certificate warning? If you can browse normally then the denied session is likely not all that important. I hate leaving something like that unknown, but it all depends on how much time you want to put into research if the user experience is fine.

gwesson · ‎05-23-2019

Is it actually being blocked and you're getting a firewall block page? Or are you saying that your browser shows the certificate as expired even though the firewall is decrypting it? If it's the latter, that is expected. The firewall copies values from the server's certificate to create the decryption certificate. It takes the Subject and the Validity Period values, so if the server's cert or common name/sni are "bad" then the decrypted version will be "bad" as well.

gwesson · ‎05-17-2019

You can search for any covered vulnerabilities by CVE on Threat Vault: https://threatvault.paloaltonetworks.com/ If you don't get a result, then there is no coverage. A lot of times new vulns are announced that are theoretical (like the Zombieload vuln) and it's impossible to cover those without a Proof of Concept.

gwesson · ‎05-16-2019

Are you actually experiencing a problem or are you just curious about the logs? When the keys expire, a new one is received (ike-recv-notify), the old ones expire (ipsec-key-expire), and the old ones are deleted (ike-send-p2-delete). My recommendation would be to set up a single firewall with a single VPN connection and watch the logs as it goes through its normal functions. When you have lots of tunnels, you'll see lots of messaging.

gwesson · ‎05-13-2019

Not directly as an LDAP group, but it can be done with RADIUS: https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-admin/authentication/configure-radius-authentication.html Essentially, you're creating a Vendor Specific Attribute for the users that you want to assign as a device admin, superuser, super reader, etc. It's definitely more work than being able to specify a group, so a filing a feature request with your account team would still be a good idea.

gwesson · ‎04-30-2019

Sorry @Venkatesan_radhakrishnan , I don't know all that much about iOS to be honest. The only experience I had was when I was testing the iOS integration for GP 5.0, and it was limited to what I previously provided in the thread you're likely referencing. That really does sound like a better question to ask Apple, since you're doing MDM+iOS actions. I would recommend getting their support involved to see if they can iron out the issue you're seeing.

gwesson · ‎04-29-2019

I have to get this out of the way first: Please upgrade to a more current code version. 8.0.9 was released over a year ago and has several vulnerabilities at medium or high priority. Unpatched devices are the most common vectors for attacks. Also, 8.0 has six months before it is End of Life as well, so that might be a good opportunity to begin upgrading to 8.1, which is supported on the PA-5000 series until 2024. PAN-SA-2019-0002 (High). Cross site scripting (XSS) vulnerability in the management interface. Fixed in 8.0.15. PAN-SA-2018-0008 (High). Denial of Service (DoS) in the management interface. Fixed in 8.0.10. PAN-SA-2018-0009 (medium). XSS in the GP login page. Fixed in 8.0.11. PAN-SA-2018-0015 (medium). OpenSSL vulnerabilities. Fixed in 8.0.13. PAN-SA-2018-0012 (medium). FragmentSmack vulnerability. Fixed in 8.0.13. PAN-SA-2019-0001 (medium). XSS in external dynamic lists. Fixed in 8.0.15. PAN-SA-2019-0007 (medium). DoS in the management interface. Fixed in 8.0.16. With that said, it depends on how much logging you are doing. Check your logging rate (debug log-receiver statistics) to see where you're at for logs/second. Even with aggressive cleaning the system may simply be getting so many logs it cannot keep up. You may be able to reduce that as well. Make sure you're not logging at session start, don't log on the default deny rule (logging is disabled by default on it). You may also want to exclude logging for things like NTP, DNS, Ping, etc. by disabling the 'log at session end' in a rule dedicated just to that type of traffic.

gwesson · ‎04-29-2019

No, not on Windows. Only the GlobalProtect client is officially supported. See X-Auth IPSec Client Support. You might be able to get it to work using X-Auth, but you won't be able to get tech support if you run into trouble since it's not on the official list of supported clients. Instead, I would recommend including GP as part of your initial image, or push the software via group policy.

gwesson · ‎04-29-2019

Just make sure that: 1. The user is in the group when you look at the DC. 2. You have that group added to the group-mapping section I mentioned earlier. 3. You do not have more than the device limit on the number of groups. You can show group mappings with: > show user user-ids all > show user user-ids match-user UserNameInQuestion

gwesson · ‎04-29-2019

You can run these CLI commands, depending on what you want to show > show user ip-user-mapping all > show user ip-user-mapping-mp all > show user ip-user-mapping ip 192.0.2.1 > show user ip-user-mapping ip 192.0.2.1/24 The first shows the mapping on the dataplane, the second on the management plane. The 3rd and 4th are for specific IPs or subnets. Since you already have the mapping configured, captive portal should work for any web traffic. Even if the CP doesn't trigger, the policy is still checking the user and so it should fail to match the rule if it's user/group based. You may want to review the traffic logs for one of those sessions to see what user it did show up as. If the log shows no user and the policy that it shows is only user-based it should not match. If your policy is group-based, then the user-id part is likely working, which would explain the lack of a CP. If this is the case, you'll want to make sure your group-mapping (Device tab > User Identification > Group Mapping Settings tab) has the correct mappings configured and that the number of groups you're using there does not exceed the device maximum.

gwesson · ‎04-29-2019

Captive Portal is strictly for authenticating users, it isn't something that can be used like an acceptable use policy. If there are users who have already authenticated, meaning you have a user-ip-mapping for them, then that user will not get the captive portal. Ideally all your users should be authenticated by having the firewall (or dedicated User-ID Agent) scan the logs on the domain controller to map the users' IPs. I'm not sure how you're leveraging CP to do this, because generally if you want to restrict users or groups, you can do that with a security policy.

gwesson · ‎04-26-2019

The enterprise CA that signed the CSR failed to ensure it is a actually a CA cert, sometimes known as a Signing cert or Delegation cert. It's not very obvious in that document, so it can be missed. When you send the CSR to the enterprise CA, they must make it a signing/delegation/ca certificate or it cannot be used to sign the on-the-fly certificates the firewall generates when doing decryption. Without that, it is just a normal server certificate. You don't have to go through the whole process again, you can just have the CA re-sign the CSR you gave, ensuring it is a CA cert as well.

gwesson · ‎04-26-2019

> Do these options actually change the DSCP value from best effort to EF? If I look in the header I should see EF afterwards without needing to change the DSCP on the internal client app machines is that correct? Yep! It modifies it prior to egress: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClKrCAK

gwesson · ‎04-25-2019

There are a couple options: 1. If you want to set it on a specific type of traffic regardless of security rules, you can add a QoS policy for it to add the DSCP/ToS values. Policies > QoS > Add > DSCP/ToS tab > Add. Name: your choice Type: EF If you don't want just EF, you can select others or even write a custom value (in binary). 2. If you want to base it on specific security policies instead, you can open your security policy for this traffic and add a QoS marking: Policies > Security > your_rule > Actions tab > Other Settings section > QoS Marking. Chose IP DSCP and a new drop-down appears. EF should be there, and should be 101110 in binary.

gwesson · ‎04-25-2019

It's normal, support will likely direct you to disable the alerts if it bothers you. The evasion detection is prone to false positives because it is a very simple check. I had to dig, but found it from the 7.1 New Features Guide: Setting up this evasion prevention feature enables the firewall to check that the hostname or SNI indicated in an initial HTTP or TLS request corresponds to the destination IP address for the connecting client. The problem is that if the firewall's DNS query for the hostname/SNI happens to get a different address, this signature will trigger even if it is a valid address. Personally, I've disabled the logging for those two signatures by setting them to "allow" instead of alert or higher:

gwesson · ‎04-25-2019

You will need to create a new rule above the one that blocks China. Just put in that IP you want to allow and tighten down the rest of the parameters you want (zones, users, apps, ports, etc.). Rules do have the option of negating the addresses, but it's all the addresses in the rule, so you cannot have a single IP negated while leaving China non-negated.

gwesson · ‎04-25-2019

You'll need to acknowledge the alarm before it will clear, as long as whatever caused it is no longer present. https://docs.paloaltonetworks.com/pan-os/8-1/pan-os-web-interface-help/web-interface-basics/alarms.html In your GUI, there should be an icon at the bottom. Click that, select the log(s) you want to acknowledge and then they should go away. That should also clear the LED on the chassis as well.

gwesson · ‎04-24-2019

Yep. When the first packet (a SYN for a TCP connection) is assigned a session ID it moves from INIT to Opening then almost immediately to Active. You would be lucky to get a "show session id" output that has any of the transient states, they're super fast. Microseconds fast.

gwesson · ‎04-24-2019

A couple things you may be able to test to see what's going on: 1. Dump the fib table. It won't help for your PBF rule, but since your VR has a static route it should show that correctly: > show routing route 2. Test the routing to see what the firewall thinks the correct route should be: > test routing fib-lookup virtual-router your_vr_name ip 2a00:1450:4001... The virtual router will always take a more specific route, so make sure your eth1/1 route doesn't have a more specific IPv6 route that is overriding your static route. It may also be helpful to see what your static route and PBF policy does (if you can sanitize it for public consumption here in the forums).

gwesson · ‎04-24-2019

Init means it's not an active session. Full breakdown here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clk9CAC Short answer: when a session ends, the session state retuns to INIT. You can still see the most recent session details that used that particular session ID until new traffic allocates that ID.

gwesson · ‎04-22-2019

Officially, no support for Windows Server 2019 yet: https://docs.paloaltonetworks.com/compatibility-matrix/user-id-agent/where-can-i-install-the-user-id-agent.html The 9.0 agent will work fine with PAN-OS 8.0.16, you don't need to be running the same major/minor version. It's fairly uncommon though, so take that with a grain of salt.

gwesson · ‎04-18-2019

The continue page is a category-based timer. Once the user hits the continue button, they can browse to that category without getting the continue page again for 15 minutes (I think). Could the traffic you're seeing be in that window of time? You can use the URL response pages, including continue, without a full blown decryption environment, but it is still technically decrypting: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFKCA0

gwesson · ‎04-16-2019

You just plug it in and it boots. Since yours is stuck on an error when you try, there's literally nothing more you can do. You also won't be able to get support on it, you can't run traffic through it, and you can't get the dynamic updates (apps, threats, etc.). AWS is something like $1/hour if you just want to play with a firewall. But that 2020 is really just e-waste at this point.

gwesson · ‎04-16-2019

Unfortunately, there's nothing useful you can do with that device. The PA-2000 series is End of Sale as of 2015, and will be End of Life in about a year. Because of that EoS status, you won't be able to purchase a support contract or get any licenses for it. The Secondary Market Policy has the details. Your best bet for on-the-cheap learning is a cloud license (AWS, Azure, etc.), a lab license on a VM (talk to your account team), or a PA-220.

gwesson · ‎04-12-2019

If the sessions have already started when you set your capture filter, it will not output anything. In addition to the 'clear filter-marked-sessions' command you tried, you may also want to clear the active sessions (assuming an interruption to those is ok): > clear session all filter source 192.168.180.210 You can also check to see if your filters are matching before you actually attempt to capture by running a delta against the counters using that filter: > show counter global filter packet-filter yes delta yes The first time you run the command you'll probably get a big output, but each subsequent time you run it the output will just be a delta between the last time you ran it. If you're seeing packet numbers increment, you can start the capture and should see the same number of packets there.

gwesson · ‎04-12-2019

Routing is the most common issue I see for this symptom. Are you doing source-NAT for your GlobalProtect clients? Recall that the gateway config on the firewall defines the source IP pools for your clients, and assigns them based on that. If you are not doing NAT, then you'll just need to ensure that the networks you're trying to reach understand that they have to send the replies back to the firewall. If there's a more general/broad route on those networks' gateways, you'll need to use a more specific route for your GP clients source pool.

gwesson · ‎04-10-2019

In all three scenarios, you're still using a single download. There are bottlenecks that can be associated with a single session (and even more when it comes to IPSec). Things like encapsulation/decapsulation and how it is split across multiple cores, and a whole host of things. The datasheet numbers are for scale, not for individual downloads from a single client. I don't want to come across as harsh, I just can't think of a better way to say it. A single download is VASTLY different than real clients connecting and doing regular work. If you insist on using this type of flawed testing, at the very least try doing several downloads at the same time from different sites on that test client at site B. At least then you'll be using multiple sessions to fill the tunnel better.

Date Registered	‎03-27-2012 04:23 PM
Date Last Visited	‎10-10-2019 02:19 PM
Total Messages Posted	735
Total Likes Received	262

Online Status	Offline
Date Last Visited	‎10-10-2019 02:19 PM

Strata

Prisma

Cortex

About gwesson