I have a working GlobalProtect setup right now using a single Portal on the district firewall, and a single Gateway on the firewall for the location I want to have access to.
Currently, these are using dedicated public IPs that are not used for anything else, assigned to the public interface of the two firewalls.
What I can't figure out from searching google, PA Discussions forum, and other resources is whether or not these need to be dedicated IPs used solely for the portal/gateway setup; or, if the IP can be shared with other services?
Eventually, I'd like to have a separate Gateway setup on each school firewall to allow admin staff to be able to access their files, servers, printers remotely. But, we don't have 50-odd public IPs that can be dedicated to this (each site only has 5 public IPs, used for all their public resources, with DNAT policies setup for forwarding specific ports through to various systems).
Can I just use one of the server IPs for the Gateway? Or will that break things for the server and/or GlobalProtect? Are there any Security Policy or NAT Policy changes needed to make that work?
Uhm ... uh ... er ... huh. Because that never occurred to me? ;) I'll have to play with that, to make sure it doesn't interfere with management connections (we use that IP for the web management IP from within the district).
Was testing a config with it set to "share" the IP of a server with existing NAT/Security Policies, and it tries to pass the GP SSL traffic through the NAT rule instead of terminating it on the firewall. :(
Loopback interface could assist here,
I read a similar article about how to make GlobalProtect accessible on a different port by using a loopback interface and NAT rules but it didn't click how that would help my setup until this morning.
I can create a loopback interface on the school firewall and use that as the IP for the GP Gateway on that firewall. Then just create NAT rules that forward ports 443 and 4501 from a shared public IP to the local IP, with Security rules to allow the panos-global-protect, panos-web, and ssl applications through on that public IP.
Or something along those lines. That way, there's an IP on the firewall that the GP connection terminates at, instead of having the traffic forwarded through the firewall. That was the step I was missing yesterday when testing it with the shared IP.
Edit: this is the article I read yesterday:
We already do that. :) Most of the IPs are shared across multiple systems with DNAT port forwarding setup. It's only the heating/DDC panel and VC units that get their own dedicated IPs. We're very conservative in how we use our IPs ... but we're also very heavy into networking services, video conferencing, VoIP, etc. It took a lot of work to get our public IP usage down to just 5 for an elementary school and 8 for a secondary school. :)
I'm going to play around with the loopback interface/IP and NAT/port forwarding. That should do what I need.
Using a private IP on a loopback interface, with port-forwarding NAT Policies using a shared public IP works. :)
Just configured a school firewall in this fashion, and the GlobalProtect client on my Windows laptop authenticates correctly to the Portal, then to the new Gateway, and I get access to the LAN and to the Internet via the firewall at that location. Required changing some of the existing NAT Policies (switch from bi-di rule to separate in/out rules), but everything is working.
Thanks for the pointers in the right direction.
Hi there! I know this thread is older...but how do you create a DNAT for 4501 AND 443?
For example, I have gateway configured with x.x.x.x:7000
I have a DNAT that forwards 7000 to 443. How do I get it working with 4501? reason I ask is because I want my tunnel to use IPSEC rather than SSL.
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!