About fjwcash

fjwcash

I use an LE cert for our GP Portal. And the Web UI for each firewall. The only thing we don't use LE certs for is the rest of the GP infrastructure (gateways and clients). That's all done using the self-signed, trusted ca cert on the portal. We use DNS-based checks for creating the LE certs. No web server required. Currently using dehydrated (python script) as it was the first one that I found that supports DNS challenge and hook script support. Renewing the certs is completely automated. The only manual part is copying the cert to the firewall, as I haven't gone through all the testing to get it working via the XML API. 🙂

fjwcash · ‎03-27-2020

Aha! Got it to work with the help of Palo Alto support. With OpenLDAP, you have to match the Domain Name in the LDAP Server Profile, the Authentication Profile, and the Group Mapping (and it doesn't like . in the domain). We had it matched across them all, but using sub.sub.tld for the domain, which it doesn't like. And, in the Portal config, when you list the group, you have to use the full LDAP cn=groupname,ou=users,dc=sub,dc=sub,dc=tld. It doesn't like using the domain\groupname short-name format. With those two settings changed, listsing just the group in the Portal config allows users in that group in LDAP to login!

fjwcash · ‎03-24-2020

Panorama 8.1.13 PanOS 8.1.9-h4 on the Portal PanOS 8.1.13 on the Gateways Using OpenLDAP on the directory servers, so the LDAP config uses "other".

fjwcash · ‎03-24-2020

What's the magic incantation needed to use LDAP groups in the GlobalProtect Portal user/group list? Instead of listing all umpteen dozen individual users. I have a working GP Portal and multiple Gateway setup, using LDAP for authentication. I have a working Group Mapping setup using groups from LDAP. I can use "show user group list" and see all my LDAP groups. I can use "show user group name mydomain\mygroup" (the shortname for it) to view all the members of the group. And I can run "show user user-ids match-user myuser" to see which group(s) a user is in. In the Portal config, I can add individual users to the user/group list for each individual Gateway. But, with the number of VPN users increasing the past couple of weeks, it's getting cumbersome to edit the config, commit to Panorama, and push tot he firewalls. Would be much nicer to just put an LDAP group in here, and update the member list in LDAP instead. I just can't make this work! If I remove a test user from the Portal config, and replace it with an LDAP group (which that test user is a member of), then I get "Not authorized to access GlobalProtect Portal". Tried the shortname for the group, mydomain\shortname, and the full cn=mygroup,ou=groups... syntax. Same result for each. What am I missing? Edit: This is on Panorama 8.1.13, PanOS 8.1.9-h4 on the Portal, 8.1.13 on the Gateways. Edit2: Further troubleshooting, running "test authentication" from the CLI on the portal and the gateway succeeds. But, we already knew the LDAP config worked; it's trying to use the LDAP group on the Portal Config that's failing. And there doesn't appear to be a way to test that at the CLI, or to get better logs.

fjwcash · ‎01-29-2020

The way it was explained to us in the 8.1 training course was along the lines of "the first server in the list to respond after boot is the only one it will use" or something along those lines. The instructor actually questioned why they allow multiple servers to be listed in a single Server Profile when it doesn't actually work the way you expect, but was never able to get a straight answer about it. If you actually want it to failover to another LDAP server, then you need to use a single server per LDAP Server Profile, and list all of those in an Authentication Sequence.

fjwcash · ‎01-28-2020

Create 4 separate LDAP Server Profiles. Assign them to 4 separate Authentication Profiles. List all 4 in the Authentication Sequence. The LDAP Server Profiles don't fail-through to the next one. It tries the first one, and only if it gets a specific response from it will it try the second one. The Authentication Sequence is where you list all the servers you want it to try, and the order to try them in. The first one to respond with "allowed" ends the sequence. If none of them return an "allowed" response, then the authentication fails.

fjwcash · ‎01-28-2020

Thanks! I've reached out to cast our vote. Let's see what comes of it. 😄

fjwcash · ‎01-27-2020

Specifically, why can't we disable the SIP ALG in Panorama, in order to push that out to the firewalls? Even more specifically, why isn't that option available in the Panorama GUI? It's a real pain having to manually change that on each individual firewall, and commit the change locally, instead of setting it once in a Device Group and having it inherited by all the firewalls. Panorama 8.1.9-h4 and PanOS 8.1.12 on the firewalls.

fjwcash · ‎01-15-2020

What version of PanOS are you running? On 8.1.12, the only ciphers available are the ones listed above, there are no others available to choose from. And , if I try to force my SSH client to connect using SSHv1, I get this: Protocol major versions differ: 1 vs. 2 So, it looks like with 8.1 and higher, SSHv1 has been disabled completely.

fjwcash · ‎01-15-2020

Panorama tab --> Managed Devices --> Summary Click the PDF/CSV export icon at the bottom of the list. Voila! More information that you'll ever need (including serial numbers and PanOS versions), in a fancy PDF or simple text file. Works just fine on PanOS 8.1.12. Whoops, just noticed this is a thread from 2016. 🙂

fjwcash · ‎01-14-2020

As with any large-scale support system, it's hit and miss. My last ticket was put in online with a low-ish priority, so wasn't expecting any response for a couple of days. Within a couple of hours, had received an e-mail, uploaded some files, and had it confirmed as an issue, and it was forwarded off to engineering for a fix. The ticket before that, the support tech continuously asked me questions that were answered in the message they were responding to, asked me to do things that were already done, and it became very apparent they were just reading off a script. Any dead hardware tickets that have been put in have had a replacement on our doorstep within 48 hours (I think we've replaced 2 PA200s and a PA500 in the last 5 years?). I don't think I've ever used the phone support, it's all e-mail and online tickets. So, it depends who picks up your ticket, which shift they're on, how knowledgeable they are, etc. Sometimes you strike gold, other times you find some shiny ferrite. 🙂

fjwcash · ‎01-06-2020

Check your logs and (if this is an ISP link) get the ISP to check their router logs, to make sure you weren't hit by a UDP flood or other DoS/DDoS attack. Prior to configuring Zone Protection and DoS Protection Profiles, and having our ISP configure DoS protection/monitoring on their end, we'd lose OSPF due to UDP floods preventing OSPF packets from getting through. UDP flood attacks are generally very short in duration, under a minute or two, so they won't always show up in logs/monitoring tools unless you specifically look for them, but they'll easily saturate a gigabit link. We had several of these attacks over the past year, and our PA-3020s couldn't handle the traffic (overload the session table) and we'd lose OSPF on our internal network. We switches to PA-5220s this fall, and still suffered OSPF drops due to link saturation on our gigabit link. We now have ZPP/DoS enabled, and our ISP is monitoring for DDoS attacks (anything over 3 minutes in length is automatically shutdown at the ISP side).

fjwcash · ‎01-03-2020

TAC has reproduced the issue and passed it along to Engineering to devise a fix.

fjwcash · ‎01-03-2020

@Rajesh12 wrote: Agreed @fjwcash . I actually had the same issue now with Panorama sending its private IP in the POST message. Luckily my firewall had internal connection also. So for now I was just relying on service routes to solve this. Any idea why they have changed this behavior? Also if we update public IP of panorama in mgmt interface settings, will the POST message in payload will be updated with public IP? No idea why they moved to using a scheduled push from Panorama to initiate a pull from the firewall, when the previous push from Panorama worked so well. Seems backwards to me, but I don't work for Palo Alto. They must have their reasons. Why they have Panorama send it's management IP address in the payload data of the connection is beyond me, when they could just use the Panorama Server IP that's already set on the firewalls. What's the point of setting it on the firewalls if you aren't going to use that for everything Panorama-related? Yes, if you update the Public IP Address setting for the Panorama management interface, that is the IP address that will be used for the scheduled updates connections from the firewalls to Panorama.

fjwcash · ‎01-02-2020

One HUGE caveat to the new setup: Palo Alto has gone back to the 80s and reproduced all the issues with FTP in their stupid/braindead updates protocol. Namely, that they embed the IP of the Panorama server INSIDE the data payload of the IP packets, instead of using the "Panorama IP" set in the Device tab of the managed firewall. Thus, if your Panorama server is behind a NAT, and your remote firewalls are configured to connect to Panorama via the public IP, these new "pushed pulls" will fail (the private IP of the Panorama server is passed through as part of the TCP payload). Instead of fixing their braindead protocol, they added a new configuration setting: Panorama tab --> Setup --> Interfaces sub-tab --> Management. In there, you have to manually enter the public/NAT IP for the Panorama server. Virtually every other protocol released since the 90s has been NAT-aware due to all the issues with PASV/ACTV FTP shenanigans, but Palo Alto decided (in 2019) to released a broken protocol that can't work through NAT without special steps. The more I use PanOS 8.1, the more I long for the days of 7.1. It seems to be two steps forward, 1 step backward with ever minor release. 😞

fjwcash · ‎01-02-2020

Now running Panorama 8.1.12. The export to CSV and PDF shows proper text now instead of HTML/Javascript code. However, the export is essentially useless as it doesn't show Address Object names, it just shows: [object Object] Can't really do a print-out of the Security/NAT Policies to audit them on paper if every rule is essentially unreadable. I've attached a sample of the NAT Policy export to PDF (the CSV looks the same). The first 9 columns are readable with Address Object names shown. Every column after that just shows [object Object]. I've opened a support case for this, as it's now 3 versions later and still not fixed.

fjwcash · ‎12-20-2019

This is very handy, thanks for the link. Now I just need to figure out how to make it work with our dehydrated setup. 🙂 Although, since we do everything via Panorama, this might not be as useful; I'm not sure I'd want an automated push to 52 firewalls ...

fjwcash · ‎12-10-2019

You install Nginx onto a server. You configure it as a reverse proxy, add all your SSL certificates to it, and configure it to accept incoming SSL connections for servername.mydomain.com (the domain of your actual webserver). Then you configure it to use standard HTTP to connect to your real webserver. On the firewall, you allow SSL traffic through to the Nginx server. You NAT the public IP of the webserver to the private IP of the Nginx server. Client connects to https://servername.mydomain.com which sends SSL traffic to the public IP. The firewall NAT's that to the Nginx private IP. Nginx is the end-point for the SSL connection, using the SSL certificates for servername.mydomain.com. Then it opens an HTTP connection to the private IP of the actual webserver. As far as the client knows, it's connected to the webserver using encrypted HTTPS. As far as the webserver knows, it's connected to the client using plain HTTP. And everyone is happy and gets the data they want. 🙂

fjwcash · ‎12-10-2019

Oh, wait, you're right, I'm confusing things. The firewall intercepts the SSL traffic from the client and becomes the end-point for the SSL connection, but it also opens an SSL connection to the web server to forward the re-encrypted traffic along to the web server. If the web server doesn't support HTTPS, the the SSL Decryption setup on the firewall wouldn't work. You'll need to configure an actual proxy server (like Nginx or even Apache) in a reverse proxy setup. That will allow SSL traffic in to the proxy server, and the proxy will use normal HTTP traffic to the actual web server. But, once that is setup, you could enable SSL Decryption for the traffic going through to the proxy server. 🙂 And get the best of all worlds.

fjwcash · ‎12-10-2019

Yes, you can do this, but not the way you think. You don't NAT the traffic (well, you do, to translate IPs, but not to convert between HTTP and HTTPS). You proxy it. You need to configure SSL Decryption on the firewall, using an SSL certificate for the server. That way, incoming HTTPS connections on port 443 are intercepted by the firewall, the SSL connectection is terminated, the packets are decrypted, then forwarded through to the server as normal HTTP.

fjwcash · ‎12-09-2019

When reading a Security Policy, you OR everything in a column, and you AND everything in a row. So, having something in the Destination and the URL Category means both must match in order to block the traffic. You'll need two separate rules: 1 to block based on only Destination, 1 to block based on only URL Category.

fjwcash · ‎11-25-2019

Awesome! Thanks for the info everyone. I guess we'll be watching for the 8.1.13 release, then.

fjwcash · ‎11-25-2019

Update: This is still not fixed in 8.1.12, although the issue is slightly different. See this post for details. Panorama 8.1.10 (running in VMWare ESXi 6.5 if that makes a difference) All PDF and CSV exports of Security Policies, NAT Policies, etc are useless. All the headings and names are shown correctly, but everything in the cells themselves are just HTML code and JavaScript code. See attached image. Anyone else seeing this? Anyone have a version with a working PDF/CSV export for Policies?

fjwcash · ‎11-25-2019

@drewdown wrote: I get the whole concept and I am using app-ids on the permit statement and denying everything else across this environment so its not that. What I didn't get is that if I did that and didn't allow whatever traffic pattern was being matched it would be dropped. I assumed, albeit incorrectly, that if I allowed 80/443 and curl uses 80/443 and there is no 'curl' app-id it would be allowed. You're still missing a bit when it comes to the concept. If you allow 'web-browsing", then it will only allow traffic that matches the "web-browsing" application. Doesn't matter what generates the traffic (CURL, wget, telnet with manually entered HTTP commands, a web browser, something else), if it matches the "web-browsing" application pattern, then it will be allowed through. Once it has identified the traffic, then it looks at the ports that are being used and checks those against the Service part of the Security Policy. If it's set to "application-default", then (for web-browsing) it has to be on port 80. If the traffic is on any other port, even if it matches the web-browsing pattern, it will be blocked. If you set the Service to some other port (say 8080), then it has to match that as well. (web-browsing on port 443 is only matched/shown for firewalls doing SSL decryption; otherwise it shows up as "ssl") So, if you are using curl to connect through the firewall and it's not matching the web-browsing application, then it's not generating traffic that matches the web-browsing application pattern. When using AppID, the port used only matters when the traffic matches the AppID already. The AppID doesn't "allow all traffic on those ports", it only allows "traffic that matches this pattern, on these ports". Easy way to look at is, if you don't care about the application, leave it at "ANY" and filter based solely on protocol and port.

fjwcash · ‎11-25-2019

You can't prevent the classification (log entries), but you don't have to use AppID. Set the Application to ANY in the rule, set the Service to use tcp-443 and tcp-80, and you're done. Any and all traffic that uses TCP on ports 80 and 443 will be allowed through the firewall. And, in the logs, you will see what the firewall IDs the traffic as (application), in case you want to start using AppID in the future. Simple as that. We try to use AppID on as many rules as possible. We have some devices, though, that don't fully match the algorithm used by PA for determining the application, so we have some rules which are just Services, no Applications. Legacy heating panels, printing from OpenVMS, telnet for legacy video conferencing equipment, and a handful of others are one that don't work with AppID, for us.

fjwcash · ‎11-22-2019

In the Traffic log, add the Rule column, and see which Security Policy is matching the allowed traffic, and which Security Policy is matching the denied traffic. From the sounds of it, there's two separate policies in play here.

fjwcash · ‎10-22-2019

Aha! It *IS* a brain-dead protocol! It's FTP all over again, but in 2019? Panorama 8.1 includes a new field in the Panorama tab --> Setup --> Interfaces sub-tab --> Management dialiog: Public IP Address. This wasn't there in 6.x (which we started with) and guessing it wasn't there in 7.1 (as we had no issues with it), but is there now in 8.1. Which means, the paloalto-updates protocol (that's what the application shows up as in the logs now) is sending the Panorama server's IP address in the payload! This is a serious no-no in this day and age of NAT everywhere! I am seriously amazed that this made it through QA at Palo Alto. What's the point of setting the IP address of the Panorama server on the Device tab of the firewall, if the Panorama server is going to tell it to use a different IP?

fjwcash · ‎10-22-2019

Oh, and connecting directly to the web interface on the firewall running 8.0.7 and doing a software upgrade from there succeeds. It's only when pushing an OS upgrade from Panorama 8.1.10 to the firewall running 8.0.7 that fails because the firewall wants to connect direct to the 10.10.10.x IP of the Panorama server.

fjwcash · ‎10-22-2019

We have Panorama installed in our DMZ, behind a PA5220. Management interface for Panorama has a 10.10.10.x IP, which gets NAT'd to a public IP. Currently running Panorama 8.1.10 in panorama mode. All of our firewalls (currently PA200/PA500 with PanOS 7.1.x) connect to Panorama using the public IP. All of the firewalls have private 10.x.x.x IPs for their management interface, and Panorama traffic is NAT'd by the firewall to a public IP. All connections between the firewalls and Panorama are done using public IPs. We've been using Panorama successfully for 5+ years to push updates to our firewalls (software upgrades, dynamic updates, policies, configs, etc). And it still works to push update We have a brand new PA220, currently running 8.0.7, with the management port plugged into the LAN at one site (so it has a private IP in the same 10.x.x.x subnet as the firewall currently there). It's configured with the public IP for the Panorama server, and is showing as connected in Panorama. We've pushed the licenses and dynamic updates to it from Panorama. However, when trying to push an OS upgrade, the PA220 tries to connect directly to the private IP of the Panorama server! Which fails, obviously. All of the port 3978 and 443 traffic to/from the Panorama server is correctly NAT'd. It's only port 28443 traffic that the firewall tries to connect to the Panorama server's private IP. Pushing a software update from Panorama to a PA200 running PanOS 7.1.19 works. All of the traffic goes over the existing session (initiated by the firewall connecting to Panorama on TCP/3978). There is no traffic whatsoever using TCP/28443. Pushing a software update from Panorama to a PA220 running PanOS 8.0.4 fails. Initial connection is done using the existing session on port TCP/3978, but then the firewall initiates a new connection to the private IP of the Panorama server on TCP/28443, which fails. Has anyone seen anything like this before? Has something changed with the way Panorama 8.1 works or that PanOS 8.x works when connected to Panorama 8.1? All of our Panorama traffic has always gone to/from the public IP. It's very odd to see the private IP showing in the logs on firewalls on the other side of town. That usually only happens with ancient / brain-dead protocols that embed the server IP inside the data payload of the protocol, instead of using the IP headers. Just as a test, I did a software push (not install/reboot) of 8.0.0 to a PA200 running 7.1.19 and it succeeded without issues, and the 10.10.10.x IP of the Panorama server never showed anywhere in the logs (just the public IP).

fjwcash · ‎06-27-2019

Post a screenshot of the two rules, and (if possible) the full text of the error message.

Date Registered	‎05-06-2016 10:51 AM
Date Last Visited	4 weeks ago
Total Messages Posted	142
Total Likes Received	21

Online Status	Offline
Date Last Visited	4 weeks ago

Strata

Prisma

Cortex

About fjwcash