Mixed Internal and External GlobalProtect

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Mixed Internal and External GlobalProtect

L1 Bithead

Hi All!

I'm working through the "Mixed Internal and External Gateway Configuration" and something isn't quite clear - 

Do I need to create 2 separate GlobalProtect Portals (one to listen on the outside interface and one for the internal interface) or should I be able to access the same portal using the same IP?

 

Using 2 separate Portals on 2 separate hostnames/IP's, It recognizes me as being "internal", but I need to switch the "portal" in the GlobalProtect Client when I go mobile.

 


https://www.paloaltonetworks.com/documentation/81/globalprotect/globalprotect-admin-guide/globalprot...

 

 

 

1 accepted solution

Accepted Solutions

Ooooh... Mac's, not used them on our domain. we do have 1500 Ipads using device cert plus ldap auth but even then they do not traverse the LAN, they connect via our wifi and back out to the internet... not sure why i told you that... however..

 

the built in user ID was relating to the agentless user ID you have already tried.

 

I still only see dual portals as your best option. this will assist with the different auth options.

 

if you can issue user certs via domain or create them yourself on the PA if you only have a handful of users then you could enforce both cert and ldap for external and just cert for internal.

 

if you cannot easily issue user certs then how about a generic device cert to all devices and then work out the best user id method for internal.

 

@BPrymail option may be best, not sure why the user id mapping does not work... i assume your users auth to the domain when on LAN.

 

I have read somewhere about running a small scritp (post-logon) that sends ip/user info to syslog, you could then use a bit of clever regex for field extraction.

 

 

 

View solution in original post

10 REPLIES 10

L1 Bithead

...And a Follow-Up question - 

Am I able to have the _External_ connect to be connect-on-demand, but have the _internal_ connection be always on?

 

That is, our users connect to the VPN when they need to access something while outside of the office. When they're IN the office, I'd like them to be auto-connected to the Internal VPN (so I can use User-ID's in my policies)

 

you will struggle with this one... you can have different configs for the same portal but users will need to have a different user ID to obtain a different app config.

 

or, yes you could have 2 portals, use the same portal address but use internal and external DNS to resolve differently.

 

why not use the built in "user ID" on the PA?

 

or... just have one external portal, "on demand" and use captive portal internally.

 

no goods or bads here but just depends on why you are using internal gateways in the first place... 

 

 

Thank you, Mick!

 

1. I'm using LDAP auth to AD. All of my clients are Macs, joined to the domain.

2. My plan for using internal gateways is to match up threat alerts to users (by IP). I'm trying to do this WITHOUT requiring the user to enter credentials to use the local LAN. (With GP, I'm using Cookie Authentication, which helps out here)

 

 

1. "Agentless" User-ID using AD Event Logs - Couldn't get it to work on the first try, and moved to GP Internal Gateways. I'm not sure how much WMI Event Logs are going to help me when all of my clients are Mac (Joined to AD). Do you think it'll work?

2. I have Internal GP kinda' working. I think if I play with it for a bit longer, I can get it to work.

3. What are the other options you mentioned? What do you mean by "built in "user ID" on the PA?" 

4. I'll look into the Captive Portal option.

 

You can do this with a single Portal.  You could put the Portal on a loopback interface on the Palo(with a private IP).  Internal users will access the Portal via internal IP, external users would NAT to the internal IP.

@MikeTewner,

Really your best solution to do this is going to be two portals with different DNS entries both internally and externally as mentioned previously by @Mick_Ball. Cookie Auth is a good way to prevent the user from entering in credentials, doing certificate auth would be an even better idea honestly. 

 

As for your further questions

1) Do your clients connect to an on-site exchange server? If so you could leverage the logs for this and create a much more reliable enviroment instead of relying on just your AD servers. Setting a higher user-id timeout  value would also help with this if you don't deal with clients roaming between computers. 

3) The built-in user-id on the PA is simply utilizing the Palo Alto to act as a user-id agent, instead of installing the user-id agent on the domain/exchange servers itself. There are some benefits to actually installing the user-id agent on the servers that you won't get with using the firewall as a user-id agent. 

Ooooh... Mac's, not used them on our domain. we do have 1500 Ipads using device cert plus ldap auth but even then they do not traverse the LAN, they connect via our wifi and back out to the internet... not sure why i told you that... however..

 

the built in user ID was relating to the agentless user ID you have already tried.

 

I still only see dual portals as your best option. this will assist with the different auth options.

 

if you can issue user certs via domain or create them yourself on the PA if you only have a handful of users then you could enforce both cert and ldap for external and just cert for internal.

 

if you cannot easily issue user certs then how about a generic device cert to all devices and then work out the best user id method for internal.

 

@BPrymail option may be best, not sure why the user id mapping does not work... i assume your users auth to the domain when on LAN.

 

I have read somewhere about running a small scritp (post-logon) that sends ip/user info to syslog, you could then use a bit of clever regex for field extraction.

 

 

 

Hello,

I'm sure there is a reason, however why not have the GP always on if they are internal or external? That way they are protected by the PAN either way.

 

Just a thought.

Nope, no Exchange - We're in Google GSuite for everything. 

(Aside - I briefly got SAML auth working against GSuite, but got stuck with the absense of Groups. Went back to AD)

 

 

Anyways, when I had two portals, the client made me constantly choose which portal to connect to (They had 2 different hostnames). If I give them both the same hostname, will the client not ask me?

 

No because you only have 1 portal available. DNS will take care of what portal it resolves to, internal or external, GP won't care...

Thank you!

  • 1 accepted solution
  • 5494 Views
  • 10 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!