Multiple Portals for Global protect -Configuration check-Inputs needed

cancel
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 vpn.connection.it ( sample name)

 

The requirement is that 

 

Internal Users use  the URL  :  internal.vpn.connection.it

External Users(Partners) use the URL : external.vpn.connection.it

 

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 ?

 

 

17 REPLIES 17

@aleksandar.astardzhiev 

 

My public interface is eth1/1

 

But I have created a loopback called loopback.1 with private ip 192.168.1.75

 

I am doing a nat to translate my public ip to this loopback ip address

 

I am currently using this loopback.1 in both gateway and portal

 

But I can still create a gateway with same loopback . However as loopback is/32 it does not give me option to choose ip address when creating the second gateway but it still accepts it as ip address is optional.

 

So I believe we can still create two gateways ?

Or you mean that second gateway without ip address is of no use ?

 

 

 

 

 

 

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 192.168.1.75". If you create second NAT rule similar to above, but with dest 192.168.1.76, 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.

@aleksandar.astardzhiev  thanks a lot .

 

Makes sense . I will make use of Ad groups and ip pool and keep it simple.

 

Thanks . Good learning for me 

 

Glad we have people like you in the community to share the knowledge

 

@Abdul-Fattah thanks to you too .

  • 9750 Views
  • 17 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!