VPN and VLAN question

[3xit]

Hi all,

While I'm waiting on my first FortiGate's, I would like to prepare some things. We will have 11 BO which will connect to the HQ. At HQ we will have two 200F in HA, all BO will have 80F.

HQ will have one Win 2019 Server (DHCP, DNS, etc).

HQ will have FortiManager

I would like to make VLAN's and Subnets as next:

VLAN 2 - Workstations (each site with their subnet ex. 10.10.10.0/24; 10.10.11.0/24, 10.10.13.0/24, etc over the same VLAN)

VLAN 3 - Servers

VLAN 4 - Management (switches, FG)

VLAN 5 - WiFi - Emplyee

VLAN 6 - WiFi - Guests

VLAN 7 - Other (UPS)

VLAN 8 - Trunk

HQ - 100 Mbps Internet

BO - most of them 50 Mbps and some 80 Mbps

Obviously need to split the tunnel 

My questions:

- What kind of VPN connection would you recommend? Routing?

- Would it be better if I split VLAN so for each subnet different VLAN (each BO with their VLAN)? I'm not sure if this would make more trouble for the administration. VLANs 2, 3, 4, 7 and 8 need to talk to each other. VLAN 5 and VLAN 6 need to be isolated from others.

Thank you all for your help!

[ede_pfau · Accepted solution]

hi,

some more general thoughts on how to design a new network.

To be secure, a network needs to be simple, robust and transparent. Simple so that one can grasp how the parts of the network work together easily. Robust means that small changes have equally small consequences. And transparent, all essential information is at your disposal at all times for you to manage the network.

At least that's what it's boils down to in my experience, dealing with networks for like 3 decades now.

In your case, I would try to use one template for the BOs and one for the HQ. That is, the same functionality would use the same VLAN ID (like VoIP is VLAN 101)*. If you're lucky the similarities are such that you can put the FMG to use and roll out one branch in no time, and then adjust the details (ISP etc.).

*hint: of course, do NOT reuse address ranges in different locations, even if you now do not intend to connect them. Always use unique ranges. RFC1918 provides so many choices that this should not be difficult.

IMHO BO to HQ needs IPsec site-to-site VPNs, no question. Corner cases like obtaining private addresses on the WAN side can still be included. In FortiOS, a no-brainer.

I'm not so much a fan of "fully meshed VPN" if more than 3-4 sites are involved. Simplicity is down, robustness might improve by having more redundancy, YMMV.

Much more important is routing in such a super-net (a network of sites all having networks). I'd always recommend using a dynamic routing protocol for 11 sites plus HQ, just because setup is easy and will pay off in the future with every network you need to connect to. Connecting networks itself is highly dynamic, you cannot foresee all connections you will need. So, OSPF is a good choice, quick and it relieves you a lot in case a node fails.

One hint for routing: assign a private IP address to each tunnel end (of course, stick with a scheme, like 'the smaller on HQ side, plus 1 on BO side'). You could as well create loopback addresses on each FGT but it's more work. Plan addresses such that you always have a super-net notation ready (e.g. 172.20.n.0/30 for BO <n>, 172.20.0.0/16 is the supernet).

When creating address objects, always make them routable. Can't be done in GUI afterwards, and it will come in handy later. Like, in static routes or in VPN phase 2 QM selectors. It's a pity that you cannot peek into a route which is based on a named object but it makes the routing table less error prone.

Hope this helps, all of this from my experience and not from books, highly subjective of course.

[sw2090]

Well maybe I can give you a clue:

we have 20 Shop-Sites with 50mbit Internet connection on two lines.

Each shop-site has 2 IPSec S2S Tunnels to HQ.

Each ship-site and also HQ use the same Vlan-IDs for their vlan.

Since the vlan is local on the FGT (and the switches behind it) that's no problem.

HQ has redundant static routes  to all subnets at every shop-site. Shop-Site has redundant static routes to HQ.

Redundant static routes in this case means there is one static route for each tunnel and subnet. So each Shop-Site-SUbnet has a static route over both tunnels with different prio/distance. This creates redundancy because primarily traffic always uses the way with the lowest cost and if that  ain't available the next highest.

Then all we need is policies at HQ and Shop-Sites to allow the traffic we want to flow (and do some UTM stuff).

To maintain all the FGTs we use FortiManager (as a VM at HQ). Works fine here.