Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Mark_Oakton
Contributor

Branch Fortigate use HQ Fortigate as default gateway

Hi All, Have brain freeze and can' t remember how to do, thought I' d ask the experts, hoping for some quick help! I have a central Fortigate with UTM services, web filtering. etc. And a remote Fortigate using an IPSEC tunnel to connect to HQ, all users in the remote site need to have their default route go over the VPN - so they can have the same web filtering policies as the HQ network from the HQ firewall. I have IPSEC tunnel configured (interface mode) and can access ranges in both sites but now need to push the default route over the VPN. The Fortinet documentation says to edit the static route to 0.0.0.0 and point it over the tunnel interface but if I do that the remote Firewall won' t have is next hop, default gateway listed anywhere - so won' t be able to reach the external peer ID for the VPN as it will not know how to connect. Am sure I have missed the obvious but its been a long day, any advice very appreciated Regards, Mark
Infosec Partners
Infosec Partners
19 REPLIES 19
netmin

Your are right. But using 2 default routes may provide an advantage in the other scenario Ede mentioned (tunnel down) when people at the branch office need to reach some internet resources.
FGTuser
New Contributor III

I think you can' t redirect users via outside when tunnel fails with two default routes: -when you have different AD, higher AD will not be in routing table until lower AD is active -in case the same AD and different priority, lower priority is always used The issue with both options: tunnel interface is always up regardless of tunnel up/down status, so you always have route via tunnel in routing table. I was thinking about using dead gateway detection to get rid of tunnel route when tunnel is down, but it' s not possible with tunnel interface.
netmin

I would expect dpd enabled on the phase1 to remove the route - as in redundant VPNs?
FGTuser
New Contributor III

DPD doesn' t help. In case site-to-site VPN route is still in routing table when VPN is down, I' ve just tested it and it' s logical behavior, otherwise you couldn' t bring up the tunnel with traffic.
netmin

I assume that there' s something missing. Unfortunately I don' t have spare equipment to test it but if the routes were not removed, the redundant VPN example mentioned here: http://docs-legacy.fortinet.com/fgt/handbook/40mr3/fortigate-ipsec-40-mr3.pdf with 4 identical routes (but different distances in this case) would not work as well, I think.
netmin

OK - it' s been a rainy day and I set up 2 trial VMs. Everything works as expected. The local P1 interface stays up but as soon as the tunnel goes down on the remote end, all routes defined on the local P1 get removed from the routing table.
 login as: admin
 FortiGate-VM64 # get router info routing-table all
 
 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
        O - OSPF, IA - OSPF inter area
        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
        E1 - OSPF external type 1, E2 - OSPF external type 2
        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
        * - candidate default
 
 S*      0.0.0.0/0 [10/0] is directly connected, To_FGT1_P1, [3/0]
                   [10/0] via 10.0.0.1, port2, [5/0]
 C       10.0.0.0/24 is directly connected, port2
 S       172.16.1.0/24 [10/0] is directly connected, To_FGT1_P1
 C       172.16.2.0/24 is directly connected, port4
 C       192.168.17.0/24 is directly connected, port1
 
---tunnel goes down remotely---
 FortiGate-VM64 # get router info routing-table all
 Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
        O - OSPF, IA - OSPF inter area
        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
        E1 - OSPF external type 1, E2 - OSPF external type 2
        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
        * - candidate default
 
 S*      0.0.0.0/0 [10/0] via 10.0.0.1, port2, [5/0]
 C       10.0.0.0/24 is directly connected, port2
 C       172.16.2.0/24 is directly connected, port4
 C       192.168.17.0/24 is directly connected, port1
 
losojos
New Contributor

I am dealing with a very similar scenario to the original poster.  It seems, from reading this thread, that there is a solution, but I was not able to grasp exactly what that solution was.  

 

My scenario:

 

FG60D with a low bandwidth Metro-E link to a data center, and a high bandwidth DIA circuit, over which there is a VPN tunnel to the same data center.

 

At the data center is a FG300D

 

The branch office (FG60D) has voice and data traffic, on separate VLAN's and (obviously) subnets.  The desire is to have all internet (from the data subnet) and data traffic route over the VPN tunnel, while the voice (which only needs to reach the data center, no internet) continues to route over the Metro-E link.

 

I am able to get everything working, except for the Internet portion.  The need is similar to the original post.  Routing Internet traffic through the data center keeps us HIPA and PCI compliant due to our proxy and expanded licensing on the FG300D.  

ede_pfau

The tricky part is that you need a default route to WAN to set up the VPN in the first place. If the remote FGT's default route points to the tunnel then traffic for the HQ FGT (via internet) would be directed to the tunnel which will result in "flapping".

 

So, set up one dedicated static route to the HQ IP address, via WAN. Secondly, set up a default route pointing to the tunnel (interface). As the first route is more specific it should be in the Routing table together with the default route. Tunnel "control" traffic (ESP or UDP/500) will not be routed through the tunnel.

 

This will only work if the other FGT has got a static public IP address.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
antonin75
New Contributor

Hi I had the same problem.

I solved it by this way:

1. on bouth sides in VPN - IPsec Tunnels i have to add in Phase 2 Selectors new address maping 

- on HQ: Local Address: 0.0.0.0/0.0.0.0 , Remote Address: address range of branch office

- on Branche Local Address:  address range of branch office , Remote Address: 0.0.0.0/0.0.0.0

2. on HQ add new IPv4 Policy  as incoming interface select IPsec tunnel, outgoing interface select your Wan port, source adress pool for branch office, destination all and turn on NAT and all security profiles and logging options.

3. on branch FortiGate in Network, static routes

- add static route for wan ip adress of HQ FortiGate(VPN) trough your Wan IP

- add static route to 0.0.0.0/0 trough your VPN tunnel with priority 0(default)

- in first static route to 0.0.0.0/0 in Advanced Options change priority to 1 or higher number

 

So when I tried tracert to internet address on branch PC i saw that trafic flow trough HQ addresses

Tony

It take almost a day to solve it :)

No one will tell you this easy steps.

ede_pfau

No one will tell you this easy steps.

That is exactly what I wrote in December 2015...hope OP has picked it up in the meantime

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors