About aleksandar.astardzhiev

Hi @Deepak_K , I am only guessing, but: - If you use dataplane interface for user-id in active-passive HA both devices will use same ip address so in case of failover the backup should establish connection to the server/user-id agent - User-ID information is synced between members in active-passive HA.   So in theory in case of failover, secondary device will get user-id info monitored server/user-id agent and sync it to primary member, which Panorama will still use. But this is valid of the primary FW is still alive (listed as passive in the HA cluster) and able to communicate with Panorama.     ... View more

Hi @Yoann-Wolf  Couple of months ago we enable transparent upgrade and experiance similar issues (PanGPS service was missing after new version installation) from 5.0 to 51. In 99% of the case manual un-install and manual install did the trick. One of the cases the re-install was failing for unknown for me reason (I don't remember if the interface was still there, probably yes) After desperat googling around the following did the trick for me: - Download and run (as admin) https://support.microsoft.com/en-us/topic/fix-problems-that-block-programs-from-being-installed-or-removed-cca7d1b6-65a9-3d98-426b-e9f927e1eb4d - Choose "Uninstall" and select GlobalProtect from provided list - Leave the troubleshooter running. It will take some time (5-10+min). - Once troubleshooter finish run GP installation again ... View more

Hi @dbrenipc ,   I believe this is caused by the redistribution profile you have configured. This is something that annoys me a lot - when you configure "Destination" in the redistribution profile, the prefix you put will not look for exact match, but it will match any prefix that falls under the configured prefix.   In your case I am almost certain that you have put 0.0.0.0/0 as destination for the redistribution profile. Which as you can guess will match all othe routes.    One way to fix this is to narrow down your redistrubtion profile filter -  - select the only the interface to which default is pointing  - select next-hop address to which default is pointing That way no other route will match that redist profile. But this depends on your config   Another way would be to create additional redistribution profile: - configure destination to match all prefixes that you don't want to redistribute to OSPF - Set action to no-redist - And set priority that is lower than what you have for the default route redist profile Redistribution profiles are applied in order from lowest to highest priority, so this would work like firewall rule and redistribute only the prefix you have in the profile with action redistribute     ... View more

Hi @Remo , Couple of months ago we have some transparent upgrade from 5.0 to 5.1 failing on random computers. From the logs I noticed that the transparent upgrade client is running batch file msiexec to uninstall and install the new msi with all of the required parameters.   I am saying this because since that I am using the exact same command to re-install GP remotely  and it seems the pre-logon to work after reboot. This is what is working for me:   TARGETDIR="C:\Program Files\Palo Alto Networks\GlobalProtect" CONNECTMETHOD="pre-logon" USESSO="yes" CERTIFICATESTORELOOKUP="user-and-machine" CACUNPLUGBEHAVE="yes" USEPROXY="yes" PORTAL="vpn.portla.wow" BENICE="yes" /l+* "C:\Program Files\Palo Alto Networks\GlobalProtect\PanGPMsi.log   Comparing with what you have probably you can try where to look for the client certificate. Although looking at the docs it seems user-and-machine should be default and not need to specify it. ... View more

Hi @fhewiufhwefhwe ,   If you have admin access to the computer you are connecting you can delete the DNS settings configured on the GlobalProtect interface once you connect. After all GlobalProtect is just creating another standard interface, only difference between the GP interface and your physical interface is that GP will use higher priority/metric to ensure any route pointing to the tunnel will take presedence. This priority will affect the DNS server order in which your PC will try to use.   The problem with this approach is that you need to do it every time you connect to the VPN. Probably you can script this and just run the script once you connect.   The better approach would be to discuss with VPN administrator and ask them if they can create a separate client config for your that does not assign DNS settings. ... View more

Hey @CHKlomp , Do you have Dynamic Packages updates on the Panorama? I remember that Default Trusted CAs were updated with App-ID/Thread packages But I am not able to find this statement in the docs, so I am not sure if this is correct.   ... View more

Hi @Deepak_K , - 3sec interval with 5 count means: It will mark path as down if 5 consecutive pings have timeout and it will wait for reply maximum 3sec before sending another ping request.   "We want to know this path-monitoring will fail after 15 consecutive pings or how it is ?" No, not 15 consecutive pings. You can say it will detect path fail after 15 seconds (waiting all 5pings to fail = 3x5)   "all 5 pings in each interval should be require to fail to trigger the path monitor failure ?" Yes. All 5ping needs to fail for path monitor to be considered down.   What I am not sure right now is when FW consider path-monitor up again...Eith on the first successful ping, or it needed the same count of successful replies as failing.   ... View more

Hi @nikoolayy1 ,   No, it is not the same. With the RDP scenario you will have multiple users related to same IP address and instead of keeping both it will override username with the last received.   Having multiple concurrent connections to GlobalProtect for the same user it will create multiple IP addresses related to same username, which is totally fine and all entries will kept. Because each successful login will assing you new IP from the pool.   ... View more

Hi @Lukaszm1 ,   These logs are not related to the VPN negotiation, but rather with configuration commit.   If you have enabled passive mode on the FW and you don't see anything else it probably means Azure is not even trying. If you don't have a way to force Azure to start negotiation, you can disable again the passive mode and run packet capture for IKE packets on the FW. Under CLI run: > debug ike pcap on (this will capture any ike packets so if you have other tunnel already running in this fw it will capture them as well) > debug ike pcap view   ... View more

Hi @AICOFINDIA ,   Compare the log  you see from the denied traffic with your "AV update" rule: - First check what FW has detected as application when matched  your deny rule - is it matching the application in your "AV update"? - What about service port? Are you using "application-default" for the allow rule? - Check if the FQDN for the update is not doing any "dns loadbalancing" and returning different IP address on each request (run multiple nslookups from your pc - is the reply change requently)   Most common reasons in my experiance are: - In your allow rule you are allowing application ssl, while the FW is detecting different application - Clients/users are resolving the av update FQDN to differnt IP from what the FW is resolving the FQDN. When using FQDN objects in the policy, FW will run DNS queries for the provided FQDN and put the first N IPs from the dns reply (not sure what was the limit if the dns reply multiple ips for single fqdn) and put them in the rule. FW will cache the dns response for 30mins (by default). If the endpoint and FW are using different DNS servers the may resolve the FQDN to different IP addresses, or the FQDN resolve to differn IP on each request. ... View more

Hi @Lukaszm1 ,   The log you have shared doesn't contain any error. It indicates that FW is trying to negotiate Phase1. The key point here is that FW is starting the negotiation ("as initiator"), due to the nature of the IPsec the initiator will not log the real reason why negotiation is failing.   You can try to enable passive mode under the IKE Gateway advance options - this will force the firewall to act only as responder and waits for the Azure to trigger negotiation. That way you should see more "detailed" log what could be the reason for the unsuccessful negotiation. Note that in thi case you need to find a way to tell Azure to start first - either by sending traffic from azure to on-prem network or by any "azure troubleshooting commands". ... View more