Global Protect Migration Assistance

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Global Protect Migration Assistance

L2 Linker

Hello!

 

So, we inheritted an infrastructure with a few hundred VPN users whose Global Protect clients were all deployed pointing to the IP address of the GP Portal (not an FQDN). And, of course, we are now in a position where that physical site (and its IPSpace) are going away... 

 

We've stood up a new GP portal and gateway at  a new location (with an FQDN hostname for the new IP, even!). The last thing we need to do to decomission this physical site is to get all the GP users off the existing portal/gateway and onto the new one.

 

So, is there anything I can do to avoid having to have someone touch all the endpoints? I was hoping there was some sort of directive or setting hidden somewhere that would allow me to have the existing portal reconfigure clients to connect to the new portal next time instead. Please? I see nothing on the App tab in the Portal Config > Agent tab that sounds promising, and I could point the old portal to the new gateway, but once that portal is out of comission they will still be unable to connect to the VPN then... Yes, it's a sad place to be.

 

FYI, we would go down the path of running a script via GP to edit the config file or registry or something, but none of the machines are domain-joined.

 

Hoping someone knows of something I'm not finding myself that could make this less painful!

1 accepted solution

Accepted Solutions

L2 Linker

Thanks all. I wasn't super hopeful on this. It's just too bad the portal doesn't have a way to push/modify the client config when they connect. This is something that you can do with, for example, with an OpenVPN Access Server... (hint, hint, PA devs!)

 

I did, however, come across This Link that details the specific registry keys where the Global Protect client stores the configured portal address. 

(HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanSetup > Portal)

 

With that info, as a few others have suggested, it becomes possible to script/automate a solution to modify that key.

 

The problem in my case now is that I've got a few hundred users on a few hundred machines, most of which are not joined to the domain (yay!). Inherited infrastructure, and not under the dominion of the humble network engineer you see before you, so don't judge (well, me, at least)!

 

Luckily, we do have a remote management tool (ConnectWise Automate, formerly LabTech) which facilitates pushing a script directly. So, I'm thinking 1) a Group Policy for a startup script to hit the few machines that are actually domain-joined (a small number and then 2) push the script via the Automate agent to hopefully hit all the company-owned machines.

 

That would just leave iOS/Android mobile devices and any BYOD/personal laptops. Again, a great reason why being able to push the config from the Portal as the client connects would be a great feature. For that, yes, I think 3) sending out some clear instructions and asking the users to 4) call Help Desk if they are unable to follow them or if they run into trouble should suffice. We could monitor users still logging into the old Portal following some time after 1-4, and then 5) have Help Desk directly reach out to those users. 

 

Not perfect and certainly inferior to flipping the IP on an A record, but better than tracking down and manually laying hands on every single device! 

View solution in original post

6 REPLIES 6

Cyber Elite
Cyber Elite

Hello,

Might not be the answer you are looking for, but how about an email to the users with instructions to change the settings?

 

Just a thought.

That's about where we are at if no one is able to offer up a better idea. It will be a real headache for helpdesk/support, but it may be we have no other option.

Hi @locampo

 

I don't think there is an easy way in your situation. The only thing I would do is to make it as easy as possible for the users. For example if you write a little script or program that the users have to execute. This piece of code will then do the following:

  1. Stop the GP service
  2. Change the portaladdress in the registry
  3. Start the GP service
  4. Show a nice splashscreen to the user that the change was done successfully

Hello,

From my experience, with screen shots and clear verbage, the end users do just fine, most of them.

 

Regards,

L2 Linker

Thanks all. I wasn't super hopeful on this. It's just too bad the portal doesn't have a way to push/modify the client config when they connect. This is something that you can do with, for example, with an OpenVPN Access Server... (hint, hint, PA devs!)

 

I did, however, come across This Link that details the specific registry keys where the Global Protect client stores the configured portal address. 

(HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\PanSetup > Portal)

 

With that info, as a few others have suggested, it becomes possible to script/automate a solution to modify that key.

 

The problem in my case now is that I've got a few hundred users on a few hundred machines, most of which are not joined to the domain (yay!). Inherited infrastructure, and not under the dominion of the humble network engineer you see before you, so don't judge (well, me, at least)!

 

Luckily, we do have a remote management tool (ConnectWise Automate, formerly LabTech) which facilitates pushing a script directly. So, I'm thinking 1) a Group Policy for a startup script to hit the few machines that are actually domain-joined (a small number and then 2) push the script via the Automate agent to hopefully hit all the company-owned machines.

 

That would just leave iOS/Android mobile devices and any BYOD/personal laptops. Again, a great reason why being able to push the config from the Portal as the client connects would be a great feature. For that, yes, I think 3) sending out some clear instructions and asking the users to 4) call Help Desk if they are unable to follow them or if they run into trouble should suffice. We could monitor users still logging into the old Portal following some time after 1-4, and then 5) have Help Desk directly reach out to those users. 

 

Not perfect and certainly inferior to flipping the IP on an A record, but better than tracking down and manually laying hands on every single device! 

@locampo yeah there's not really a great way to control GP from an enterprise scale.  I'm currently in the process of migrating my company to GP (about 6k devices) from AnyConnect and there's not really any defined way to manage GP holistically.  

 

I did find this article which I provided to my SCCM guys and they built a package that pushed GP and the relevant config to our clients.  So while you're only wanting to change a simple setting maybe someone at your company can do the same?  

https://www.paloaltonetworks.com/documentation/71/globalprotect/globalprotect-admin-guide/set-up-the...

  • 1 accepted solution
  • 7225 Views
  • 6 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!