What is wrong with Mobile Access in R80.10?

[Vladimir]

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?  

[Vladimir]

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...:

No

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.

[PhoneBoy]

So does the SNX client even come up at all?

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

[Vladimir]

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.

[Gaurav_Pandya]

Hi Vladimir,

We are planning to move one of our customer from R77.30 to R80.10. They have Mobile access blade with SNX. So just thought to ask that you got the solution for this?

SNX is working fine with R80.10? or need lots of fine tunning

[Vladimir]

I was not able to implement SNX in R80.10 with any degree of reliability or consistent behavior across browsers.

See previous posts in this thread for all the kinks that were encountered. Hopefully it'll be better in R80.20. 

[Gaurav_Pandya]

Ok Vladimir,

Thanks for the information.

[Alex_Rozhko]

I am on 80.10 with mobile blade in legacy mode for over a year now. In my environment SNX integrated with AD and 2-fa using SMS authentication. Unfortunately there is no conversion scripts available and none will be available with 80.20. Just finished converting legacy rules to unified 80.10 policy with test implementation next week.

As far as SNX functionality in 80.10, - it works as long as Microsoft, sunjava or browsers do not mess mess it up.

Alex

[Gaurav_Pandya]

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

[Vladimir]

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.

[Gaurav_Pandya]

Ok Vladimir,

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

[Vladimir]

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:

[Gaurav_Pandya]

Oh This is strange..

[Alex_Rozhko]

Vladimir, try IE. SNX/Edge never worked for me on 77.30 or after migrating to 80.10 (MBA) rules are still in legacy. In some cases running IE as admin helps as well. Chrome still gives trouble because of java. Firefox, will be combination Of browser version and win10 build, 1607, 1703, 1709

[Vladimir]

I can try it, if only for experiment sake. In large corporate environments you can't really expect the users to have "run as admin" rights on their laptops.

[John_Fenoughty]

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!

[PhoneBoy]

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

[Vladimir]

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?

[PhoneBoy]

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:

[Vladimir]

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

[Alex_Sazonov]

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

EA

[PhoneBoy]

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?

[Vladimir]

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?

[PhoneBoy]

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. 

[Vladimir]

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

[Gaurav_Pandya]

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.

[Vladimir]

Gaurav,

Thank you for the suggestions.

Unfortunately, portal customization is limited to the addition of the logo and the title:

The "Alternative Portal" option seemingly looks better, but it is limited to User Groups, rather than Client Types:

And the "Endpoint Security On Demand" does not contain Windows 10 as one of the OS options:

You may be onto something here, since we can try checking the registry keys for OS version, but while you can display the link to "remediation URL", you are not forcing the redirect to a different version of portal.

It is possible that I am missing something and, if you can post the details of how to achieve the desired effects, I will be grateful.

Regards,

Vladimir

[Asaf_Livne]

I would like to address some of your original points, hopefully it will be helpful:

First, not sure how familiar you are with the Mobile Access policy model. Back in R77.x the Mobile Access policy was defined in the SmartDashboard on its own dedicated Mobile Access tab.

In R80.10 we introduced the option to define the policy in the Unified Access Policy, this is the Unified Policy option. One can still define this in the previous way, in the Smart Dashboard, which is the default and referred to as the Legacy Policy.

As you noticed, you can toggle with the Policy Source option to choose which the Mobile Access policy will be used.

* Policy verification error “R80.10 gateway cannot be included in the Mobile Access Legacy Policy when Mobile Access unified Policy is the selected policy source”:

As mentioned, this is indeed a known bug, which was resolved in R80.10 Jumbo take 70.

The greyed-out checkboxes for Portal URL and SSL Network Extender: this is by design, but I agree the UX around it can be improved to not confuse users that this is a bug, we will see what can be done.

* Policy verification error “The Mobile Access Policy does not contain any rules”:

This is an expected error if the policy source is the Legacy Policy and indeed it contains no rules. If I understand correctly, you configured your policy source to the Unified Policy when this was encountered, in this case this should not be shown. We will double check this in our labs. But if you were on the Legacy Policy, make sure to have at least one rule defined, otherwise Mobile Access has nothing to enforce, hence the error.

* SNX did not connect, before and after installing the deployment agent HF, in neither browsers: Now, this is strange, because it was thoroughly covered in our labs and we know concrete customers that have this working. We have doubled-checking this and it works flawlessly in our labs. It could be a misconfiguration. I would suggest seeing which IP is defined on the gateway object in Smart Console, and if it is a routable and main IP you intended. The SNX client will attempt to connect to this IP, if it is not routable, one can expect the SNX client to endlessly try to reach it. In addition, I would also suggest to try and remove the SNX installation (from the Add/Remove Programs) and try to reinstall it by browsing to the portal after it is uninstalled.

In any case, I do agree that in such a case we have room for improvement in the UX around notifying the user on such as case.

* Firefox and Chrome compatibility – In order to use SNX from the SSLVPN portal, via Firefox and Chrome, one indeed must install the Mobile Access Deployment Agent HF.

Due to the scope of functionality introduced in this HF, it was not yet integrated to the Jumbo releases, we have concrete plans for this, but it will take a bit more time.

* Web applications are not published in the SSLVPN portal: The way it works is, that the portal will show only applications the logged in user is authorized to. This means that after you defined the web application, you need to define a rule in the Mobile Access policy, which allows the application to the user.

In the Legacy Policy, navigate to the Policy tab and place a rule with a user group containing the intended user, and then in the same rule place the intended we application you want to publish for that user.

If you choose to use the Unified Policy, this is similar, just used an Access Role object (instead of a plan user group) as the source and place the application in the Applications column.

* If you still have any questions or if things are not working as expected, I strongly suggest to engage with our excellent Technical Assistance Center, who can guide you through your obstacles.

[Gaurav_Pandya]

Hi Asaf,

We have R77.30 and Mobile access SSL VPN works well with IE browser. But client wants to open it from Firefox browser. We are facing issue with Firefox in Network Extender.

I have installed Add on hotfix for Firefox browser sk113410 - Check_Point_R77_30_jhf_T266_MABDA_sk113410_FULL.tgz

Also installed 32 bit JAVA & 32 bit Firefox browser but it is not working.

[Vladimir]

Asaf,

Thank you for your reply.

According to the Check Point Remote Access Solutions , SNX is NOT listed as one of the options available for Windows 10:

* Firefox and Chrome compatibility – In order to use SNX from the SSLVPN portal, via Firefox and Chrome, one indeed must install the Mobile Access Deployment Agent HF.

Due to the scope of functionality introduced in this HF, it was not yet integrated to the Jumbo releases, we have concrete plans for this, but it will take a bit more time.

I've seen the Mobile Access Deployment Agent HF installing in Chrome, but not in Firefox.

* Web applications are not published in the SSLVPN portal: The way it works is, that the portal will show only applications the logged in user is authorized to. This means that after you defined the web application, you need to define a rule in the Mobile Access policy, which allows the application to the user.

In the Legacy Policy, navigate to the Policy tab and place a rule with a user group containing the intended user, and then in the same rule place the intended we application you want to publish for that user.

If you choose to use the Unified Policy, this is similar, just used an Access Role object (instead of a plan user group) as the source and place the application in the Applications column.

These are the rules in the lab I am working with:

The AccessRoleAnyClients object is configured: Any Network, Any User, Any Client.

The WebPortalClients object is configured: Any Network, Any User, WebPortalClients:

I understand that the combined brain power of the end users and TAC can make this work (eventually), the idea is to have the R&D process steered towards delivering something more streamlined than what we currently have.

Regards,

Vladimir