Remote access without visitor mode enabled?

[George_Dumitru]

Hello,

What options do I have to configure remote access without enabling Visitor Mode? 

Following the Remote Access VPN guide looks like it's mandatory as it's specified in the basic gateway configuration. It's not clear to me how you can set it up without it.

However, this feature opens ports 80, 443 and 264 TCP to the Internet. Why are all of them necessary and how could I restrict them?

Which VPN client can connect to the gateway when visitor mode is disabled?

Thanks,

George

[G_W_Albrecht]

No, it is not mandatory, see for details sk159372: Visitor Mode in Remote Access clients !

[George_Dumitru]

It says it's a backup mechanism but with the Mobile Access blade enabled (which is required in order to use Office Mode with IP pool for the Check Point Mobile client) it's by default enabled and greyed out, it cannot be disabled.

If you only have the IPSec VPN blade enabled, without the visitor mode feature, the gateway doesn't answer to connection requests from VPN clients. It actually warns you when disabling it that VPN Clients (except for the old Secure Client) will not be able to connect.

I haven't found a workaround yet.

Thanks,

George

[mdjmcnally]

There is a reason that is needed and this is what it is.

The VERY first time you connect to a VPN Gateway with a Client it asks you to trust the VPN Certificate as being from the ICA then is not a Trusted CA.

That connection is made over HTTPS not IPSEC protocols

You will see subsequently when you connect that before the IPSEC tunnel is initiated then the Client makes a HTTPS connection to the Gateway.

The Visitor Mode allows this HTTPS connection to be made.

No response from the HTTPS request and the IPSEC tunnel doesn't attempt instead it says is unreachable etc.

264 is the fw1_topo port that used for downloading the topology.

You don't know in advance where they are coming from so you have to have open everywhere.

Same as port 500 and proto 50/51 to allow the IPSec Tunnel to build, you don't know the source so has to be open, of course it doesn't stop them being reported by scanners as vulnerabilties but won't work without them being open

[George_Dumitru]

Hello,

Thanks for the details, this makes sense.

Following this logic, after I connect the first time and create the site, I should be able to subsequently connect from the same device even if visitor mode is disabled.

Is this correct? Should I be able to connect using Office mode after initial trust is established, with visitor mode disabled? This means mobile access blade removed, and only IPSec VPN active in order to be able to disable visitor mode.

[mdjmcnally]

Unfortunately you will still see the Client make an attempt to connect with HTTPS every time make a connection.

You can probably get rid of Visitor Mode as long as have a rule open to allow HTTPS to the Gateway as an Explicit Rule, which effetively results in the same rule.

Most people will have moved the Gaia Portal off HTTPS 443 to another port so isn't as if that big a deal having HTTPS open on the box as the HTTPS should only be there for the Remote Access at that point.

[Jonathan_Griffi]

Hi,

Has anyone confirmed that RA VPN clients (EndPoint Security VPN) can connect when visitor mode is disabled (providing an explicit HTTPS rule is added to the policy)?

In my environment we have moved the portal to a different port, when visitor mode is on (running on port 443), the "enable_tcpt" implied rule is implemented (this isn't configurable via the normal implied rule area, sk119497 explains this). The clients can configure sites and establish phase 1 / 2 normally. However, when turning visitor mode off, and then having an explicit HTTPS rule in the access policy the client is no longer able to connect or create a site / establish VPN. The observed behaviour suggests there is a service which is enabled when visitor mode is enabled which answers requests from the Endpoint Security VPN clients (or possibly this is additional function of visitor mode?). I understand the requirement for visitor mode (sk159372 explains this perfectly). Interestingly, sk159372 also advises to avoid visitor mode if there is no need for it.

So how come EndPoint Security VPN Clients are unable to connect to the gateway when Visitor mode is disabled and an explicit HTTPS rule is implemented in the access policy?

Is anyone from Check Point able to answer / confirm the above? 

Thanks,

Jon

[Timothy_Hall]

My guess would be that disabling Visitor Mode is affecting something in the MultiPortal feature, which arbitrates access to port 443 on the gateway since it is used by so many different features:

sk155512: How to determine which portal is causing MultiPortal to respond on external interface

[HristoGrigorov]

VPND process is listening on port 443 and Endpoint Security VPN always uses this port to negotiate tunnel. That kind of requires Visitor Mode to be enabled if you want to use this client or capsule. 

[Jonathan_Griffi]

Thanks @Timothy_Hall and @HristoGrigorov ,

You guys helped point me in the right direction.

I did some further reading/testing, It does appear as you say @Timothy_Hall , the mpdaemon has a portal called "clients", which is bound to port 444. When visitor mode is disabled, this portal is removed. It would, therefore, seem visitor mode enables the client portal which supports the hand over of the HTTPS (or whatever visitor mode port is chosen) traffic from Endpoint Security Clients (and possibily other remote access clients) to the vpnd process via port 444.

I don't know if the above is 100% accurate, but the behaviour seen would fit that description. 

Thanks again,

Jon

[Garrett_DirSec]

Hello Folks -- I'm working with customer who recently upgraded from R77.30 to R80.40.    Part of upgrade includes having to enable Visitor Mode on VPN setup -- in addition to explicitly allowing port 80 (in addition to 443).    Their remote-access VPN under R77.30 did not require http/80 or visitor mode and customer feels turning on all additional features -- and opening up ports (especially tcp/80) -- increases complexity and necessarily increases security risk (his words).

reference scenario #8 on following:

Troubleshooting "site is not responding" Issues

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

What can I tell him?   -GA

[PhoneBoy]

The only place where it is required for sure is when you are first defining the site.
After that, it shouldn't be strictly required. 

[Garrett_DirSec]

Hello @PhoneBoy  -- thanks for quick follow-up.     I suggest it's pointless to provide the checkbox implying "optional" for visitor mode.   If it's required, then HIDE it in GUI and make it default prefs under the covers (behind the scenes).     In other words,  why give the option to enable/disable something if it's required with R80.xx remote access VPN?   that seems silly. 

[PhoneBoy]

It is required even after the site is defined on the client? I don't believe so.
If it is, it's either a bug OR we need to update the documentation.

Note if you disable Visitor Mode, then you have to distribute to your users an installer that has the site predefined in it. 

[Eric_Oakeson]

Hi @PhoneBoy, the customer tested this yesterday and without Visitor Mode enabled, he cannot connect. He enabled it to set up the site initially, successfully connected to the VPN, then disabled Visitor Mode and couldn't connect again.

[JackPrendergast · Accepted solution]

Hi,

@PhoneBoy  is right. After site creation, it shouldnt be needed.

It depends if the client can reach the firewall on port 4500. If it cant, it will switch to 443.

Is there any local endpoint firewalls blocking 4500?

Any upstream blocking of that port?

To check fully, please follow the below to properly prevent visitor mode being used.

1. As I said above, on the client side, check that there is no firewall that blocks 4500. If there is, make sure to allow port 4500.
2. Check that there is no duplicate object that uses the same IP as the IP used in Link selection settings - This is a common reason for visitor mode.
3. Check that the option in IPSec VPN, VPN Advanced, "Support NAT traversal" is enabled.
4. Check that the option VPN Clients, Office Mode, "Support connectivity enhancement for gateways with multiple external interfaces is enabled"
5. Check that the IPSec VPN, VPN Advanced, Link Selection that the correct interface to which the client is connecting is selected.

Thanks.

[Eric_Oakeson]

Thanks @JackPrendergast, I'll check to see if there's anything else blocking 4500, as that should be covered in the implied rules for the gateway itself and isn't blocked that I'm aware of.

[PhoneBoy]

A TAC case might be required here to understand what's going on.

[Garrett_DirSec]

Hello @JackPrendergast and @PhoneBoy .     

a little background.   

1. current customer R80.40 (+HFA) distributed setup recently upgraded from all-in-one R77.30 (_HFA).     
2. The hostname -- and IP -- of SmartCenter service host has changed.   upgrade was done via sk154033 (BELOW).
3. The result dedicated R80.40 SmartCenter has an ICA with DN structure that still references the hostname of original stand-alone smartcenter object.     I recall from R77.xx word that changing hostname of SmartCenter required a SIC reset.   
4. I recently found newer R80.xx sk164055 that details procedure to change smartcenter hostname that does not include SIC reset.   
5. It appears that changing IP address of Smartcenter still requires either SIC reset or sk40993 (to update CRL references). 

With previous all-in-alone R77.30 platform, there was NO rules to allow http/80 or https/443 from Public/External.    Also, Visitor mode was disabled.  

Remote-access VPN worked fine on this R77.30 platform (don't know endpoint product used).

However, with dedicated gateway running R80.40 (recent HFA) -- and Checkpoing MOBILE client E83.xx -- we need both explicit policy allowing (a) tcp/80 and tcp/443,  and (b) visitor mode.

Because everything worked FINE with r77.30 platform, I'm hesitant to make many changes (as this also makes customer uncomfortable with perception of relaxing security posture by explicitly allowing direct connect to gateway over tcp/80 (for example).

should we reset SIC on this simple distributed setup to clean-up ICA?    

thanks -GA

How to migrate R80.x standalone management environment to a distributed environment

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Changing R80.x Security Management Server Name

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

How to change the IP Address of a Security Management

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[JackPrendergast]

Hello @Garrett_DirSec 

Firstly, dont reset SIC.

SIC has nothing to do with your issues here, and talk re. cleaning up the ICA is irrelevant.

So - ignore that. If your SIC communication is established and working fine, then leave it 🙂 

I suspect you may have VPN configuration changes then, hence the reason why its connecting over 443.

Some settings and features change from 77.30 to 80.40. 

Have you seen my post above?

Please can you check through those 5 steps and report back? These ALL need to be adhered to in order to restrict visitor mode.

If all of these check out fine, and you are still seeing issues, then I fully agree with @PhoneBoy about engaging TAC.

I just don't want TAC to turn around and ask you to check similar parameters as to what we have said above! 🙂 

[Garrett_DirSec]

Hello @JackPrendergast .   thanks for your msg.    I reason I asked about ICA was based on various searches on knowledgebase and some references to issues with endpoint vpn connectivity based on cert issues.       we did check through the five steps you provided and NAT_traversal was not being explicitly allowed (tcp/4500).  

remote access VPN SITE CREATION now successful (without Visitor Mode enabled).  

now we can walk customer through creation of MSI installer updates for CP MOBILE to include the site. 

[JackPrendergast]

Glad this worked for you.

Take care.