Own gateway interfaces' address excluded from Remote Access VPN

[hugothebas]

Hello, I need to understand why the gateway is excluding all of it's interfaces from the remote access vpn.

For example:

the above interface is one of them, but the issue happens with all interfaces.

The remote acces encryption domain includes that subnet:

After connecting to VPN client, on the endpoint side I see that the /24 subnet is divided into smaller subnets and the gateway's interface IP is excluded from the routes:

I've already checked if is there any overlap os other VPNs and there is none

Does anyone know what could be causing this issue?

Thanks!

[the_rock]

But it should work fine with endpoint security as well.

[hugothebas]

Yes, for sure, just mentioned it because that is something even more weird. Well, let's see what TAC says.

[Duane_Toler]

How do you have your Office Mode address assignment configured?  DHCP? Manually from a network object? ipassignment.conf? RADIUS?

[JozkoMrkvicka]

could be, but I was not able to find more info about similar case in my old notes 😕

[ilkerd · Accepted solution]

Hi,

Use this SK: https://support.checkpoint.com/results/sk/sk92676, and you'll thank me later. 🙂

Unfortunately, there’s no other solution. R&D doesn’t care about this issue.

[Duane_Toler]

This isn't related to the issue being discussed.  As for not caring about your particular issue, that SK article contradicts you; clearly they do care or else the article wouldn't exist.

Not every button, knob, switch, dial, and doodad can be included in the frontend management console, or else it'd be littered with too many confusing options for the 90-95th percentile of use cases (ever see an Outlook 2002/2003 settings panel? that's not the shining star of UI design...). R&D provides numerous underlying config options for an enormous degree of tweaking and tuning; not everyone should use all of these, however, and they don't apply universally.

R&D does care, but decisions have to be made and not everything makes the cut.  If you care strongly about a particular item, you can vote (via TAC cases, contacting your local support office, and submitting RFEs).

[ilkerd]

Please don’t comment without trying it!

This setting related to MEP causes the routing table of remote access connected clients to exclude gateway IP addresses.

Even if the network containing the gateway IP address is, for example, /24, it gets fragmented and excluded as /25, /27, etc., using VLSM.

Yes, this issue exists for many of our customers, and R&D isn’t releasing a fix for it. It’s very frustrating that every change requires manual editing of files. You can only apply this fix by connecting to the user’s computer and manually editing the files.

[JozkoMrkvicka]

I am using MEP on many RAs and none of them exclude FWs IPs from encryption domain.

It has to be some setting/config on that one affected firewall which prevents to include FW's IPs into encryption domain.

Isnt firewall itself somehow included in encryption domain ?

[ilkerd]

Hello,

This is an issue that occurs in some cases, but we have encountered it frequently lately. RD couldn’t provide us with a different solution to this issue. It’s a problem we’ve been facing for a long time. I hope it helps someone resolve the issue.

Since the change is applied on the client PC, it can be easily tested.

[PhoneBoy]

One of the things I know R&D is trying to address longer-term is to eliminate the need to go to expert mode at all.
That would require making changes like this "configurable" somehow via clish/WebUI.
That would make these changes something that would survive upgrades and such.

[hugothebas]

Hello, first of all, I'd like to thank everyone who tried to help, I really appreciate!

I'm marking this answer as a solution, although it was not exactly it that solved my issue, it gave me a clue about what was happening and it was also the SK that TAC told me to check.

In fact I had 2 gateways on remote access community, I did not change trac.defaults file on client side, because in a company that has hundreds of users (not my case) it would not be that easy. In my case I opted for just remove the second gateway from the community (as we were not using it to connect to C2S VPN) and the issue was gone.

But I still doesn't understand why the other gateway was preventing the routes to correctly being downloaded, the other gateway encryption domain was empty, so, what is the explanation for the second gateway, make the routes to the first one be excluded? I really don't get it and I guess I'll never do.

Anyway, what I needed to do was done, If I have another issue like this in the future in a case that I really need to have MEP enabled, I'll have to deal with it again.

Thank you all!

[JozkoMrkvicka]

I managed to find similar case from 2020. At that time this issue was caused by old "Connection Profile" used in pre-R80 versions (R77.30 for example). Once not needed Connection Profile was removed using GuiDBEdit (Desktop -> desktop_profiles), issue was gone. More info in sk91120.

I am pretty sure the gateway you have removed will be part of that legacy Connection Profile. You will not be able to delete the gateway which is present as part of Connection Profile. You will need to delete the gateway from the profile first, or delete complete profile since this is not used anymore.