SecuRemote - Secondary connection

[k_b]

Dear all,

Currently we are struggeling with SecuRemote and I hope you can help / clarify some points.

There are two CheckPoint gateways, lets call them CP_A and CP_B. CP_A, which uses a private IP, is not under our control and we do not have access to the configuration / any details of this system. A VPN to this gateway (CP_A) is used to access systems in the domain D_A. The authentication is done via a SmartCard and a (cached) PIN. The other gateway CP_B is used to create a VPN to access systems in domain D_B. To access CP_B you have to use a proxy because it is a public IP.  To authenticate to this gateway a certificate protected by a password is used. There is no (technical) connection between these gateways. Both are configured as sites in the SecuRemote client and in case only one connection is created each VPN is working as expected. But when establishing to VPNs we are seeing different behaviour.

I. If I now first create a VPN to CP_A and then want to access a target which is in the domain D_B the login prompt is created / shown and silently dropped after the credentials are provided. There is no visible error message in the GUI that some went wrong. The targets are just not availalbe.

II. If I now first create a VPN to CP_B and then want to access a target which is in the domain D_A, both access to systems in D_A and D_B is possible.

Why is the access possible in II but not in I?

In case I, it is

- not possible to see any access to the gateway CP_B via fw monitor / tcpdump etc.

- possible to see via WireShark that packets are send out to the gateway.

- possible to see that it did not worked by checking the client logs trac.log / diagnostic_history.log

"Creating secondary conn flow to..."

"Starting new connection (1)"

"Client state is connecting"

"Connecting: secondary tunnel failed"

- possible to see in trac.log that "is_secondary_connect_enabled_and_supported_on_gw" is true

- possible to see that it is recognized that a system in in another domain

[TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: ======= TUNNEL ROUTING =======
[TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: This packet should go to Encryption domain index: 2
[TR_OFFICE_MODE] TrOfficeMode::OmSendIpFrameCB: we have no handler connected for this Encryption domain (2). notify ConnManager
[TR_CONN_MANAGER] TunnelNeeded: tunnel requested for encryption domain 2

- possible to assume that something is not working correclty with the proxy which is required to access CP_B

... ProxyWrapper::DoConnect: Creating a new connection gw: <CP_B-IP>, port: 443
...
... ProxyWrapper::DoConnect: init connect successfuly
... ProxyWrapper::Connect: Successfully init connect
... ProxyWrapper::Connect: Starting ...
... ProxyWrapper::Connect: cb_opq = 37518720
... ProxyWrapper::Connect: prxConn = 37520320
... ProxyWrapper::Connect: currentConns[prxConn] is NO_AUTH_PRX_STATE
... ProxyWrapper::Connect: *** (prxConnHandle->ConnState is INIT_STATE
... ProxyWrapper::Connect: *** currentConns[prxConn] is NO_AUTH_PRX_STATE
... ProxyWrapper::isProxyConnectivityAnalysisRequired: Starting ...
... ProxyWrapper::isProxyConnectivityAnalysisRequired: mGlobalConnectivityPreferringMode is INIT_STATE
... ProxyWrapper::isProxyConnectivityAnalysisRequired: proxy Analysis phase already started -> not required
... ProxyWrapper::Connect: proxy Analysis phase is not required -> this is probably part of it (this conn may be part of it or not) -> use currentConns[prxConn]
... ProxyWrapper::isProxyConnectivityAnalysisInProgress: Starting ...
... ProxyWrapper::isProxyConnectivityAnalysisInProgress: INIT_STATE == mGlobalConnectivityPreferringMode -> in progress
... ProxyWrapper::Connect: proxy Analysis phase is not in process or this request is part of it -> proceed...
... ProxyWrapper::Connect: debug: prxConnHandle->ConnState is NO_AUTH_PRX_STATE
... ProxyWrapper::Connect: about to DoConnect...
... ProxyWrapper::DoConnect: Starting ...
... ProxyWrapper::DoConnect: Current state is NO_AUTH_PRX_STATE
... ProxyWrapper::DoConnect: Connecting to proxy..
... IsProxyDetected: Starting... m_proxyState.m_autoDetectFileLoadedOk - 'FILE_DOWNLOAD_NOT_NEEDED', m_proxyState.m_PACFileLoadedOk - 'FILE_DOWNLOAD_SUCCEED'
... IsProxyDetected: Proxy is detected
... ProxyWrapper::DoConnect: No proxy is defined. Cannot connect via proxy.
... ProxyWrapper::DoConnect: Moving to state AUTH_PRX_STATE with already 2 retries
... ProxyWrapper::DoConnect: Current state is AUTH_PRX_STATE
... ProxyWrapper::DoConnect: Connecting to proxy..
... IsProxyDetected: Starting... m_proxyState.m_autoDetectFileLoadedOk - 'FILE_DOWNLOAD_NOT_NEEDED', m_proxyState.m_PACFileLoadedOk - 'FILE_DOWNLOAD_SUCCEED'
...
... ProxyWrapper::NotifyConnect: Starting ... prxConnHandle is 37520320
... ProxyWrapper::NotifyConnect: prxConnHandle is: 37520320 conn state is NO_PRX_STATE
... ProxyWrapper::NotifyConnect: note: conn managment - do not reset the conn - in order to release it later - if it is reset then there is no way to notify the FW later in order to remove the rule
... ProxyWrapper::NotifyConnect: *** conn address is: 0
... ProxyWrapper::NotifyConnect: *** conn address is: 0
... ProxyWrapper::NotifyConnect: Failed to connect. Notify the error.
... ProxyWrapper::connectivity_analysis_proxy_cb: Starting ... conn is 0, status is -1000
... ProxyWrapper::connectivity_analysis_proxy_cb: (client / orig) conn address is: 37520320 conn state is INIT_STATE
... ProxyWrapper::connectivity_analysis_proxy_cb: Failed to connect. status = -1000
... MessageLoop::MessageLoop::SchedCB: entering.
... ProxyWrapper::Connect: status != RAISOS_STATUS_SUCCESS
... ProxyWrapper::DoProxyConnectivityAnalysis: proxy attempt failed....
... ProxyWrapper::DoProxyConnectivityAnalysis: done - OK

- possible to see that the proxy access seems to be functional in case II

...[proxy_wrapper] ProxyWrapper::DoConnect: NTLM global is turned on - setting it on the current entity
...[proxy_authentication] init: Construct for <CP_B-IP>:443, through proxy <Proxy_IP>:8080
...[proxy_authentication] connectToProxy: enter
...[proxy_authentication] isExist: Using proxy.

- possible to see that also in case II the proxy is used to access GPA

... [proxysupp] IsProxyDetected: Proxy is detected
... [proxy_authentication] proxyEntity::proxyEntity(1): enter...
... [proxy_wrapper] ProxyWrapper::DoConnect: Created a new proxy entity 03427FB0
... [proxy_authentication] setFwdEnv: setting fwd env to 036CC018
... [proxy_wrapper] ProxyWrapper::DoConnect: NTLM global is turned on - setting it on the current entity
... [proxy_authentication] init: Construct for <CPA>:443, through proxy <Proxy>:8080
... [proxy_authentication] connectToProxy: enter
... [proxy_authentication] isExist: Using proxy.

The main question is: Why is he able to use the proxy for the second system in case II but not in case I?

CheckPoint Quantum 3600

Version: R81.99

Take: 81

Thanking you in advance.

[G_W_Albrecht]

Looks like the configuration is different on the respective GWs.

[PhoneBoy]

I assume this is R81.10 as there is no R81.99 release 🙂

In any case, this points to a configuration issue on Site A (likely in the Encryption Domain).
Probably the easiest way to verify this is to compare the differences in the client's Routing Table when connected to Site A versus Site B.

[k_b]

Oh, yes, you are correct, this was a typo. It should have been R81.00.

When connecting first to CP_A both routes, the one to CP_B and to the proxy are the same. The issue is, that there is not even a connection to the CP_B in case CP_A was connected first. I would exclude the encryption domain of CP_B due to that. Due to the fact that also both routes (proxy / CP_B) are the same for VPN connected to CP_A / VPN not connected to CP_A I would also exclude the encryption domain of CP_A. I really don´t understand why the proxy can be used for CP_B only when this is the first Remote Access VPN, but can be used for CP_A no matter if it is the first or the second VPN.

One additional note: When changing the proxy settings from "Detect proxy from Internet Explorer settings" to "Manually define proxy" and then using such a manually defined proxy it is working. In case the proxy is generally a issue, why not also in the first place and why only for CP_B in the case it is the seconds target?

[PhoneBoy]

I'm not clear what you mean by "first or the second VPN" here.
Does it refer to definition in the client (i.e. Add New Site)?
Or does it refer to connection (connect to CP_A first, then CP_B)?
Are they connected simultaneously?

The routes I am interested in are the routes to the proxy IP when the VPN is connected in both cases.
Also, what version of client was installed?
You claim it was installed as SecuRemote, is that correct or was it installed as "Check Point Mobile" or "Endpoint Security VPN"

It still feels like there is some "overlap" between CP_A and CP_B.
It may be because the CP_A is configured to use Secondary Connect for something in CP_B's encryption domain that it prefers to use that.
This will probably need a TAC case to troubleshoot further: https://help.checkpoint.com 

[k_b]

"Are they connected simultaneously?"

Yes, the VPNs are connected simultaneously.

When the connection to CP_B is created first and the one to CP_A, both are working as expected.

When the connection to CP_A is created first and the one to CP_B, only the CP_A connection is working as expected.

"The routes I am interested in are the routes to the proxy IP when the VPN is connected in both cases."

The route to the proxy is the same in all three cases (on VPN, VPN to CP_A, VPN to CP_B).

"Also, what version of client was installed?"

E86.60

"You claim it was installed as SecuRemote, is that correct or was it installed as "Check Point Mobile" or "Endpoint Security VPN""

"It may be because the CP_A is configured to use Secondary Connect for something in CP_B's encryption domain that it prefers to use that."

There is no logical connection between CP_A and CP_B. On CP_B secondary connect is left in the default settings. But when the two gateways are not part of the same management system etc. seconadary connect should not apply, or am I wrong?

[PhoneBoy]

While Secondary Connect can be set on the client side, it can be forced on the gateway side with no ability to disable it.
Further, the first site added to the client is given priority if there are any configuration conflicts.
I suspect this is what is happening when CP_A is added first in this case.
When you add CP_B first, that site takes priority and the "overlap" between CP_A and CP_B is resolved in favor of CP_B.

One thing we haven't tried is looking at trac.config on the client.
The file is obscured by default and requires the following procedure to unobscure it: https://supportcenter.us.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&so...