ssl gateway not working after upgrade to 4.1.2

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

ssl gateway not working after upgrade to 4.1.2

L3 Networker

Hi

After upgrading to 4.1.2 from 4.1.1 the ssl gateway and protal is not working.

When accessing the portal the client certificate is presented but when pressing continue, the login page never appears.

I had to revert to 4.1.1 to get it running again.

Any clues?

Thanks

9 REPLIES 9

L7 Applicator

This actually depends on many things, as this could be a bug, but we have not had many people reporting this one yet.

What client? SSL-VPN with NetConnect or Global Protect?

What authentication are you using?

If you reverted, you may have lost your logs showing something in there, unless you looked and you noticed something.

In short, no solid answer on why, it would have to be investigated by us by opening up a case.

Sorry for the vauge answer.

LIVEcommunity team member
Stay Secure,
Joe
Don't forget to Like items if a post is helpful to you!

I have the exact same problem. After the upgrade from 4.1.1 to 4.1.2 global protect isn't working anymore. The captive portal is also not working after the upgrade (login works but the redirect to the called url times out).

On my second test system the upgrade from 4.1.1 to 4.1.2 I had no issues with GP.

Hi,

We are also having the same issue. Since upgrading our Palo to 4.1.2 from 4.1.0 Global Protect has stopped working and we have users who now not able to login. We are having authentication issues when using RADIUS which was working fine prior to upgrading.

Many Thanks

Harsh

L0 Member

We are having the exact same issue. If someone get's the answer, please update this thread.

Thanks!

Retired Member
Not applicable

Have you opened a case with Support? If not then please do so as this could possibly be a bug.

-Richard

Yes I have, only problem is that our box is in production Smiley Sad - so I need to schedule it after hours next week.

Thanks

It is fixed now, the issue was that the HTTPS portal traffic was "tagged" as "web-browsing".

I copied my last policy and added "web-browsing" and "service_https" - now the portal loads AND GlobalProtect client works again

L4 Transporter

Adding "web-browsing" as an application and a https service did not help me in any ways.  You all have noticed it as not working but my experience is, the Global Protect Configuration disappears on committing changes. 

I was then later told that it was a bug and it resulted in loss of configuration whenever either of the option during commit is unchecked. Nothing was lost once I check both the options for commit. 

On the other hand, when I was on training, I was told that setting an application with a specific service does not provide with fruitful results and is not the way to configure.  I was asked to either add an Application and set the service as "Application Default" or add Service and leave application as "any".

Can anyone please clear my doubt.

Thank you.

Regarding setting service then of course if you limit lets say web-browsing down to TCP80 (where the TCP80 is put in servicecolumn) then it wont be able to detect web-browsing which is passing at TCP8080 or any other port for this particular rule (because that will be dropped if you use a classic whitelisting setup of rules meaning a bunch of allowrules which in the end have a deny+log).

But I think it can be sane to manually specify which ports you wish to limit because even if the grand feature of PaloAlto is application detection it doesnt mean that it will always succeed in detecting such applications not to mention that "service-default" might change over time.

Also if you set a huge range of ports (or "any" for that matter) - before an application can be identified the traffic must be let through (depending on what the payload is).

A simple test is to send "a b c" as a HTTP-request to a webserver hidden behind a PAN and you will notice that PAN will let this packet through to the server, but as soon as the server replies the reply will be not let back to the client (because it is when PAN gets the reply from the server it knows that the requst was HTTP and not something that just use TCP80 which means that the flow will be denied once it figured out the flow is not about web-browsing and your rule only allows web-browsing).

So in my case I recommend to first setup the rule in PAN as you would with a normal SPI-based firewall. And then choose appid for that rule then finally go to the service column and change specific ports into either manully defined range/ports or "service default" or "any" for very chatty procotols (for example many Microsoftbased is badly constructed from a network point of view).

One of the points of using a NGFW is to improve the security by setting up rules not only on port but also application. If you set "any" as service you will in many cases lower the security at least for the first few packets.

  • 4732 Views
  • 9 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!