- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-20-2023 08:28 AM
I don't know if you can really compare it to Cisco/Checkpoint, but yes both the Portal and the Gateway are required. The GP Portal is where the GP client connects to get its configuration data: client side settings/network restrictions and a list of which Gateways to connect to. The GP Gateway is where the GP client connects to establish the tunnel that client VPN traffic will actually flow over.
The reason these are separate is that the GP configuration point and the data point can be on completely separate interfaces or devices. So you can have one or more GP Portals that push different configurations to different clients with a set of preferred Gateways. Those Gateways can be scattered across the world with the client choosing the best Gateway for its connectivity. You can also have different Gateways for different types of clients, based on the Portal config, i.e. your corporate users go to one Gateway, your contractors go to a different Gateway, with the same Portal.
In most cases PA users are probably using a single Portal and Gateway setup. In my setup I have multiple PAs with 4 different public interfaces, each running a Portal and Gateway. End users being users... most people always select the first VPN Portal in their GP client. If you only had a single Portal/Gateway association then all the clients would be on the same public interface/PA. With multiple Gateways I can make the GP clients automatically load balance across all the available Gateways (and fail to a different Gateway if the primary is unavailable) regardless of which Portal the user selected. This also means that I can remove a Gateway from the Portal client config and have users automatically move off it (over time) to perform maintenance or test new configurations, without having to tell every end user to change their VPN Portal setup.