Routing across 3 (or more) subnets through a VPN tunnel?

[GCJBL]

All our offices are fortigates on 6.x firmware connected via IPSEC tunnels. Each office has its own unique LAN subnet, but also has a unique DHCP-based subnet strictly for wifi clients. NAT-based policy in each direction routes wifi clients back to the LAN in each office. All routing between offices is however using static routes with non-NAT policy in each direction over the IPSEC tunnels.

My dilemma: We are rolling out laptops to remote offices which have always previously been desktop endpoints strictly on LAN, so VPN tunnel routing always worked fine for LAN to LAN between two offices. Now that we are introducing laptops into the mix which will be on their own wifi subnet when undocked, I am having a hard time figuring out how to route through those 2 subnets back to a LAN subnet in another office. Since these other users have mapped drives on the LAN in our home office (remote to them), I am simply trying to figure out how to configure routing so that a laptop on the unique wifi subnet in our Northern office can get through to the LAN in our main office - which I assume is a route from localwifiSubnet -> localLANSubnet -> Remote Subnet.

I've read so much confusing information on this that I need help wrapping my head around how to do it properly in FortiOS. I have no problem making those wifi subnet policies static routes instead of NAT-based if that's a step in the right direction to facilitate a solution. Thanks profusely for assistance on this challenge. Hopefully I explained it well enough.

[Toshi_Esumi]

Probably you read too many variations of articles, but you just need to pick up the common things.

- add Phase2 selectors to allow the 2nd (wifi) subnet to go over the vpn to get to the other side's subnet, if you're not using 0/0<->0/0 default selector.

- set proper routes (static or via routing protocol) on both sides to route to the tunnel interface.

- if policy set is limiting source/destination subnets, you need to add the new subnet to them.

That's all and it should take care of it.

[ede_pfau]

To make things easy:

- in VPN phase2, only use '0.0.0.0/0' as wildcard QM selectors. FortiOS explicitly allows this.

- in every location, create an address group containing your subnets in use, not only in local use but of HQ as well.

Use these in the policies allowing traffic to and from the VPN.

- put up static routes in every location, pointing the HQ subnet to the tunnel interface. You do not need to specify a gateway address (another speciality of FortiOS).

All in all these are only incremental changes to your existing config.

[GCJBL]

Ede and Esumi, thanks! Will try to digest this and come back with any questions. Much appreciated.

[GCJBL]

OK, additional question time.

Is this all assuming that I take NAT off the wifi<->LAN policies in each office and make them also static?

Instead of an address group, couldn't I just add the applicable subnet addresses to each tunnel policy (add wifi subnets to policy in addition to LAN subnet)? Trying to make sure I understand how to get the 'outer' subnets talking in both directions.

[ede_pfau]

Right, if you keep NAT on you'll only deal with the LAN addresses. (I call that 'poor man's routing').

Of course you can add explicit addresses to each policy. An address group shifts focus from the policy to the address tab - by adding to the group changes take effect without you ever touching the policy / policies again. It's a layer of abstraction, in a way.

You can first add the extra address object and change that later to a group if you wish.

[GCJBL]

Eureka!

Pretty sure I have this working now, but not exactly as one would think. Making both the IPSEC phase 2 selectors 0.0.0.0/0 was apparently a key tenet for policy subnets to traverse the tunnel, so thanks for that!

Ended up making an additional static route on the home office router through the tunnel interface back to the northern office wifi subnet as all other necessary static routes were in place. Also removed NAT from Northern office WiFi<->LAN policies.

From there, created two-way non-NAT policies from LAN interface/subnet in home office to the Northern office WiFi SSID interface/subnet over the tunnel. Then added the Northern office wifi subnet entry to existing two-way LAN-LAN tunnel policies in the home office. 

In essence, this problem ended up being almost purely a policy implementation from interface to interface with some static routing as necessary for WiFi subnet to be routed across the tunnel interface. Hopefully I explained this in a manner helpful to someone in the future, so apologies if not detailed enough....this one just about broke my brain :)

[ede_pfau]

Great! You'll always the first real obstacle you've cleared. Glad it works.

Maybe I've got this wrong but do you really use Policy Routing? Or just plain routing, and policies allowing the traffic?

Regarding the two-way policies: each policy rules if a session can be started from source to destination (interfaces and addresses). Once the session is allowed and established, traffic will flow in both directions across that policy.

So, if you need to have a branch-to-home policy then there is a server at the branch office which needs to open a session to your home client. If not, you wouldn't need this policy (and I would delete it).

You can easily check a flow by looking at the 'bytes' counter in the policy. You might need to add this column first.

[GCJBL]

Yes, sorry. I am not using policy routing but was actually referring to policy taking care of traffic flow. Thanks again for the suggestions!