Routing from RemoteAccess VPN to subnet behind another router

[dphonovation]

I have 2 clusters managed by the same MGMT server. I have RemoteAccess profile for both clusters as a result.

The 2 clusters have a route in between them to get to their respective MGMT networks.

       10.20.171.0/24 (2 MGMT Network/24 in pic) via 172.30.0.4, eth4, cost 0, age 4887

I'm Remoting in through Site1/CP1 and I want to get to the opposing data centre.

Topology is:

RAVPN <--> Internet <--> WAN [CP1] 172.30.0.1/28 <---------------->172.30.0.4/28 [CP2] 10.20.171.0/24

I started out with just the first two rules (8 & 9) which are working fine, however I must switch VPN profiles to the cluster on the same network as the MGMT Net I want access to. So now I now wanted to add 10.20.171.0/24 (red box) for RemoteAccess (route to either MGMT net no matter which VPN Site Profile I connect to). I got drops with no Identity information:

I then added rule 10. It worked. I reverted the change just to see it break again. Then reenabled, but this time policy failed with "Only Users Groups and Access roles are supported as source in VPN and Client Authentication Rules". I disabled rule 10 and pushed again. I can't route to 10.20.171.0/24 from RemoteAccess. I reenabled rule 10 and this time it let me push policy with no problem, and traffic is working!

Curiously, when its working with rule 10 and it accepts the policy, the log does show identity details as well:

So what I don't get it:

1) Why didn't the rule based on Users/Groups (Rule 8) work? (when I added 10.20.171.0/24 to it, which is 1 hop away versus the other items in rule 8 that do work)

2) Why the strange behavior in first disallowing me to push a policy with something other than Users/Roles in Source column for a "RemoteAccess VPN"; and then letting me?

[PhoneBoy]

What version/JHF is the management?
Both your questions sounds like the result of bugs and recommend getting the TAC involved.

[dphonovation]

81.10 Take 66

1) My community was set to "all domains defined in topology", and since 10.20.171.0/24 is an on-net route..... I created a group defining both Site1 and Site2s MGMT Networks and configured the RA community to use that. Users/Groups working as expected now.

2) Still have no idea. Case open.

[PhoneBoy]

Glad you sorted the first issue.
The second issue sounds like a bug in the policy validation process.

[dphonovation]

I got the impression Secondary Connect was still supposed to handle this situation for me, as per these docs:
https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_RemoteAccessVPN_AdminGuide/Topics-...

And just like they say, my profile has a drop down for both clusters and at times I had the VPN client prompting me to reauth.

The logs lead me to believe that Secondary Connect was happening, however the NAT Pool used for office mode was still from CP1 and therefore CP2 failed to match it to a policy. I can't make both Office Mode pools the same or SmartConsole complains.

[PhoneBoy]

Right, the Office Mode pool needs to be different on different gateways/clusters to ensure the traffic is routed back to the right set of gateways.