VPN access issue via a dual ISP connected FW

[ipbloke]

Hi All,

Hoping someone can point me in the right direction as I cannot seem to get the following setup working:

Equipment: 60D

Software: 5.6.0

Internet: Dual WAN Connectivity to 2 x different ISP's

Network Setup

The FW itself currently has two Trusted networks connected locally:

[ul]

192.168.1.0/24 ---Home Network  (Net A)

10.0.0.0/24 --- Security Lab containing a few servers  (Net B)[/ul]

I also have a small network range defined for Remote Access Users (10.10.254.0/28) who I would like to remotely access the Security Lab (Net B) via an IPSEC VPN.

[ul]

ISP A is connected to WAN1 --- Used as the main internet connection for (Net A)

ISP B is connected to  WAN2 -- Used as the back up connection for (Net A).[/ul]

Both ISP's provide a default route though I have modified the Interface Admin Distance as follows:

[ul]

ISP A (Distance 1)

ISP B (Distance 5)[/ul]

I 'do not' want to run these links in a load balancing setup.

Problem Statement

I would like the remote access users to VPN in to the FW via the secondary ISP connection (ISP B) so they can access the security lab (Net B) over an ISP link which is not really utilized.

I have set a specific Policy Route for the security lab (Net B) to utilize and use the secondary ISP connection as follows:

Protocol: Any

Source Addr: Net B

Destination Addr: Any

Action: Forward Traffic

Outgoing Interface: WAN2 (ISP B)

Gateway Addr: (Next Hop)

I can see in the routing table (via the routing monitor)  that a default route is installed for 'ISP A' on the basis I previously configured a better distance so Net A would use this path.

All outbound traffic from Net A does appear to correctly ollow the default route via ISP A.

All outbound traffic from Net B appears to use the policy route via ISP B (However this route is not shown in the routing monitor)

The issue I have is that no users can currently establish an IPSEC VPN via ISP B to the FW. 

Running  'diagnose debug application ike -1' appears to show that new IKE sessions arrive via ISP B though all sessions try to return via ISP A.

My understanding here is that this is probably the correct behavior as the FW only has a single default route installed back via ISP A.

I have previously set both admin distances to the same value and can see both default routes in the routing table, however this caused devices within Net A to use both ISP A & ISP B.

I tried to add a separate static route back to the Remote Access User Range directly via NET B though this made no difference.

Forum Question

Is there a way to force all VPN users trying to connect via ISP B to return via the same interface instead of routing via ISP A (which prevents any IPSEC session establishment) ?

Apologies if this is long winded though wanted to provide as much info as possible as I am probably overlooking something here.

Any help or pointers greatly appreciated !

Cheers

Matt

[Toshi_Esumi]

Try the same cost (leave it default) on both and set a lower priority (higher number like 10) on the B side only, which should provide your desirable behaviour.

[Toshi_Esumi · Accepted solution]

I meant to set static default routes toward both with different priority. I don't think you can change priority on DHCP/PPPoE injected routes.

[ipbloke]

Hi Toshi,

Thanks for your reply. So your spot on that both ISP's are 'injecting' default Gateways and they don't have an option to set a higher priority.

Having said that, your suggestion does seem to work as I subsequently created a single static route pointing towards 'ISP B' and kept the distance the same as 'ISP A' (4) though set a priority of (1) on this route.

The resulting output in the routing table shows the following:

xxxxxxxx (Internet) # get router info routing-table static 

S*      0.0.0.0/0 [4/0] via x.x.254.1, wan1

                        [4/0] via x.x.254.254, wan2, [1/0]

If I hover over the priority setting within the 'Static Route' config section then it does state that the priority of routes dynamically learned from routing protocols will always be '0'.  

In the above output, the static route for 'wan1' was dynamically added to the routing table by virtue of the received gateway obtained dynamically via ISP A, so I guess this actually does have a priority of '0' though it is not displayed in the above output.

A quick check in the kernel routing table however does however show this:

tab=254 vf=1 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=x.x.254.1 dev=7(wan1)

tab=254 vf=1 scope=0 type=1 proto=11 prio=1 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=x.x.254.254 dev=6(wan2)

So really happy this is working  and a huge thanks to you !

For future reference for others , i found a really useful document here which explains how Fortinet handles routing with regards to Distance, Priority and Policy Based  Routes:

http://kb.fortinet.com/kb/viewContent.do?externalId=FD32103

The key statement for me here was: 

Note : the "priority" parameter is used in situation where a static route needs to be present in order to accept incoming traffic and pass the RPF check (anti-spoofing).

Thanks again Toshi. I now have remote VPN users connecting via the secondary ISP to access dedicated equipment, whilst outbound users continue to use the primary ISP.

Matt

[Toshi_Esumi]

Glad it worked for you.