About BPry

@Mike_Canfield, The local client PanGPS logs have all already rolled? If that's actually the case, I don't think you're going to have enough to further troubleshoot this properly. The agent itself is rather generalized when it comes to connection issues, but PanGPS.log includes actual details about where the process is failing. Not having that you're stuck with just the DR firewall GlobalProtect logs, but I would assume that those have already been checked and found to not be an issue.  ... View more

@Mike_Canfield, Does the DR site have the exact same configuration and is it the same series? Have you checked the PanGPS logs of someone who can't connect to actually see what error the service itself is providing, that's where you'll get detailed information from the client side of things.  ... View more

@pratik.gothankar, You don't really give enough information to actually indicate whether this is an issue to GlobalProtect or not. Zoom (or any video conferencing platform) is generally something that would be recommended to be routed outside of the VPN and allow the traffic to exit locally for best performance.  There's a lot of information missing from this post however and there's quite a few things that can be modified in the Zoom side of things as well that can potentially help with performance for split geographic teams trying to conference with each other.  ... View more

@Mike_Canfield, Not entirely positive on your full goal here, but if you're using RSA as a SAML provider you can modify the Access Policy to a 2.0 policy and enforce both a primary authentication process alongside a secondary process which is probably what you're intending to do for authenticating connections.  ... View more

@JimMcGrady, Windows and sleeping clients have been weird for quite a while due to modern standby, but you're also running into GPC-17854 which is a known issue on 6.2. You kind of have a couple of solutions that you could attempt:   Increase the login lifetime to an extended duration. Generally outside of BYOD devices I will set this to an extended number of days, not hours. Inform people that they should not be sleeping their computers and that this is going to cause them issues. This doesn't change anything that you're doing and you don't need to make any changes, but it is the least user friendly modification. If these aren't issued devices however, this is what I would do. You could attempt to test a couple clients on 6.3 where this issue is only noted for Linux agents.  ... View more

@H.Thiam, Someone with Duo can probably provide you more information, but it looks like the attribute that Duo wants to utilize would be User.Username for your authentication profile according to their docs ... View more

@M.Mohamed143196, I imagine here that you're not going to do a clean cutover and that equipment is going to be active in both locations? Otherwise you could simply shut down both units and move them with the rest of the equipment.   Assuming that this isn't a clean cutover and that you'll have equipment active at both locations, this is a bit more of a complex question that I would generally recommend you have an actual conversation with someone who can actually review your network and configuration. That might mean a local consultant that you trust, it could be professional services, but if you're asking this level of question it's likely worth spending a little bit of money for someone to fully review your plans with all of the relevant background knowledge. As is, the answer to how you would move everything is highly dependent on the following: Do you advertise your own prefix? If not, is you're ISP going to have service active at both locations concurrently? Is there a need to change your public addressing for any potential external services that you have? Do you have external services that will be running across both locations until everything is moved over? Do you have VPN connections configured to any other entities or sites running on the equipment that you will be moving? Ultimately the general idea is going to be the same. You can offline your passive device and then break HA on both devices. You'll then treat them completely as standalone devices and make all of the necessary configuration changes on each device to support both environments for as long as the 'old' location stays active. Once you're ready to bring things back together, I would completely reset the 'old' location firewall and rejoin it to the firewall in your 'new' location and treat it more like you're adding HA for the first time to an existing location.  Keep in mind that there's likely a whole lot of configuration updates you're going to need to make to support both locations being online at the same time and they aren't generally minor updates. Depending on your answers to the question above, it can change the entire process of the migration of services while you make this change. That's why I would recommend spending the money to do this in conjunction with a professional who has done these types of migrations before instead of relying on forum assistance.    ... View more

@M.Mohamed143196, I'm not positive of what you're asking. What do you mean by 'shift' to another location? You'd have to provide a bit more information on what you're actually trying to accomplish here for anyone to be able to offer assistance.  ... View more

@bilal_guclu, As @Raido_Rattameister mentioned, this would be expected with how you have things configured. You may want to look into setting up the 'enforce GlobalProtect for Network Access' option ensuring that you have properly configured the enforcement setting and specifying the transition timeline if this is something that you want to truly enforce. There's a couple of tuning points like captive portal timeout that you have to watch out for, and understanding the support aspect in the event that someone simply can't connect for some reason, but that will do what you seem to expect.  ... View more

@mohammedsalhis, I would highly recommend engaging your local sales team so that they can run an analysis and recommend appropriate hardware. One of the hardest things with you just giving us models is that we don't know why you went with that unit, if it's actually sufficient for your existing installation, and what your requirements actually are. If you are pricing a PAN with everything enabled, but your existing Fortinet is just a stateful firewall we're not going to be looking at remotely the right comparisons. You could have been moved up-market on the Fortinet due to SSL Inspection CPS, which isn't as big of an issue on PAN, or you could have missed the mark on sizing completely initially. The direct simple comparison for your 501E would be the PA-1410. You would absolutely want to know more about your existing setup before recommending you proceed, because again we don't know what you currently have. If you have 10 VDOM configured on your 501E (which is supported) and need to maintain it, the entire 1400 series is out of consideration because it can only have a maximum of 6 VSYS. Likewise with your 1001F, the lowest market comparison would be your PA-3430 assuming that you're actually hitting near the 1001F top performance figures, which you likely aren't. There's again however quite a few additional aspects that you would want to consider before outright saying go buy that as the replacement.   Overall, just giving model numbers and asking for a replacement is asking for trouble when you actually make the purchase. You need someone that can look at your existing configuration and what your current systems are actually getting hit with, determine if you can make any necessary adjustments that would let you go down-market or up-market, and give you a proper replacement.  What you're essentially asking for, and getting, is an 'educated guess' of what might work in your environment based solely off of a common environment and datasheet numbers of your existing hardware. That is not how you should be making hardware purchases. It will work 92% of the time, and 8% of the time replacing hardware like this is going to put you in a world of hurt and make you very unhappy. Get your sales team involved to scope this replacement, it's literally why PAN pays sales engineers.    ... View more

@GregorJus, I would suspect that you're running into a cookie issue and the constant connections and disconnections that you are seeing. Disable 'Accept cookie for authentication override' on the Portal.  ... View more

@M.Pahlavanzadeh, I've never tried to do this previously, but how would you handle any sort of routing to the connected endpoints? Just from a support aspect, this seems like it would be a pretty bad idea since you wouldn't be able to connect to these endpoints at all even if the FIB actually allowed this to work in practice. It certainly isn't something that I would recommend you knowingly and actively do.  ... View more