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!

[Lesley]

This is for tunnel_test. You can also disable this and exclude firewall IP from encryption domain.

https://support.checkpoint.com/results/sk/sk180716

[hugothebas]

Thank you, but that doesn't solve my issue. I have already tried doing it, the result is the same.

[Lesley]

ah VPN clients. I see now normal enc domain can you double check remote access enc domain?

[hugothebas]

Sorry about that, I should have sente the vpn domain of remote access community before.

There it is:

Thanks.

[Lesley]

Check, are the VPN clients up to date? What version?

Second tip: 

Maybe work something out with crypt.def (exclude firewall ip from tunnel)

https://community.checkpoint.com/t5/General-Topics/VPN-traffic-exclusion-with-crypt-def/m-p/167592

[hugothebas]

Client is the latest version "Endpoint Security E88.70".

Exclude gateway from tunnel with crypt.def file would make it send the routes (encryption domain) to the client? I can try, but I don't think so.

Thanks

[CaseyB]

I see you are using a granular encryption domain. What version are you running?

It could be this: sk170857 

[hugothebas]

Hello, @CaseyB.

I'm on R82 Take 12, but this has been happening since R81.10, I was avoiding dealing with it, but I can't postpone anymore, need to solve it.

Thanks.

[PhoneBoy]

Is this causing an actual issue above and beyond the cosmetics of those routes existing in the routing table?
Pretty sure this is expected behavior as we want to make sure any access to the gateway IP addresses does NOT go through the VPN and those routes are explicitly for that purpose.

[hugothebas]

Hello @PhoneBoy!

The main issue is that it is impossible to connect to the gateway vis SSH, HTTPS, etc.

As of now, to reach the gateway, I need to access another host (the SMS, for example) and then jump to the gateway.

About your comment: "Pretty sure this is expected behavior as we want to make sure any access to the gateway IP addresses does NOT go through the VPN and those routes are explicitly for that purpose." - This behavior is only on this gateway, I connect to other customers from VPN client and have no problem accessing the gateway's internal interfaces through VPN.

Thank you!

[the_rock]

Make sure that subnet is not inadvertantly natted.

Andy

[hugothebas]

Hello, @the_rock!

I have certified there is no nat involved in this communication.

Thanks.

[the_rock]

Okay. Just to verify, is this the ONLY subnet with the issue once connected? If so, please check to see if topology on that interface is 100% right.

Andy

[hugothebas]

No, the gateway has 4 interfaces on different subnets, the behavior is the same for all of them.

Thanks!

[PhoneBoy]

Well, yes, that is an issue as this should be possible.
Wondering if there's a setting in one of the trac configuration files that might be impacting this?

[hugothebas]

Well, I'm m gonna check trac config file, but I don't see how it could cause this issue.

I'll let you know.

[JozkoMrkvicka]

I handled the same issue in the past. Dont remember what kind of setting was changed, but something says me it might be related to supernetting within GuiDBedit setting. Will check it further and let you know.

[the_rock]

These are the ones I know of in guidbedit that should be set to false.

Andy

ike_enable_supernet

ike_p2_enable_supernet_from_R80.20

ike_use_largest_possible_subnets

[hugothebas]

I'm gonna try it tomorrow and post here the result.

Thanks!

[the_rock]

Hope it helps.

[the_rock]

Hey mate,

Any luck with this?

Andy

[hugothebas]

Hello!

Sorry for taking so much time to test, I had too much work to do the last days.

I have tried those GuiDBEdit parameters

ike_enable_supernet - (under global properties) was already "false", I did not change.

ike_p2_enable_supernet_from_R80.20 - (under Remote Access Community) was set to "by_global", I've changed to "false"

ike_use_largest_possible_subnets - (under global properties) was set to "true", I've changed to "false"

I also checked crypt.def and it is default with no changes.

Checked trac_client file and the only change there, is to set topology as first to respond (with 2 participant gateways).

Unfortunately, the issue wasn't solved.

Thanks anyway.

[the_rock]

Did you ever end up opening TAC case?

[hugothebas]

Not yet, TAC cases usually takes a long time and need several remote sessions. I was trying to avoid it.

But I think I don't have other choices.

Thank you all for trying to help.

[the_rock]

I would call and insist on doing remote if possible.

Andy

[the_rock]

@hugothebas  Or if you can wait till Sunday afternoon EST, happy to do remote and see if we can fix it.

Andy

[hugothebas]

Well, I have opened a TAC case, if we can't reach a solution (or if we do) I'll update this post.

Thank you!

[the_rock]

Sounds good!

[hugothebas]

I needed to uninstall the vpn client and needed to connect using Capsule, I just realize that the issue doesn't happen with Capsule VPN, but only with Endpoint Security.