routing to Public Internet over IPSEC

[Spiderghom]

Hi Guys,

I am testing a setup with 2 x 80F in two branches ( A and B) connected back to Hub (C) via an Ipsec tunnel.

The local LANs behind the branches can ping the hub local lan through the tunnel . Also I configured a second phase2 selectors to allow another local lan ( /29 each) in the branches to get to the internet through the hub. I have added default route via the ipsec interface in each branch and and a firewall policy allowing the second local lan (/29)  and in the hub the required firewall policy.

For branch B which has the second /29 , the ping towards internet via the hub is working but not in the branch A.

I can see under routing monitor that a static router /29 - branch B is showing but not for /29 - branch A.

I am wondering if I am missing anything. I went to compare the config of A and B and couldnt  find  any difference/issue  except the IP scheme is different.

[Toshi_Esumi]

If the HUB's public IP is static, you can set a static route to the /32 toward wan, then remove the static default route to wan. That's the common way to route internet traffic through the HUB.
I thought you had 2 x 80F at each A and B locations (totally 4 x 80F) based on the original description. That's why I asked the topology/diagram. Since that was not the case, the topology was simple. But the problem was just a routing on the 80F at A location.

Toshi

[pminarik]

Is the Hub-and-spoke setup dynamic (one phase1-interface configured in hub for all spokes), or static (one phase1 per spoke)?

If dynamic, this raises the question of how you're doing routing on the hub. How does it learn about each spoke's subnets? Dynamic routing (BGP, OSPF, RIP), or does it learn the routes from phase2-selectors ("set add-route enable" in phase1 or phase2)?

[Spiderghom]

Hi,

yes. it's dynamic setup; single phase1-interface for all branches.

the hub gets the routes from phase2-selectors . I confirmed that by bringing up and down the phase2 selectors and the route gets added and removed.

[Toshi_Esumi]

I hate the dialup VPN after they made the change for routing after 6.0/6.2.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-set-net-device-new-route-based-IPsec-logic...
I think now it works if you have "set add-route enable" after 7.0.
https://docs.fortinet.com/document/fortigate/7.0.0/administration-guide/534155/dynamic-ipsec-route-c...
But not sure if it still creates "...tunnel_0", "...tunnel_1" virtual interface for routing. That's why I asked "get router info routing-table all" to see the interface names.
Why don't you just set up two completely separate/independent/different-phase1-name site-to-site IPsec VPNs? So that routing on the hub side is quite simple. If injected (add-route) based on phase2-selectors they would be pointed to those two interfaces.

Toshi

[Spiderghom]

HUB(C)- Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via x.x.148.x, port17, [1/0]
C 10.112.200.10/32 is directly connected, dc-loopback0
C x.x.148.x/30 is directly connected, port20
S 172.x.x.16/29 [15/0] via to-hub tunnel x.x.128.x, [1/0]
S 172.x.x.24/29 [15/0] via to-hub tunnel x.x.166.x, [1/0]
S 192.x.x.8/29 [50/0] is a summary, Null, [1/0]
S 192.x.x.16/29 [50/0] is a summary, Null, [1/0]
Branch(A)-Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via x.x.128.x, wan1, [1/0]
[10/0] via to-hub tunnel x.x.148.x, [1/0]
C x.x.128.x/29 is directly connected, wan1
S 192.x.x.0/26 [10/0] via to-hub tunnel x.x.148.x, [1/0]

Branch(B)-Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via to-hub tunnel x.x.148.x, [1/0]
[10/0] via x.x.166.x, wan1, [1/0]
C x.x.166.x/30 is directly connected, wan1
S 192.x.x.0/26 [10/0] via to-hub tunnel x.x.148.x, [1/0]

[Toshi_Esumi]

The routes at the HUB are fine.
S 172.x.x.16/29 [15/0] via to-hub tunnel x.x.128.x, [1/0]
S 172.x.x.24/29 [15/0] via to-hub tunnel x.x.166.x, [1/0]

Toshi