Endpoint VPN: How does client get routing topology fom the VPN GW ?

[TomShanti]

I know that the client calculates topology on connect and stores it in local trac.config file but where is this topology information stored on the gateway ?

Thanks Tom

[PhoneBoy]

It's part of the configuration of the gateway object.
This is compiled along with the policy and pushed to the gateway.
I presume it's somewhere in $FWDIR/state/local/FW1.

[Maarten_Sjouw]

it is configured on the gateway object in the Remote access VPN Topology, this can be different from the standard VPN topology for that gateway.

[TomShanti]

Ok thanks -I am having troubles with a VPN cluster not pushing down the correct VPN routes to a Remote Access client.

This FW cluster is in the same VPN community as other FWs which work perfectly.

Looking at the unobscured trac.config file at the client I get only the VIP and physical IP addresses in the <IP_RANGE> section whereas I get all correct networks when I connect to another FW cluster in my network.

The last change on the affected FW cluster was adding two unnumbered VTI interface to get redundancy for a cloud proxy used by the local network.

Thanks Tom

[Maarten_Sjouw]

That last change will explain why it is not working as expected, most of these VTI configurations (with dynamic routing) tell you to add a empty encryption domain.
So as I said before make sure to define the Remote Access VPN topology separately.

[Wolfgang]

As Maarten mentioned, you have to specify another VPN domain for the Remote Access Community.

Look here:

Wolfgang

[TomShanti]

My VTI routing is based on static routes added to both cluster members via GAiA.

Regarding the steps to solve the problem I am not sure if I fully understood your inputs.

1) currently I have set a domain for Remote Access Community in SDB like "Remote Access" -> "Enc-Dom-Mobile" for the FW cluster object

2) "Enc-Dom-Mobile" contains all relevant networks where encryption should happen (I assume the GW builds the routing topology from this information)

3) "Route all traffic through tunnel" is enabled

4) there are already some exclusions configured for "Enc-Dom-Mobile"

The peers I used for routing through the VTIs are already part of another encryption domain "VPN_cloud". This "VPN_cloud" has the FW cluster as Center Gateway and two satellite gateways which are actually two cloud datacenters. The GAiA VTI configuration includes each of these satellites as peers. The actual static route tells the FW cluster to route the cloud vip through one of the VTIs (so two routes with different metrics exist).

Should I now exclude something from "Enc-Dom-Mobile" ?

It feels like FW cluster publishes encryption topology from the "VPN_cloud" to the client rather than the "Remote Access" VPN community.

Thanks again for your help.

Regards Tom

[Maarten_Sjouw]

Ahhh, this is your problem:
3) "Route all traffic through tunnel" is enabled
You will not need any separate routes, there is only a semi default route needed in this scenario, route all traffic into the tunnel...

[TomShanti]

Sorry for being so dumb - but what do I need to change ?

On the FW cluster GW object I have enabled "Allow VPN clients to route traffic through this gateway"

Thanks Tom

[Maarten_Sjouw]

What is it you are trying to achieve?

[TomShanti]

I want to get FW cluster to publish the correct topology from the Remote Access community.

Currently it only publishes the external interface IPs to trac.config.

Regards Tom

[Maarten_Sjouw]

Than you should disable the Hub mode setting (Allow VPN clients to route....) as that one forces together with the setting in the Global properties 'Remote Access -> Endpoint Copnnect -> Route All traffic through gateway' that all traffic will be sent to the gateway.

[TomShanti]

But this is not possible regarding our security concept. If I understood correctly and disable the feature the client would be able to directly connect to local resources. There should be a way to get the FW cluster to publish the correct topology, shouldn´t it ?

We partly solved it with support by disabling secondary connect but now we cannot manually choose our primary VPN GW in the VPN client anymore.

Regards Tom 

[PhoneBoy]

It's not real clear exactly the problem you're trying to solve here (i.e. why are you debugging the topology the client gets).
This SK might be helpful, though:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[TomShanti]

Thanks - I´ll try to re-explain

                                                                    |---->  one tunnel to cloud proxy provider (different VPN community "Cloud1")

                                         ---------> FW-Cluster 1 ----|

Remote access clients ---------> FW-Cluster 2 --------- Same remote access community

                                          --------> FW-Cluster 3 ----|

Scenario:

Remote access clients can connect to different VPN gateways (FW-Cluster 1, FW-Cluster 2, FW-Cluster 3).

All VPN gateways are connected to the same Remote Access community.

MEP and Secondary connect are enabled in trac_client_1.ttm

So the user can choose in the VPN client from a dropdown box to which GW to connect (this is mandatory).

With this setup everything was working fine - client could reach all resources to internal network.

Now I changed the following for FW-Cluster 1:

- added a secondary satellite to VPN community "Cloud1"

- to make a redundant VPN tunnel I added 2 VTIs and routes with different metrics with the two satellites as destination gateways

After this change the clients connecting to FW-Cluster1 where not able to reach internal resources anymore.

The VPN tunnel to FW-Cluster1 from a client is established successfully but it looks like the Cluster is publishing a wrong topology which does not include the internal networks anymore. Only the external interfaces of the cluster.

Regards Tom

[PhoneBoy]

Do you want remote access users to access resources via Cloud1 also or just your local networks?
In any case, I highly recommend getting the TAC involved.

[TomShanti]

Yes they need to access the internet via Cloud1 as this is is a "internet proxy service" which they need because they have no split tunnel to directly access the internet from their client.

TAC is already involved since a week via our partner.

But up to now no solution. So I probably have to roll back the config today because of the side effects.

Regards Thomas