R80.30 - Remote Access VPN via 2nd ISP

[ClaudiaPeter]

Hi,

our customer wants to use a 2nd ISP exclusivly for Remote Access VPNs. At the moment we fail for the correct routing table and get a asymmetric routing: the pakets from the client arrives on the interface of the second ISP but the answer is routed via the interface of the primary ISP (with the source IP of the second ISP).

In the system table the default gateway of the second ISP has a higher priority and is for that unused, PBR is not used for pakets from the gateway itself.

We even tried "Configuring Link Selection for Remote Access Only" accoring the CP_R80.20_RemoteAccessVPN_AdminGuide.pdf, but there is still the problem of the outbound routing.

How can we achieve the correct routing via the gateway of the second ISP only for Remote Access VPNs?

Best regards

Claudia

[Maarten_Sjouw]

In the link selection there is a button for source IP setting, this should be set to: Automatic derived from method of IP selection b y remote peer.
When you have no other VPN's you could change this to the interface you want the clients to use.

[ClaudiaPeter]

There are several S2S-VPNs in use without link selection. I tried to enable link selection for S2S VPNs in a test setup without any change for the routing problem of the Remote Access VPNs (it was just a try in the absence of any reasonable idea...).

The option "Automatic derived from method of IP selection by remote peer" is for the source IP address when initiating a tunnel. But for my problem the source IP address is correct, it is a routing problem.

Regards

Claudia

[Maarten_Sjouw]

This was the option I was looking for:

 

[ClaudiaPeter]

Sorry that I didn't mentioned: I already tried this option without effect for the Remote Access VPN (and retested it right now). And I'm not sure if this option should have an effect for Remote Access VPNs or only for S2S VPNs.

I think the actual problem is that there is no active default route for the secondary interface in the system routing table.

route config:
set static-route default nexthop gateway address 2.0.1.254 priority 1 on
set static-route default nexthop gateway address 2.0.2.254 priority 3 on

system routing table:
ip r
    default via 2.0.1.254 dev eth0 proto routed

Regards,

Claudia

[Maarten_Sjouw]

I think you should open a case with TAC, as this should indeed work.
The problem with the routing is that you don't know the IP's of the RAS clients.

[ClaudiaPeter]

Hi,

in the meantime there is another post for this subject to accomplish this with alerts and scripts:

https://community.checkpoint.com/t5/Remote-Access-Solutions/How-to-configure-VPN-Remote-Access-on-no...

I didn't try it, I just want to give a hint if someone find this thread and not the other one.

If the solution provided by a Check Point employee is so complicated, there is no standard configuration to accomplish this.

Regards, Claudia

[FedericoMeiners]

Claudia,

Have you tried the the same setup but with ISP Redundancy in Active/Active mode?

I remember that I had some issues a while back publishing services and PBR couldn't be used, Active Active for ISP was the way to one to correct default route.

If it works, you may want to check if ISP Redundancy in A/A still affect SecureXL prior advising to the customer.

Regards,

Fede

[ClaudiaPeter]

Hello Fede,

I've never tried a active/active ISP redundancy, and I don't think it will do the job. The customer wants to handle only the Remote Access VPNs via the extra line without any side effects for all the other connections. With active/active ISP redundancy we would have Load Sharing with many impacts for the other incoming and outgoing connections.

Best regards

Claudia