topic Re: What is wrong with Mobile Access in R80.10? in Firewall and Security Management

What is wrong with Mobile Access in R80.10?

Vladimir — Tue, 13 Feb 2018 17:54:48 GMT

Well, third day deep diving into Mobile Access blade on R80.10 and here are the findings so far:

1. Mobile Portal does not work as intended. From Windows 10:

a. no native applications could be launched as SNX does not work using either Active-X or Java (at least on Windows 10 Pro).

b. no custom web applications appear in the portal as well, regardless of where they were defined in.

2. Multiple notification errors during policy installation or failure to install policy:

a. When GW rules are removed from the Mobile tab in SmartDashboard, still seeing:

b. When mobile blade is removed from the gateway and the rule referring to it adjusted by replacing the gateway with "Installation Targets", still seeing this:

3. Mobile blade FTW, displays "Check Point Mobile for Windows" as one of the options for Desktop Clients, while Capsule VPN is only associated with "Mobile Devices":

Endless re-naming of and re-purposing the names for different types of clients is mind boggling.

Any suggestions on how to make SSL VPN accessible, manageable and the portal to work as intended, regardless the version of the OS, browser etc.., preferably notifying users about any incompatibility issues and describing workarounds interactively?

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Tue, 13 Feb 2018 22:16:31 GMT

Continuation of the previous post.

In a spirit of patience and perseverance, I've decided to take a look at the Jumbo HFA_Take70, that seem to contain the update for the Mobile Access blade:

With it deployed and caches of the browsers cleared, we are no further than we were: same missing mobile apps in the portal, same failure to install the SNX on the Windows 10, same missing compatibility notifications.

Following the breadcrumbs of SKs, links and redirects, arriving at this hotfix:

It being four months older than the Take 70, I would hope to see it included, but alas, it was not.

So with the hotfix installed, hope rekindled anew, going through the process again:

Now, when attempting to execute downloaded Mobile Access Deployment Agent:

And... that's it. We are greeted with all too familiar:

The hotfix has mentioned Chrome, so let's give it a try:

Upon clicking "Connect", we are prompted with:

After we are agreeing to "Trust server":

With "Continue Anyway" clicked:

And "Yes" and...:

Needless to say, I've parked the planned demo for the client until some light could be shed on this uncooperative feature.

Your input is, as always, welcome.

Re: What is wrong with Mobile Access in R80.10?

PhoneBoy — Tue, 13 Feb 2018 22:37:14 GMT

So does the SNX client even come up at all?

I can gather the portal isn't showing anything from your screenshots...

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Tue, 13 Feb 2018 22:43:10 GMT

Nope,I am getting no love from Mobile Access blade at all.

SNX does not come up, no custom apps or even sample apps are displayed in the portal.

The Check Point Capsule VPN, SecuRemote and EndPoint Security VPN are working if installed locally on client machines.

Re: What is wrong with Mobile Access in R80.10?

Gaurav_Pandya — Wed, 14 Feb 2018 14:08:45 GMT

Hi Vladimir,

I agree that so much customization is required on client machine for Mobile access SSL VPN. I have recently installed for one of customer. I had also issue with Windows 10 Laptop but here we have R77.30. Please install deployment version 7.01.0000, may be it will resolve the issue.

For more information refer below.

https://community.checkpoint.com/docs/DOC-2613-ssl-vpn-network-extender-issue

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Wed, 14 Feb 2018 21:57:19 GMT

Thank you Gaurav, I'll give it a shot.

My problem, besides the ability launch client, is the fact that the portal does not display any of the apps configured either in Unified Policy or the SmartDashboard's Mobile tab.

I've even re-build the gateway on the odd chance that something was wrong with it, but it made no difference.

Re: What is wrong with Mobile Access in R80.10?

Gaurav_Pandya — Thu, 15 Feb 2018 09:47:39 GMT

Ok Vladimir,

Just try with this deployment agent and let me know result.

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Thu, 15 Feb 2018 12:54:25 GMT

No dice:

This is the version that is installed on Windows 10. From Control Panel/Apps and Features:

When attempting to run the slimsvc.exe executable on Windows from "C:\Program Files (x86)\CheckPoint\SSL Network Extender", it is failing with redirect to:

Re: What is wrong with Mobile Access in R80.10?

Gaurav_Pandya — Thu, 15 Feb 2018 18:01:42 GMT

Oh This is strange..

Re: What is wrong with Mobile Access in R80.10?

John_Fenoughty — Thu, 15 Feb 2018 21:52:07 GMT

I have spent much of today on the same mission as you: converting an R77.30 Mobile Blade policy to an R80.10 unified policy. Overall it went well, all VPN rules are migrated and this site now has the blissful situation of a list of rules, in one policy, using access roles, mixing radius, AD and local Check Point user groups and controlling which clients (SSL extender, Endpoint, mobile etc. as part of the role in the rule. We were particularly pleased to be able to define destinations and applications all in the access rule-base and to be able to use network objects rather than the 'IP ranges' that one was forced to define in the now very legacy mobile blade. Introducing all of this to a new end user administrator now make so much more sense, it really was a ridiculous situation we have been in for the last 5 or 6 years!

My next bit of fun will be to look at the mix of Identity Awareness, generic*, 3rd party radius, local groups and LDAP groups to see if the exciting new Multiple Authentication Clients Settings (there may be a need for an apostrophe or one fewer plural in that window title) can enable me to provide a more coherent authentication offering to the users.

Now, for their next trick, Check Point MUST MUST MUST deal with the ridiculous client-sprawl, crazy nomenclature and licencing hell to which you allude in your original post!

At this point there are two issues that we share:

1. All legacy mobile rules have been removed, yet I still get this on policy install just like yours:

I've been scouting about for anything in KB articles, documentation and here but I have found nothing about this. I am thinking that I'd like to remove the 'shared policy' entirely but a few docs have hinted that there are still Mobile Policy elements configured in the 'legacy' policy - that said, I cannot find out which or what!

2. Where do all the published applications go? Silicon Heaven perhaps?

In this case the screenshot is taken on a Windows 7 client using Internet Explorer.

So, any Chrome, Firefox, Windows 10 or Java concerns are moot at this point (IMHO).

Just in case anyone who is about to do this job is reading this and having a go without reading the documentation in detail the key to making the switch-over is this setting in the gateway (cluster) object:

For the record, this is my favorite new element of this, and worth all the pain...

All of the client types are available in here and we can simply pick nd choose which any given role (thus rule) will use - brilliant and not before time!

Re: What is wrong with Mobile Access in R80.10?

PhoneBoy — Thu, 15 Feb 2018 22:44:49 GMT

1. All legacy mobile rules have been removed, yet I still get this on policy install just like yours:

I've been scouting about for anything in KB articles, documentation and here but I have found nothing about this. I am thinking that I'd like to remove the 'shared policy' entirely but a few docs have hinted that there are still Mobile Policy elements configured in the 'legacy' policy - that said, I cannot find out which or what!

This is a UX bug, as was noted previously in this thread.

For the record, this is my favorite new element of this, and worth all the pain...
All of the client types are available in here and we can simply pick nd choose which any given role (thus rule) will use - brilliant and not before time!

Got to say, I was not aware of this one.

That said, it's been the SecuRemote days (pre Connectra/Mobile Access Blade) since I spent any serious time with the Remote Access features.

And agree: nice feature

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Thu, 15 Feb 2018 22:59:19 GMT

Yep, this feature is certainly nice. It would've been nicer if the Mobile Portal would've actually listed published applications

Can you, maybe, give a swift hmm.. poke to the R&D team responsible for it?

Re: What is wrong with Mobile Access in R80.10?

PhoneBoy — Fri, 16 Feb 2018 00:17:14 GMT

If it's any consolation, I'm now digging into this, trying to set it up.

I'm kind of at the same point: I can't get apps to show up in the Web Portal either.

One question: do you have explicit rules in your policy allowing access to these web apps?

i.e. something like:

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Fri, 16 Feb 2018 00:31:04 GMT

I have a combo rule for the web and native apps:

Re: What is wrong with Mobile Access in R80.10?

Alex_Sazonov — Fri, 16 Feb 2018 05:45:35 GMT

Hi Vladimir Yakovlev and Dameon Welch Abernathy‌,

Please check section "Best Practices for Rule Order" in Mobile Access Admin Guide:

"In the Unified Access Control Policy, put Mobile Access rules that authorize applications above rules that contain a related service. For example, put a rule to allow a web application above a rule that allows or blocks HTTP/HTTPS. If the HTTP/HTTPS rule is first, the user will not see the Mobile Access Web application in the portal or in Capsule Workspace and will not be able to access it.

For example, this Rule Base allows Outlook Web Access (OWA), a web-based Mobile Access application. It also allows HTTPS traffic.

Correct way to allow the HTTPS service and also Mobile Access HTTPS applications:

Rule 2.1, that allows access to Mobile Access applications, including Outlook Web Access (OWA) on HTTPS, is above rule 3, which allows all HTTPS traffic.
If you put rule 3 to allow HTTPS above the Mobile Access rules, the user will not see the OWA Web application in the portal or in Capsule Workspace and will not be able to access it. To authorize a Mobile Access application, you must use a Mobile Access application in the Services & Applications column.
You can use HTTPS in the parent rule of the Mobile Access Inline Layer, but specify the Mobile Access application inside the Inline Layer. That way, the HTTPS traffic for OWA, for example, will match on the HTTPS rule, and will also match on the OWA App inside the Inline Layer. "

Also from the "Limitations for Mobile Access in the Unified Policy" section:

"If users do not meet the defined Protection Level requirements for an application, the application does not show for them. This is true in the Mobile Access portal and Capsule Workspace. (In the Legacy Mobile Access policy, the applications show but are disabled)."

I hope this may help you

Alexander Sazonov

Re: What is wrong with Mobile Access in R80.10?

PhoneBoy — Fri, 16 Feb 2018 06:48:09 GMT

So this raises a question.

In my application, I have set the Security Requirements to be "This application relies on the security requirements of the gateway."

Which I assume means "if I can access the Web Portal, I can access this application."

I've also moved my rules up to the very top of the rulebase and there are rules below that would permit the traffic from the gateway to the destination server:

Funny enough, the SMB entry shows on the portal, but doesn't work because my Samba server isn't configured to allow NTLMv1 logins

Only the "Jekyll" web application doesn't show.

How can I debug this?

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Sat, 17 Feb 2018 17:05:08 GMT

Alexander,

Thank you for bringing the sequencing to my attention.

I've tried following the steps described in the "Best Practice for Rule Order" document and, as Dameon did, build the policy from scratch placing pertinent rules on top:

Two apps that did show-up in the portal are the webapps configured with pointers to DNS names of the targets:

The one that is missing, was pointed to a dummy host object:

So, for now, the situation as I see it:

1. We cannot verify validity of the applications when creating them

2. We cannot verify validity of the MAB rules

3. There is a difference in treatment of DNS-based targets and Object-based targets

4. We cannot see "Native" applications in the portal, because we cannot launch SNX from Windows 10 (at least)

5. There is no mechanism in the portal that allow distribution of other (may be pre-configured) endpoint VPN clients

Dameon, can you tell me if you got any further with your tests?

Re: What is wrong with Mobile Access in R80.10?

PhoneBoy — Sat, 17 Feb 2018 18:36:24 GMT

I haven't gotten any farther, but you're doing a few things I haven't tried yet--something to play with later.

The MAB portal will only distribute SNX client, not others.

I suppose you could put them on an internal webserver and server THAT up through the MAB web portal.

Re: What is wrong with Mobile Access in R80.10?

Vladimir — Sat, 17 Feb 2018 18:51:28 GMT

Well, that's an idea. We could call the web app "Windows 10 users click here" to get them to the source files.

Still small probability that they'll do that because well, users.

Would be nice to have:

1. OS detection and redirect to a different view of a portal

2. Built-in Guacamole with SSO (may have to work-out my own integration for it).

3. Portal customization to remove current "Native Application" option

Re: What is wrong with Mobile Access in R80.10?

Gaurav_Pandya — Sun, 18 Feb 2018 09:59:09 GMT

Hi Vladimir,

You can achieve first point with Endpoint security on demand --> Compliance check. You can put condition with Windows 10 OS and redirect to particular URL.

Also you can do Portal customization on Portal Settings.