About aleksandar.astardzhiev

aleksandar.astardzhiev · ‎01-05-2021

Hi @FWPalolearner , There is a lot of comments, not sure if I get everything but: - What version is your FW and Panorama? If you are running 9.1 you probably can rely on the feature Automated Commit Recovery We still run on 9.0 so I haven't test this feature, but in theory this show work great for your case: 1. Enable the autmatic recovery 2. Push the new mgmt IP from Panorama. If there are any issues with the new mgmt FW will loose access with Panorama and the recovery process should kick in. - In general you don't have to do anything on the Panorama once you change FW mgmt IP. This is because the Panorama is using serial number to track the FWs. When you configure FW with panorama IP, it will attempt to register to Panorama. By default panorama will accept any source IP and will try to establish the TCP/SSL connection, it will ask for SN and if the provided SN is already added to Panorama it will accept the fw request and complete the registration. So in your case once you change the mgmt ip, the fw will generate new tcp session with the new source, panorama will establish this session and will see that the SN is the same as the one already registered and will automatically update the IP under the "manage devices" Similar to the FW you can configure permit IP list to specify which IP address are allowed to connect to Panorama, if nothing is defined panorama will accept anything. So if you have anything configured under the permit ip, make sure you have included the new mgmt ip/range - You cannot ssh to member over the HA link. Even if you receive password prompt, the firewall will not allow you to connect. - As falback you can configure the the mgmt profile to dataplane interface. Indeed for HA cluster you will be able to connect only to the active member. But this should be enough as falback: 1. Assign mgmt profile 2. Connect to active FW, fix the mgmt ip 3. Suspend FW to cause failover 4. Reconnect to mgmt profile IP, which now will connect you to the secon FW 5. Fix mgmt IP on secondary device - I believe @OtakarKlier was trying to say - check your HA config and make sure you don't use the mgmt IP for HA1. If you do and you don't have backup HA1 you will have split brain once you change the FW mgmt IP on one of the members.

aleksandar.astardzhiev · ‎12-23-2020

Hey @BPry , GlobalProtect logs are the main reason I want to upgrade to 9.1, but we were not sure if it stable enough yet. I am interested in what you say - "You don't necessarily see an authentication event with update". So far from the firewall logs I see actually the oposite. See below screenshot. These are system logs filtered with "(description contains '<username>') or (description contains '<user-public-ip>') , showing connected user that is updating its portal config every four hours (as per portal config). These are logs from user that has been already upgraded to 5.1, I just wanted to point out that from all the logs I have seen so far every portal config refresh is led by portal authentication (in this case with auth cookie, that is why no logs from auth profile). Going back to the users that are refusing to upgrade - I started looking at the PanGPS logs and something very strange got my attention - there is a entry saying "--Set state to OnDemand mode." . Our configuration is Pre-logon (Always On) and I can see in the registy the connection method is set to pre-logon. However at this exact moment the machine is online, but no GP was connection attempt was on 10th.

aleksandar.astardzhiev · ‎12-20-2020

Hey @BPry , We recently switched allow agent upgrade from disallow to allow transparently, meanwhile the config refresh is set to four hours. I was looking at the logs to see how many users have already been upgraded and noticed that lots of users are still not upgraded, because they haven't updated their config from the portal. I was looking at some logs and I am staring to believe that the timer for the config refresh is restarted on each reconnect. A user connects directly the gateway in the morning, after few hours (less then four) it has reconnect (laptop sleep or wifi switch or something similar) again directly to the gateway. And this could happend one or twice a day and that way user will never reach the config refresh interval. I actually noticed few users still using 4.1 version and looking at the logs for one of them it seems because he haven't contacted the portal for the last few months.

aleksandar.astardzhiev · ‎12-18-2020

Hi @Sarc845 , Thank you for the suggestion, but it doesn't seems to be related to the auth cookie... Yes we do use auth cookie, but from the below log (all of the logs are related to one user - my filter is "description contains 'name: <user>'") you can see: - that first agant is trying to authenticate with the cookie, but it has already expired. - So the gp agent will follow the authentication process (the authentication profile) configured under GP portal:

aleksandar.astardzhiev · ‎12-17-2020

Hi Guys, For couple of reasons, recently I started to think - Is there a way to force the users to always connect to the GP portal first and don't use saved gateway config? I have noticed that we have lots of users connecting straight to the GP gateway and haven't been connected to GP Portal for days. I am trying to figure out a way to force the users to always connect to portal first, get the latest config and after that to connect to gateway, and I am not able think of anything. I will appreciate any ideas!

aleksandar.astardzhiev · ‎12-16-2020

Hi @JoschkaKruse , Lets make it clear user-ID has nothing to do with app-ID, so lets separate the two issues. User-ID: Enabling user-ID on the IPsec tunnel zone will only tell the firewall to look for user-to-ip mapping for the source IPs that are received from that zone. You still need to have the "user-to-ip" mapping information from somewhere. If you say you are using Agentless I guess you are using Server Monitor and firewall is looking at the Active Directly security logs for logon events. Can you confirm that AD you are monitoring have logon events for the users in the remote network? Are these users use the same AD? I cannot think of any reason why IPsec tunnel will behave differently from any other interface on the firewall. So I will abstract from the fact that it is IPsec tunnel, and look if the AD that FW is monitoring actually have information for IP network behind the tunnel. Application-ID: Again - no reason why IPsec tunnel will behave differently from any other interface on the firewall. In addition FW will always try to identify the traffic that is processing, no matter if you use apps in the security rulebase or not. Can you explain a bit more what do you mean by "apps are not being dicovered properly"? What is firewall reporting and what do you expect to be reporting?

aleksandar.astardzhiev · ‎12-16-2020

Hi @Ahmad_ElKilany , I want first to clarify something - The ICMP probes generated by the tunnel monitor are not passing through the flow module (as explained here). Which measn: - The ICMP probes are not passing through the security rules (no need to explicetly allow them) - No route lookup is performed for those packets - No logs are generated - Packet capture cannot capture those packets. @MoatasemMetwaly, @Ahmad_ElKilany , the whole purpose of the tunnel monitor is to logically mark the tunnel as not working even if the phases are up. So if you see phase1 and phase 2 green, but status is red, this means that the IPsec tunnel (and phase1 & 2 settings are correct), but for some reason the pings generated by the tunnel monitor are dropped and FW is not receiving replies. I would suggest you to check my comments here - https://live.paloaltonetworks.com/t5/general-topics/fail-over-vpn-site-to-site/m-p/249792/highlight/true#M71033 But in summary - My experiance so far shows that in most cases the tunnel monitor fails, because it doesn't match the Proxy-ID/Interesting traffic/Encryption Domains. When you enable tunnel monitor, firewall will use the IP address assinged on the logical tunnel interface as source IP for the ping packet and destination the monitored IP you are using. After that it will send those packets over the tunnel (will encrypt them), however if the source and destination IP does not match the proxy-id the remote device will reject the pings and you end will not receive any reply - marking the tunnel as down. So: - Check if the source and destination IP of the probe packets are matching your proxy-id (if you are using any). - Check what IP are you monitoring, are you pinging the remote peer IP - If I remember correctly long ago the different FW vendors were behaving differently for the traffic send/received to the IPsec tunnel peer IP (some vendors were automatically accepting traffic between peer IPs to be encrypted in the tunnel, but other not)

aleksandar.astardzhiev · ‎12-11-2020

Hi @chyates , We need to renew the certificate for our SAML and today when I was preparing for this change I experiance the same message so with quick tests on lab VM we came up with the following steps 1. Import the IdP metadata as XML file. In our case with ADFS we use the link https://<your-adfs.local>/FederationMetadata/2007-06/FederationMetadata.xml 2. Go to Device -> Server Profiles -> SAML -> Import (at the bottom) and import the metadata. This will automatically create: a. New certificate - the self signed used by the IdP b. New SAML profile already using the new certificate 3. We edit the old SAML profile (which is used for GP auth) and configure it to use the new certificate 4. Remove the new SAML profile (as it is not needed) 5. Commit. At this point a warning for duplicated certificate will show, but if everything is working with the new cert, just delete the old one and commit again. I sure that the same approach is applicable for Panorama deployment as well, or if it is completely new SAML setup (skip the part with removeing the saml server profile). As I mentioned I have tested this once on lab VM, but looking at the successfull commit without warning and errors I don't see any reason to bother with the CA flag. Even without CA flag and self signed FW was still showing the certificate in the dropdown menu under the SAML server profile

aleksandar.astardzhiev · ‎12-10-2020

Hi @stoff , I, personally, am trying to avoid multiple IP address on the same interface like a plague. In some rear cased it is reasonable to do it, but in most cases there is a better way to accomplish your goal. I also agree with @BPry also that you don't need separate interface for each IP. When you use IP address in the NAT policy the firewall will automatically configure the proxy arp for that IP. So my suggestion would be the same as @BPry : - Configure your WAN interface with one IP from the /26 network - Configure destination NAT policies with the rest of the addresses in the /26 network (or bi-directional static source nat, depending of your needs and nat policy). No need to have those addresses configured on firewall interface

aleksandar.astardzhiev · ‎12-02-2020

Hey, @Jafar_Hussain , Unfortunately I don't believe there is other solution except to disable http patial response. Not sure if I am not thinking for something else, but I belive there was feature request to be able to override this option per rule... But I am really not sure..If you have contact with sale engineer you can check with him.

aleksandar.astardzhiev · ‎11-29-2020

Hey @Jafar_Hussain , You didn't answer my question - Are you using "allow http partial response" ? What I am thinking is - when you start downloading a file, firewall will buffer the data in the transfered packets and will build a copy of the transfered file. It will use the information in the file to identify what type it is. I believe it is using the "magic bytes" which are at the beging of the file. So on your first attempt to donwload the file firewall will see allow the first few bytes to be transfered, during that it will detect that the file is msi and will block the connection and effectively block the rest of the file to be downloaded. Now with http partial response, your browser is able to tell the server that it already has the first N bytes, so intsead of starting from the beginning, it will requests from the server to send the rest. Because of that the firewall will not see the magic bytes and it will not be able to identify the actual file type, which will not match your file blocking profile and therefor allow for the user to resume the download (effectively starting new session downloading the rest of the file). Disabling this option will tell the firewall to reset any http session that is trying to resume download (telling the server from which byte to start). The problem is that this is configured on global level and it is breaking Microsoft update (and other like SCCM). So a lot of people leave it disabled (meaning allow http partial response). I would suggest you to try to enable this feature (just for the test) and see if you are still able to resume the download

aleksandar.astardzhiev · ‎11-29-2020

Hi @djr , You need to move he NAT at the other end of the tunnel. As you correctly concluded - the static route pointing to the tunnel (for the return traffic to take correct path back), should not match your internal network. So: - The NAT 172.31.40.40 -> 172.16.12.5 should be applied on the other end of the tunnel - Which means that you also have to change the remote proxy-id to match the already nat-ed network - Not sure how your rule is configured, but review it as well and update it to use the nat-ed address - Keep the static route for 172.16.12.0/27 pointing to the tunnel I would also recommend you to use different zone for the VPN tunnel interface. From the output below I believe you are using the "untrust" zone for the vpn tunnel, which probably is the same zone for the firewall outside interface. If you configure ipsec tunnel to use separate zone can be benefitial for simpler NAT configuration (ex. you will not need NO-NAT rule for traffic sourced from your lan to the tunnel)

aleksandar.astardzhiev · ‎11-29-2020

Hi @Jafar_Hussain , Have you tried to disable "Allow HTTP Partial Response" - https://live.paloaltonetworks.com/t5/best-practice-assessment-device/content-id-http-partial-response/ta-p/336942

aleksandar.astardzhiev · ‎11-28-2020

Hi @raji_toor , Have you tried to disable contentin inspection for this SMB traffic? You can follow this article and try with DSRI first, but we recently troubleshoot slow transfer from GP users and DSRI didn't make any change. We created custom application and application override rule to completely disbable content inspection for the SMB traffic from our GP users to the internal server. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClpfCAC

aleksandar.astardzhiev · ‎11-28-2020

Hi @rasood , I agree with @SureshReddyM, you are talking about physical and aggregated interface, but your screenshots are from the aggregated and the sub-interface. I recenetly find the following kb - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000boDtCAI hopes it answers your question.

Member Since	‎08-01-2017 11:18 PM
Date Last Visited	‎12-22-2025 12:06 AM
Posts	1,077
Total Likes Received	448

Online Status	Offline
Date Last Visited	‎12-22-2025 12:06 AM

Unlock your full community experience!

About aleksandar.astardzhiev