Configuring GlobalProtect and DMZ Web Server

[ccortijo]

Hello,

Thank you for entering this post, the reason for it is that I am trying to configure the GlobalProtect VPN and a web server in a completely separate Zone. The programmer will have access to the server through this VPN and we will subsequently expose it to port 443 of my public IP. But I have the problem that GlobalProtect uses port 443.

Although I have seen guides and information, I have not yet been able to configure it

Somebody could help me?

Context:

We have a router with IP 192.168.1.1

On the eth1 interface of my PA220 I have it configured as an internet exit with 192.168.1.2, it connects directly to the router.

On eth2 I have configured my LAN network 192.168.10.1/24 (which I want the programmer to access)

On eth7 I have a DMZ zone (10.10.10.1/24) configured with a 10.10.10.2 Ubuntu server.

How can I configure GlobalProtect so that it does not interfere with the web server and is exposed to the public? Hosting the gateway, portal and web server on 192.168.1.2

Thank you

[aleksandar.astardzhiev]

Hi @ccortijo 

The best and simplies solutions would if your Internet Provider is giving you multiple public IP addresses. But such luxury is not very common.

Have you checked the following guide - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClGKCA0

I haven't needed to do it myself, but the concept  is the following:
- There is no way to configure GlobalProtect to listen on different port

- You can however create a loopback interface and enable GP on that

- Using NAT and port forwarding you translate your public IP and custom port to the loopback and 443.

- The drawback is that you IPsec/ESP cannot be NATed, and I am not sure if GP can work with NAT-T. Probably that is why in the last screenshot from the link it is shown that GP client is using SSL instead of IPsec.

If you have followed above guide, but you can't get GP to work, can you share more details, part of your configuration  and what issues are you facing?

[ccortijo]

Hello,

I have tried the guide that you have provided me and it does not work for me, I am attaching images of the configuration.

Currently neither the VPN nor the web server works.

Do you see something strange?

I greatly appreciate the help

[aleksandar.astardzhiev · Accepted solution]

Hi @ccortijo ,

- From your zones I can see that you use the defautl "loopback" interface. I am not sure if this is correct configuration, but general approach when creating loopback is to create new and interface with identificator at the end. Like the picture below

Same goes for the tunnel  interface.
It is possible the way you have configure it to work as well, but I am not sure

- From your interfaces it looks like your firewall outside interface is private (192.168.1.2) and you haven't configured the subnet. Is this because you have tried to hide your public IP, or there is another device infront of the firewall that is performing NAT and translating public IP to 192.168.1.2?

- If there is another device that is perfoming the NAT before the firewall, your NAT rules doesn't seems correct:

1. The rule at the top natting FW external IP to the DMZ server is appling any service, which will shadow any rule below that so GP rule will never be hit

2. If there is NAT before the firewall, your GP NAT rule will also use 192.168.1.2 as original destination. However it must be put above the DMZ rule.

- If there is NAT infront of the FW, your security rule also seems wrong.

1. You need to use 192.168.1.2 as destination and not the public IP, because the device before the FW will do the translation

2. You will need two separate rules for GP and DMZ, because security rules are using post-NAT zones. This means that in the security rule, you need to allow the addresses before that, but use the zones after the NAT. Since GP loopback is in WAN-CYBER your security rule should be source and destination zone = WAN-CYBER. Howerver your DMZ server is in different zone, so you need second security rule allowing again 192.168.1.2 as destination, but this time destination zone should be DMZ Servidor CAU

GP portal settings for external gateway is correct, you need to enter the public IP there.

[ccortijo]

Hola,

Muchas gracias por las aclaraciones.

Sigue sin funcionar, actualmente no veo el portal de GlobalProtect ni el servidor, adjunto imágenes de la configuración realizada. Antes del firewall tenemos un router que hace el nat

[aleksandar.astardzhiev]

Hi @ccortijo ,

The last rule, which should allow access to your DMZ server, still needs to be corrected. It should match destination address 192.168.1.2. This is little trick when you first start working with PAN firewalls, but I believe at some point you will understand it make a lot of sense:
When creating security rule you need to use post-NAT zone with pre-NAT addresses. That is because NAT is being "evaluated" first, before policy lookup, and NAT is applied after finding matching rule, little before traffic exit the firewall.

For the same reason NAT rule needs to use pre-NAT zones (because it needs to match the traffic using the original addresses).

So back to your case your NAT and security rule for the DMZ and GP should look like:

GP:

- Security: source zone=WAN-CYBER; dest zone=WAN-CYBER; source addr=any;  dest address=192.168.1.2

- NAT: source zone=WAN-CYBER; dest zone=WAN-CYBER; source addr=any; dest addr=192.168.1.2; service=tcp/7000

DMZ server:

- Security: source zone=WAN-CYBER; dest zone=DMZ-Servidur; source addr=any; dest address=192.168.1.2

- NAT: source zone=WAN-CYBER; dest zone=WAN-CYBER; source addr=any; dest addr=192.168.1.2; service=any

Back to your GP - NAT and security rules looks good to me, however it looks like the NAT doesn't any hit, which makes me believe no traffic for 192.168.1.2 on prot 7000 is hitting the firewall.

- How are you testing the access to GP? Can you try to open the public IP with simple web browser https://<public-ip>:7000

Do you receive login page? If yes are you able to authenticate.

- Check your unified logs, filtering by (port.dst eq 7000), if too many noise add filter for (addr.dst in 192.168.1.2). Do you see your attempts? If yes, is traffic being allowed? If you expand log details, do you see NAT being applied?

In addition:

- Did you move  the GP to loopback.1 as I suggested?

- I notided you have applied  MGT interface profile on the loopback. What services have you enabled for that profile? Does HTTPS being enabled? If yes, you really don't have to. Int profile with HTTPS is only to enable webUI admin interface and not required to enable GP. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClbUCAS

[ccortijo]

Hello,

Thank you very much for the help, it is really useful.

I think the web server is working correctly, but global protect is not, I attach images of the policies and logs.

I think the fault is in the GlobalProtect NAT

Thank you very much, again

[aleksandar.astardzhiev]

Hi @ccortijo ,

Regarding the DMZ server - although connection to the server seems to be working, in my humble there is room for improvement:

- It seems your DMZ server security is now using "application-default" as matching service. Unfortunately this will cause issues in your particular case. App-default means FW, will allow connection only if the applicaiton it is detecting correspond to the tcp port that is being used. From the logs it we can see that FW is identifying traffic as "ssl", that is becaue you are using HTTPS, without performing ssl decryption on the firewall. "ssl" application default port is 443, but you are using 8080. For that reason traffic is not matching your DMZ server rule, but it seems to be falling back to the "intrazone-default" rule, which by default is blockin any any. But apperantly you have change it to allow any any.

My recommendation - set port to tcp/8080 with application "any" for your DMZ security rule. Obeserve the logs for one or two days and see what applications are detected over this rule. Then you can switch from "any" app to specify only apps that you see in the logs. Keep tcp/8080 for the service.

- Regarding the GP - From traffic logs for port 7000 you can see that firewall is trying to send the traffic to dest zone DMZ. Which means correct NAT rule is not being applied. This is confirmed by the lack of increasing hit counter on the NAT rule. For me the GP NAT rule seems correct and it should work, my only guess is that you have typo for service object "port-7000", can you edit the object and confirm it is using tcp and dst port 7000? Can you share service object config?

[ccortijo]

hello,
Now everything is working.
Really, thank you very much for your help, it has all been thanks to you.
This helped me better understand NAT in Palo Alto Firewalls.
Thank you so much.