About nikoo

nikoo · ‎08-07-2020

IKEv2 on PA has built in keepalive mechanism, but it can only act if the communication is lost for more than 5 minutes: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClgcCAC After testing it out, about 7-8 minutes passed until Palo Alto detected lost peer and did reset of the tunnel. That's happening due to built in algorithm: The default interval of liveness checking is every 5 seconds when SA is idle. Upon losing connection, the firewall will do 10 liveness retries with increasing timeout (seconds) for each retry as follows: 1 + 2 + 4 + 8 + 16 + 32 + 64 + 64 + 64 + 64 = 319 seconds (about 5 minutes) .. meaning it is not configurable in any way? Is there a way to speed it up? Tunnel monitoring didn't seem to be an option, because tunnel is proxyID based and there are 4 proxyIDs configured - tunnel monitoring was working properly for one of them (source/destination pair), but at the same time concluded that other 3 of them are down and did the reset every 10 seconds or so which is not acceptable. Basically, what are your options to detect the IPSec tunnel peer down condition and act as soon as possible, meaning, tear down the tunnel and start re-negotiation.

nikoo · ‎03-27-2020

9.0.7 @ PA-3020 - today the same warning popped up, but recommendation didn't seem to help. Also tried changing App configuration, committing and changing it back - still the same.

nikoo · ‎04-08-2019

Indeed, that's why it is rather strange as I would guess the product is widely used and I would expect it to be recognized properly by this time.

nikoo · ‎03-29-2019

Hi, I'm doing decryption for Exchange 2013 OWA web part and it was doing good - was seeing mostly applications like ms-exchange, activesync, outlook-web which makes sense. Customer upgraded their infrastructure to Exchange 2016 and after trying to decryot that I'm getting a bunch of unknown-tcp traffic after decryption instead of ms-exchange and/or outlook-web. Even for full length sessions with bunch of traffic. Activesync still seems to be recognized normally. Due to that had to allow unknown-tcp traffic in security policy as well, which is not great, but still better then not decrypting at all. Decryption itself seems to be working fine, as there are no errors, same key was used on the new servers when migration was done. Have anyone seen similar results?

nikoo · ‎02-27-2019

Indeed, 8.1.6 has given me enough confidence to start deploying 8.1 much wider - haven't seen any issues so far. 8.1.6 is listed as TAC recommended release, which was not the case for any of the previous releases - so that is already a good sign.

nikoo · ‎08-31-2018

This was my fault as I did misunderstand procedure for deactivation and re-registration a bit. Basically I didn't have Licensing API key generated for the new account, I was using the one from the initial account. As soon as generated it on the new account and replace it on the VM itself - it worked fine.

nikoo · ‎08-24-2018

Yep, getting the same message since the last content update. Given it is not ciritcal and does not seem to have any impact - will wait as I guess next release may fixt this.

nikoo · ‎08-24-2018

Hi, Although looking through this in internal sources as well, but maybe you guys have seen this and have an idea. Initially there was PA VM-100 trial registered in Support Account 1 - partner account. Everything's good. Trial expired, full license was purchased - auth code was registered in Support Account 2 - customer specific account. VM-100 was deactivated and re-registered in the Support Account 2 with a new auth code, licenses were uploaded manually to the device and they look valid, but at the same time it is not possible to get Software updates, GP packages, retrieve licese keys for license server, etc. due to Error: "Failed to install licenses. Serial Number doesn't belong to this support account." As soon as I transferred the VM back to original Support Account 1 - it started working. Transferred back to Support Account 2 - same error message. As mentioned - licenses show up fine, S/N is registered on Support Account 2 and can be seen as active. From my side it looks like VM is still hanging to the original account where the Trial was started, even though it was re-registered. Any ideas?

nikoo · ‎08-13-2018

Cloned the rule, yep. Left everything the same, but removed source user statement. Will try poking around, yep.

nikoo · ‎08-13-2018

Thank you for the advices guys, somehow missed all the notifications. @BPry, As far as I know (not working directly with the end user) - nothing specifically fancy, but there could be something unnoticed though - no one was really sitting behind his back. But definitelly nothing major - same setup, just different time. @ToddJohnsen, Yes, it is clientless (moslty, one agent as well). User is kind of known to the Palo - it is not lost at any time, but will check through updates documents regarding requirements anyway as initial setup is pre 8.0 era. Although given this concerns only one specific user - company wide issue should be seen more often I believe. @MickBall, These is expected user-id associated with the IP in the logs and user-ip mappings. User field is not blank. If looking at the logs - they are exactly the same, with the difference of rule being hit. In one case - used-id base, in another case - backup IP-only based rule. User-ID mapping is still present in the cache - at least as far as I've checked from the CLI.

nikoo · ‎08-07-2018

PAN-OS 8.1.2, User-ID configured with Windows AD single domain. There are security rules built, based on users/user groups. It is mostly working as intended, but specifically there's [at least] one user that has a different behavior - some user-based (not group) rules are occasionally missing, even through they did hit the policy a few moments ago. Same traffic, same packet fields - IPs/ports, etc., but suddenly it goes through Deny, instead of hitting the Permit policy. At the same time same rules works fine for a different user. After a moment, it may start hitting the proper rule again. When checking via CLI, faulty user is registered properly- there is user-ip mapping, user-group mapping, etc. If creating additional rule, based on IP only, without username used - it hits that rule if it is missing the user-based rule, so there should an issue with User-ID, but not widely seen as there are a bunch of user/group rules used and they are working fine. Issue have been noticed with one specific user, but it is no different than any other user seen around. useridd.log shows such an message, where <domain> - proper domain and <username> - username for the tricky user: Warning: pan_user_group_user_prime_uid_lookup(pan_user_group_multi_attr.c:1306): For <domain>\<username> user, domain <domain> does not exist in group-mapping I've tried resetting, clearing, refreshing, etc., but that didn't help. Don't want to overwhelm with configuration, but maybe spew some ideas where to look? Thanks!

nikoo · ‎01-03-2018

Conect via console and check what's happening there. Or reboot in maint mode and rollback.

nikoo · ‎01-03-2018

Objects -> Regions allow creating custom regions based on the IPs and/or location, but there are already predefined locations and they do not require any additional configuration. Or do they suddenly? https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Security-Policy-to-Use-a-Region/ta-p/60353 https://live.paloaltonetworks.com/t5/Community-Blog/Geolocation-and-geoblocking/ba-p/188812

nikoo · ‎01-03-2018

Hi, PA-3020. Had a customer upgrading from 8.0.4 to 8.0.7 and, after upgrading, autocommit failed with the message: "Failed to find address US"; "Unknown address US"; "Failed to parse security policy", where US is a default region object used in the security policy. There are no customer objects created in the Objects -> Regions section. Checking here first as maybe there's already known problem with this? I see there's a post from a guy in the reddit about such a result as well, so that shouldn't be limited to a single device only. Upgrade to 8.0.6-h3 with the same config was successful.

nikoo · ‎09-24-2017

Hi, Thanks for the input, I've looked though these articles and most likely reboot for these processes should be done anyway, but just curious if that is may be something specific customer is doing within GUI, etc. or that is process itself getting busy with something, so looking if someone has seen similar pattern in any way.

nikoo · ‎09-22-2017

PA-5020, sitting on 8.0.4. From time to time MP load increases rapadily due to appweb3 process going above 300%. Looking like this: There is no direct correlation found between the spikes and actions taken within the GUI. Spike may go on for a while - 20 minutes, 2 hours, 5 hours, etc. During that time GUI is still usable and everything is operating without noticable delay (same goes for data plane, no impact there). But this is still bothering, as there's no clue what is causing the load and if that could have bigger impact for the box in the future. Spikes can be seen clearly when monitoring CPU load - it show values below 20% and then sudden spike ~90% further, while it drops after a while. Has anyone seen such a behavior or are there any suggestion where to look further?

nikoo · ‎06-27-2017

@vsys_remo Hi, did you get any feedback from TAC?

nikoo · ‎06-19-2017

Had to run home yesterday, so didn't elaborate much on details. 🙂 But, yea, there are no additional inspection events related to that specific event - just a one rule hit, which covers all of the possible variations for application shifts on that TCP/443 port, without using application-default behavior. These logs definitely showed up only after enabling SSL decryption for that specific inside server and dissapeared after disabling it, so that may be related to some application shifts happing somewhere under the hood or some inspection profile having some impact. Here's a sanitized full log entry: And here's a rule: There are some inspection profiles attached to it, so there is an option to disable them and see if that has any impact on the logs. At the moment decryption is disabled though, so cannot test that. 8.0.3 is out - I don't see anything related in the fixed bug section though, but may worth trying. Cannot tell about 7.0.x or 7.1.x, because had to upgrade to 8.0.x in order to have Inbound SSL decryption for ECDHE. Sitting on 708-4066.

nikoo · ‎06-19-2017

Hi, SSL decryption was turned on for one of the inside servers. Although it looks good, but some of the logs are rather strange. There are sessions like these: Basically Action - Allow, Rule is hitting correct one (the one permitting the traffic), but Type is Deny and Session End Reason is policy-deny. That looks false to me and it seems that traffic is permitted indeed. Can check more with captures, etc., but has anyone seen such an effect? PAN-OS: 8.0.2

nikoo · ‎04-17-2017

Hi, Beginning are always clumsy, but one of the first things I was impressed - community and knowledge base articles. I cannot stress enough how many times articles around here have helped me to get around some issues or simply get to know some feature. Anyway, when I got into PA firewalling, it all looked nice and shiny and overall easy to deal with, so it felt good, but some things I've learned over time: Subscribe for Security Advisories, Software Update & Content Update e-mails - that way you will always know when new feature release comes and will not miss more severe notifications about vulnerabilities - in such a cases every minute counts. Use packet capture - that has proven my point countless times - if, for any reason, you do not believe logs - getting the capture in such a cases is easy & fast way to see what really happens from a different directions. Learn some basic CLI - they WILL become handy one day and when that happens - it may be already stressful enough as you will not go there unless there is a really good reason. Know how to deal with HA from CLI, log structure, running debug packet diag, flow basic (https://live.paloaltonetworks.com/t5/Featured-Articles/Getting-Started-Flow-Basic/ta-p/72556), etc. Superb feature I learned about after a while - https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Test-Which-Security-Policy-Applies-to-a-Traffic-Flow/ta-p/53693. Testing policy match from the CLI - that really helps to understand if the traffic will pass without bothering the end-user. P.S. TCP - IP protocol 6, UDP - 17. Good to know when testing. 🙂 Features that are synchronized in HA - https://live.paloaltonetworks.com/t5/Tech-Note-Articles/High-Availability-Synchronization/ta-p/61190. Had to deal with the question - why the heck secondary device is not getting the updates from the Internet although the network setup should allow it, but, whooaaah, service routes had to be set for both devices of the HA pair saperately as they are not synced in HA. Although it was not possible in early PA releases - it is possible to log the default security rule traffic - https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-See-Traffic-from-Default-Security-Policies-in-Traffic/ta-p/57393. I've seen some creating custom "catch-all" rule for the traffic just for the logging - not required anymore. I was told it is not possible and it turned to out to be legacy and wrong. ..and there are definitely other things, but as you see all of these are well described in Live community - you still have to find them though. 🙂

nikoo · ‎03-15-2017

Yea, it should be OTP, but turned out as TTP. 🙂 Well, fine, will upgrade to 7.1 when possible although there was a cookie to feed for the client in 7.0 as well, but that did not do the trick. We'll see if this will make it better.

nikoo · ‎03-09-2017

A little bump, maybe still someone has some insight?

nikoo · ‎03-08-2017

Long story short, reason for my doubt was SSL, becuse decryption was done. Basically, when SSL decryption succeeded, instead of seeing application ssl at TCP/443 as initially, Palo Alto saw application web-browsing at TCP/443 which is not the application-default port and due do that was blocking it, which is pretty much expected with this configuration.

nikoo · ‎03-07-2017

Hi, @reaper Ok, thanks for assuring me, will look into why it is acting the way it is, because it seems like not hitting the correct rule then with the current deployment.

nikoo · ‎03-07-2017

Hi, There is a deployment with RSA-ID as OTP and GP as VPN client (3.1 or 3.0). PAN-OS version 7.0.14. After the recent upgrade from 6.x to 7.x an issue showed up - when authenticating from GP - login information is asked twice. This seems like a known issue: https://community.rsa.com/docs/DOC-46969 I've adjusted the PA settings according to this: https://live.paloaltonetworks.com/t5/Management-Articles/GlobalProtect-with-RSA-OTP-behavior-change-from-PAN-OS-7-0-1-or/ta-p/65176 But that did not help, double authentication is still asked every time. GP client was reinstalled and local data cleared. Basically, after investigation of PA logs, it can be seen that when client connects, he's asked for the username and passcode (PIN+Code). After that the connection is accepted by RADIUS (RSA) and instantly there is a new request made by PA in a blink of an eye and that is rejected. Due to that a new login is required - after that connection succeeds, connection is accepted and VPN connection established. Is this really how it should work and there is no way around it?

nikoo · ‎03-05-2017

Hi, Sadly don't have PA to play around at the moment, so have to pass this question for all you out there as I'm sure I cannot be first one with such an idea. What is the best way to block apps on their non-default ports? Basically, allow apps ONLY on their application-default ports. My first thought was like: Rule1 - src: trust, dst: untrust, application: any, service: application-default, allow Rule2 - src: trust, dst: untrust, application: any, service: any, deny But this way, due to rule processing sequence, as soon as PA seens Rule2 for new traffic, it does not go futher to App-ID, but block the traffic based on service. At the moment there is "permit all/catch all" rule before the default intra/inter-zone rules, but if that was not there, how would the default inter-zone rule (from trust to untrust for example) block the non-default port traffic for any app or would it still catch all based on the service before the App-ID and would not allow anything further?

nikoo · ‎02-01-2017

Hi, We have an internal CA, we have a certificate generated and it is used for GP portal/gateway only, clients are authenticating via usual credentials. Nothing fancy overall. So there are external clients who do not have CA cert installed, so they are getting "untrusted certificate" warning when connecting to the GP gateway. But the GP agent behavior differs between versions 2.3 and 3.1 wen connecting to the gateway. 2.3 - click continue, accept the untrusted cert and roll on - login succeeds. 3.1 - click continue, login (because reject happens if invalid credentials are entered), but that is when connection fails with the message: "Gateway 1: Server certificate verification failed". Won't expand on tshoot logs and everything, but is that way it goes? Is there a workaround other than installing CA cert to trust the issuer? Because if there is trusted cert installed for the issuer CA on the client/agent computer, connection happens fine with both versions. I've found this: https://www.paloaltonetworks.com/documentation/23/globalprotect-agent-rns/globalprotect-agent-2-3-release-information/changes-to-default-behavior#99749, but as far as I understand, this should already happen on 2.3 according to this document. Can't seem to find anything related to 3.1 and what specifically changed there. Any expierence with this? Cheers!

nikoo · ‎10-05-2016

Will poke this thread around. Time has passed, so maybe someone has seen similar situation and filed a support case?

nikoo · ‎08-04-2016

Could this possibly help you? https://live.paloaltonetworks.com/t5/Management-Articles/Domain-not-Added-to-Usernames-using-Captive-Portal-and-LDAP/ta-p/56114

nikoo · ‎07-20-2016

Because it matches the Vulnerability signature. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1902 Dealing with false positives is pretty normal - everything will not magically work out of box. First two options tod eal with it on top of my mind are: 1. Change the default action for the whole role if you feel like Lotus Domino vulnerabilities are not your concern (you don't have that in your network, etc.). 2. Create Security rule matching traffic from your server and with different Vulnerability profile assigned which will be created not to trigger this specific vulnerability.

Date Registered	‎05-05-2016 01:35 AM
Date Last Visited	Friday
Total Messages Posted	53
Total Likes Received	15

Online Status	Offline
Date Last Visited	Friday

Strata

Prisma

Cortex

About nikoo