GlobalProtect Login Portal Redirect to 443

[jsalmans]

We're trying to find a way to redirect people trying to hit our Globalprotect login page on straight http to redirect to https seemlessly.  We thought we had this working with an inbound NAT policy with destination translation looking for original service as TCP 80 and the translation moved it to TCP 443.  This doesn't actually seem to be working and I believe what we thought as our initial success may have just been Chrome being helpful.

I'm not seeing traffic logs for connection attempts from my device to the portal IP unless it's a successful connection on 443 (i.e. I'm not seeing any of the port 80 attempts).  Is this due to an internal traffic flow difference since it is a Globalprotect portal?

My setup includes:

• A public IP address as a floating IP based on the Active firewall (running Active/Active due to having dual-homed 10g connectivity from provider).
• Portal config ties that public IP to a loopback with an internal IP.
• Firewall security policy allowing incoming connections to the floating IP using web-browsing along with the other applications necessary.

This is really just about ease of use for our end-users since getting them to use https:// when first going to the page is only easy when providing them a link in a webpage.  Telling someone verbally almost always ends up with them attempting to just type in the url without https://.

Is this possible at this time?

Thanks!

[TranceforLife]

curious as well:

https://live.paloaltonetworks.com/t5/Management-Articles/Does-the-PAN-provide-options-for-HTTP-to-HT...

I have done some tests but no luck........

[bradk14]

if I understand you correctly, you can't really just send HTTP traffic destined to port 80 to 443 and expect it to work. HTTP =/= HTTPS.

I don't know if it will work in this instance, but what you may what to consider trying is:

1) set up a dummy HTTP server somewhere on the inside to listen on port 80

2) configure the HTTP server to redirect to your portal url on port 443 (and https)

3) configure destination NAT port forwarding to take traffic destined for the untrust interface on port 80 and point it to the dummy server from step 1.

if #1 is too much of an investment, maybe it's possible to redirect to an external hosted cloud server like from digital ocean which would run you $5/mo. or leveraging a device like an F5 would make this possible.

[ansharma]

 Hi jsalmans,

It doesn't seem to be possible. Here's what I found:

No interface management profile on the portal interface.

Portal configured on the interface

http://interfaceIP = could not connect

https://interfaceIP = could connect to the portal

Now, if you look at the sessions (show session all filter source x.x.x.x destination y.y.y.y destination-port 443), you'd find that it does a destination NAT to some port (urs could also be 20077). I tried doing a D-NAT from 80 to 20077 but that didn't work.

From the debug logs I could find that it's detecting the session as sslvpn host session in the https case and a normal (incomplete) session (with no SYN ACK) for the 80=>20077 case. 

This leads me to believe, there is a script (internal logic) of the firewall only allows the portal page on https and does not accept any modified access.

Maybe talk to you SE and see if he can do something (feature request/product manager).

[jsalmans]

Thanks for the replies everyone.

@bradk14 the destination NAT idea came from something we saw on a Live article but I can't seem to find it anymore.  It was a long shot but we thought we had it working... pretty sure Chrome just remembered we'd previously reached the portal on https and just updated hte URL every time we typed it in.

I thought about using a server as you suggest to just have a redirect page set up, however, I wasn't sure how that would work since the portal isn't just a webpage... it's also a connection point for the VPN client.

@ansharma I noticed the 20077 translations as well when examining the sessions in the Traffic Monitor.  I agree that it seems like something specific is being done for VPN behind the scenes that occurs before a lot of the user configurable stuff or like a script blocking anything but https connectivity like you mentioned.

I'm definitely going to reach out to our reps about this.  It seems like a bit of an oversight and, while it isn't a super important feature, it certainly is useful when presenting the portal to end-users.

Thanks