Secondary connect R77.30

[Maxim_Medvedev]

We need to provide access to branch resourses to remote users via VPN, now only headquarter gateway participates at remote access community.
We use CheckPointVPN E80.61 client.

As I understand Secondary Connect is what I need, the solution is:
Enabling Secondary Connect for Remote Access Clients E75.20 and above 

I found administration Guide for Secondary Connect for R80.10, I cannot find any for R77.30

Does Secondary Connect works with 77.30?

If it does, can it be set up following this steps (from R80.10 Guide):

1. Make sure the gateway has a server certificate that is signed by the internal Certificate Authority.
2. On each gateway, open the $FWDIR/conf/trac_client_1.ttm configuration file.
3. Set the :default value of automatic_mep_topology to true.
4. Find enable_secondary_connect. If you do not see this parameter, add it manually as shown here:
:enable_secondary_connect (
:gateway (
:map (
:true (true)
:false (false)
:client_decide (client_decide)
)
:default (true)
)
)

1. Make sure the :default value of enable_secondary_connect is true.
2. Save the file.

3. Install the policy.

Are there any other steps that need to be taken?

[G_W_Albrecht]

I would assume that you need to use MEP - this is covered in VPN Administration Guide R77 Versions p.139ff.

[Maarten_Sjouw]

Forget editing the trac_client file, why? First it is dangerous as it is very picky on the format, second as you don't need to change anything at all. those settings are the default.

To see all the default settings in the trac_client file look at sk75221.

What you do need to do is make sure you do not have an overlap in the VPN Domain of the the gateways (if needed set this for the remote access separately), now just add the other gateways to the Remote access community and setup Office mode per gateway.

Keep in mind that your client will use the IP it gets from the gateway you sing into.

Lets say you have 3 gateways you want to use for this, you assign the following IP ranges to the 3 gateways:

GW1 with 10.10.1.0/24

GW2 with 10.10.2.0/24

GW3 with 10.10.3.0/24

Now you have in your login screen 3 sites (after you login the first time after you set this up) and you choose GW2 to connect to, you will be assigned a 10.10.2.x address, this address will be used for ALL connections to all 3 gateways. So make sure not to route those networks over MPLS or other back-end connections.

When you use AD to authenticate the users and your sites do not have a local AD server, and those sites are only connected over a VPN, make sure to disable LDAP in the implied rules, as it will not be encrypted by default. see SK26059.

[Maxim_Medvedev]

Thanks for reply!

If I understand you correctly, Secondary Connect already enabled in R77.30. Is that right?
There is no (enable_secondary_connect) section in trac_client_1.ttm file.

[Maarten_Sjouw]

As you can see in SK75221 it shows default enabled. This is why I hate manuals that say to add something that is already enabled.

[Maxim_Medvedev]

Secondary connect works after I add branch gateway to Remote Access community.

Authorization is performed on the main gateway and when I access to host at the branch site, secondary tunnel established.
But I cannot connect directly to branch gateway, error "site is not responding"

Maybe the reason is certificate installed on branch gateway?

Subject Alternate Names in main gateway internal certificate is public IP address of the gateway, while Subject Alternate Names in branch internal certificate is management (private) IP address of the gateway.

Should I reissue certificate with public IP at Subject Alternate Names?

[Maarten_Sjouw]

Although you authenticate the first connection to the primary gateway, every other tunnel will be authenticated with the same credentials. Do you see the second Auth request? What type of authentication do you use?

The cert should not be a problem, as it does not really look at the IP's.

[Maxim_Medvedev]

Hi!

I tried two methods of authentication

local account

AD account

Both times I recieved second authentication request, it was successful and the second tunnel was established.

Originally office mode network at branch gateway (10.1.180.0/24) was inside VPN domain (10.1.0.0/16) and I changed it to anoter network. But error was the same: "site is not responding"

At the main office gateway two certificates are installed: from internal CA and from Active Directory (with CN equal to public VPN interface of gateway CN=vpn.mycompanyname.com)

At the branch gateway only internal CA certificate is installed.

Is that certificate nececcary for Secondary Connect VPN scheme, or it is user only for SSL VPN?

[Maarten_Sjouw]

Make sure that you do not have any overlap in the VPN domains of the gateways, there is a separate field in the VPN Topology area where you can add a VPN domain explicitly for Remote access. 

At what point do you get the Site not responding?

Secondary connect will make the connecting without any assistance from you, just try to connect (ping) to any device in the second location.

On the second location, make sure that routing for the Office Mode IP range of the primary GW is routed to that secondary gateway. 

the second login is normal, and will only happen once, the next time you login (if you set the login credential caching to a time that is around 1 hour) it will know you and the site and will use the cached credentials.

The certificates are irrelevant for secondary connect, the gateways cert is sufficient.

[Maxim_Medvedev]

Thank you, this question is quite clear

I have another one:

I use custers (two gateways in Cluster XL high availability)

There is certificate for cluster from internal CA and there are certificates for both gateways too, but they are expired.

Does this gateways certificates have any matter for Secondary connect?

I can establish tunnel to branch gateway, and have access to branch resources via this tunnel, but I cannot connect to it directly. Is that normal?

[Maarten_Sjouw]

when you go into the gateway object to the IP/Sec tab and see that the certificate there is expired you should just click renew. Yes this is needed for all VPN´s that use the certificate.

Always make sure they are valid.

I don´t understand your second question.

[Maxim_Medvedev]

Hello, I ask you:

"I can establish tunnel to branch gateway, and have access to branch resources via this tunnel, but I cannot connect to it directly. Is that normal?"

I mean that I can only connect to HQ gateway, when I change gateway to branch gateway in "Gateway" field of Endpoint Security Client, I recieve "site is not responding" error.

I use local Checkpoint user or AD user, error is the same.

When connecting to HQ gateway, I can get access to branch hosts via Secondary Connect tunnel.

As I understand with Secondary Connect I should be able to connect to any gateway in Remote Access community.

[Maarten_Sjouw]

Did you add the second gateway to the Remote Access community and did you install policy to that gateway?

You should be able to connect to that gateway directly, if that does not work, check the Remote Access settings in that gateway object and adjust where needed, ie you need to turn on Support Visitor Mode.

[Maxim_Medvedev]

Thank you!

You point me to the right direction, I've enabled SSL Network Extender:

I also add Firewall rule to permit ssl traffic to external interface of gateway.

Gateway started to accept SSL connections.

But there is still no connections directly to gateway.

In wireshark I can see SSL communications and ISAKMP communications

ISAKMP communications ends with icmp Destination unreachable (Port unreacheable) messages from client side, although it started successfuly, but after three packets client responced with icmp Destination unreachable (Port unreacheable) messages.

I cannot understand what is missing this time

[Maarten_Sjouw]

You need to click the Plus sign in front of VPN Clients then in that list select Remote access:

Here you need to enable Support Visitor Mode.

[Maxim_Medvedev]

Support Visitor Mode enabled and it was already enabled.

I also check IKE Properties in Traditional mode configuration...

...and change it to match settings in Global Properties:

And of course I save and install policy after every change of settings

[Maarten_Sjouw]

What does tracker show when you filter on the second gateway as destination?

Specially when you know the IP of the client this should help filtering.

PS do make sure you are NOT on the LAN of any of the Check Point FW's in your envirnoment.

[Maxim_Medvedev]

Yes, there is something:

traffic to establish VPN to HQ gateway followed implied rule (number zero), although traffic to establish VPN to branch gateway followed other rule.

There was no access to TCP 443 from Internet to branch gateway therefore I had to add specific Firewall rule.

I suppose there should be implied rule for branch gateway too. 

P.S.

answering your comment: I use pure Internet for my tests (3G smartphone acting like access point for my laptop)

[Maarten_Sjouw]

You need to make sure visitor mode is turned on on both gateways.

[Maxim_Medvedev]

I found what was missing:

https at cluster public ip was occupied with NAT translation to private ip. I change NAT to another ip and connection was almost successful:

I found sk120652

"You cannot receive an office Mode IP address because the security gateway does not have a license f... 

They say that

Restarting Check Point services ("cpstop;cpstart", reboot) on the Active cluster member resolves the issue until a fail-over occurs from the current Active cluster member to the Standby cluster member.

I'm going to restart Checkpoint services on the active cluster member to perform one more check and contact support to get a Hotfix.

[Danny]

This is quite a common demand. In case the branch offices are also connected to the same Check Point gateway via Site-to-Site VPN the easiest way to accomplish this is by defining an alternative remote access encryption domain that include the encryption domains of your branch offices or simply tell the VPN clients to route-all-traffic to your Check Point gateway. This will then re-route the traffic to your branch offices.

[Maxim_Medvedev]

I continue to install Secondary Connect feature and faced with different issues, here is another one:

I've added third gateway Branch#2 to Remote Access community with R77, but it doesn't work (Secondary Connect works with the second gateway Branch#1)

made all settings identical to the secong gateway

- check VPN domains to prevent overlap

- renew certificates on cluster and on both appliances

- add Firewall rule to access to Branch#2 hosts

- chose the right interface for VPN connections (External ip address of the cluster)

I can see following errors in trac.log file of Endpoint Connect

[ 3496 3516][21 Nov 15:01:43][IKE] message: (msg_obj
:format (1.0)
:id (CPSC_INTERNAL_ACCESS_DENIED)
:def_msg ("Access denied - wrong user name or password ")
:arguments ()
)

.........
[ 3496 3516][21 Nov 15:01:43][rais] [DEBUG] [RaisMessages::CreateMessageSet(s)] message: (msg_obj
:format (1.0)
:id (ClipsMessagesGwNegFailed)
:def_msg ("Negotiation with site failed")
:arguments ()
)

..........
[ 3496 3516][21 Nov 15:01:43][FLOW] TrConnEngineConnectStep::operation_failed: user message set: (msg_obj
:format (1.0)
:id (ClipsMessagesGwNegFailed)
:def_msg ("Negotiation with site failed")
:arguments (

The only differences between Branch gateways is:

1. version (branch#1 gateway with R77.30 works, branch#2 gateway with R70 doesn't)

2. management interfaces of branch#1 gateway connected directly (branch#1 gateway interface and management server located in the same /24 network via IPVPN) and management interfaces of branch#2 gateway connected via corporate network (located in different networks and connected via two routers)

Couls you help me with these questions:

Does Secondary Connect work with R77 version?

What mean error "Access denied - wrong user name or password"? What settings may mismatch in that case?

[Maxim_Medvedev]

That's what I really did to enable Secondary Connect, maybe it would be helpful:

   1. Make sure that VPN Domains on different clusters do not overlap. I actually created new groups for VPN Domains and made sure that internal networks or hosts presented only in one VPN Domain group.

   2. Renew certificates on clusters.
I use Solution from Scenario 1 from this sk128652
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

I do nothing with the certitficates on gateways, it seems that when cluster is enabled only cluster certificate is used.

   3. Set correct ip address for VPN Gateway in Cluster Properties --> IPSec VPN --> Link Selection. This step is nesessary in my case because cluster has internal ip as IPv4 Address in Gateway Cluster Properties --> General Properties. I also set internal cluster ip in Cluster Properties --> IPSec VPN --> Link Selection --> Source IP address settings.

   4. Enable Office Mode. Cluster Properties --> VPN Clients --> Office Mode. Office Mode network also should be allocated for every gateway of the cluster.

   5. Enable Visitor mode Cluster Properties --> VPN Clients --> Remote Access. I suppose that there is no need to enable SSL Network Extender as I suggest earlier.

   6. Check that Visitor Mode port (443 in my case) doesn’t occupied by anything else. In my case there was NAT rule for external cluster ip address to some internal host. I’ve changed internal ip address for this NAT rule.
sk30197 is very useful to configuring proxy ARP to change ip address of NAT rule
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

7. Add cluster to Remote Access VPN Community.

8. Save and install policy.

9. This step doesn’t apply to gateway settings, but it is important: make sure the route to Office Mode network from inside branch network exist and that ACL on inside routers/firewalls is correct.

Finally on R77.30 I have got following error when connecting directly to gateway:

sk120652 described this issue. I suppose I should get Hotfix from CP Support.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

For R77 I’ve got another error:

I doesn’t found my case in sk116957, suppose I should Hotfix too.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Nevertheless there is access for branch resources via secondary tunnel, so I managed to achieve main goal. Answering my previous post: yes, secondary connect works with R77.

Thanks to those who participated!