Multiple Portals for Global protect -Configuration check-Inputs needed

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

Multiple Portals for Global protect -Configuration check-Inputs needed

L4 Transporter

Hello ;


For one our Customer running PA 3200 Series in HA having GP License ( HIP checks)


Currently the GP Portal and Gateway have common Interface  . The GP URL is ( sample name)


The requirement is that 


Internal Users use  the URL  :

External Users(Partners) use the URL :


The Users are part of different user groups .


So can we achive this using the same ( Single Public ) IP address or do we need two Public IP address 


We can to use different HIP profiles for Internal and External users . 


Do we need to create two different tunnel interface or loopbacks ? or two different gateways ?




Accepted Solutions

Hey @FWPalolearner ,


I understand that you use loopback for GP portal and gateway and use NAT to translate the public to the loopback. I still don't understand why you do this way instead of use the eth1/1 in the GP portal and gateway on first place.


But let discuss the other point - "But I can still create a gateway with same loopback" even if you somehow manage to use same interface/ip on multiple gateway you should receive error during commit. Think about it - all comes done to sockets, creating GP gateway will create TCP socket which FW will listen for connections. Sockets consists of ip and port and you can have different services/application on different combination of ip and port. If you create second GP gateway you need to create second socket and since you cannot use different port (always using the standard port for SSL or IPSec)  the only part you can change is the ip. Assigning same int and ip to both GP gateways will try to create two exactly the same sockets which will generate commit error.


And the same concept for the sockets apply for your NAT rules. I assume that you have NAT rule says "any public source to dest x.x.x, nat to any public source to dest". If you create second NAT rule similar to above, but with dest, the second nat will never hit (because the first math will be applied). Again you can play with ports as GP doesn't allow you change default ports, so the only way for the fw to apply the different nat rules is to use source ip address as matching criteria, but this defied the purpose of remote access vpn, because you will need to know from which public ip will the users connect.

View solution in original post


L4 Transporter



you can achive this with configuring an Internal Gateway and an external Gateway and one or two portal, the Internal Gateway is an interface on your internal Network, External Gateway accessed from Outside normally out from internet (Public-IP)  - Tunnel interface required here.

for more information check these out



Hi @Abdul-Fattah 

Thanks for your reply


We are already have an Internal gateway which is being used currently only by Internal users when they are in Corporate network


The goal is this exercise is when Users connect to the GP outside of the company network ( internet or at home)


All the Corporate Users should use the URL  internal.vpn.X . Different HIP profile , different IP Pool . different zone and different rules


All the Non Corporae users should use the URL  external.vpn.X . Different HIP profile , different IP Pool . different zone and different rules


So my Query is whether we need two Tunnel Interfaces( One for each external Gateway) and two Loop backs ( one for each Portal )


So do i have to create two external gateways using two different loopbacks 


and in the Portal settings define difference Address( FQDN) ?


Also , do i need two Public IPs ? or 1 can solve the purpose

then what you need is 2 external gateways, two tunnels, two public Ips.

another soultion would be same gateway, seperation based on users , and you can also define different IP pool for these non-corporate users and the networks that should they access with split-tunneling and add/edit your security policies as needed .

Hi @FWPalolearner ,


I suggestion is to always avoid multiple ip address on same interface like you would avoid a plague/covid. I cannot claim I have deploy lots of GPs, but I haven't yet saw a real need to configure multiple portals on single device, so I  will try to avoid such setup as well.

As @Abdul-Fattah mentioned you can provide single portal and once the user authenticate you can have group/user base separation (have different ip pool, dns, access etc for each user group). This would be the easiest way to have complete separation between internal users and contractors/3rd-party. The problem with this approach is that both type of users will need to use same authentication type. You can use different domain for user authentication, but the the type (LDAP, RADIUS, etc) must be the same for both (if you use mfa over radius you can be creative, but it is up to the mfa and not the fw). And as you can imagine both type of users will use the same vpn address. 


If you really  want internal users to use one address and contractors/external user to use completely different address - the only way to achieve this is to have second portal/gateway. As mentioned I would avoid secondary IP, instead I would recommend to use loopback (configure loopback with public ip, put it in untrust/outsie zone and use it for the gp portal and gw).


The only benefit I can think of is that you can apply different authentication type for each user group, so it is interesting for me to understand the reason why you need separate addresses

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!