FG-100F in HA without using switches

[nethori]

Hi everyone,
I'm relatively new to networking and eager to learn.I would appreciate your input regarding a technical solution. Specifically, in the following architecture, I aim to facilitate communication between zones using two firewalls configured in High Availability (HA) active-passive mode. The challenge lies in achieving complete redundancy without employing intermediate switches between servers and firewalls.

In the scenario where, for instance, FG1 is the active firewall and the connection between SRV1 and FG1 drops for a specific reason, I'm unsure how to achieve full redundancy without using intermediate switches. In such cases, the only solution seems to be manually forcing an HA failover.

I'm thinking about using HA active-active, but I haven't used FortiGate devices in this mode before, and I'm uncertain if it's the optimal solution. I understand that having a pair of switches between servers and firewalls is preferable, but due to space and cost constraints, I'm considering this approach as a last resort.

I would greatly appreciate any insights or recommendations from the community on this matter. Thank you for your support.

[AEK · Accepted solution]

Hi Nethori

I've never thought of such design but I think there might be some useful ideas.

• I think A-P HA would be more adapted. Could't imagine how can do that with A-A HA
• From server side you will have to find a suitable IP Multi-Pathing mechanism that work best in such situation. I think about something like old unix A-P L3 based IPMP
• L2 based IPMP may not work here since the passive FG's interfaces still L2-up
• Nowadays I guess there should be many IP multipathing mechanisms to choose from
• The floating IP will be on the server's port that can reach the gateway, and will failover automatically when FG fails over
• Configure IPMP failover as shortest as possible
• On FG cluster you should not set the back-end links as HA monitored interfaces, because if one sever goes down, the FG will failover and failback untill the sever comes up again
• So I think the good solution for link redundancy is to go for LACP from each server to each FG

Once all this done, you need to test all possible scenarios before go prod.

[AEK · Accepted solution]

Hi Nethori

I've never thought of such design but I think there might be some useful ideas.

• I think A-P HA would be more adapted. Could't imagine how can do that with A-A HA
• From server side you will have to find a suitable IP Multi-Pathing mechanism that work best in such situation. I think about something like old unix A-P L3 based IPMP
• L2 based IPMP may not work here since the passive FG's interfaces still L2-up
• Nowadays I guess there should be many IP multipathing mechanisms to choose from
• The floating IP will be on the server's port that can reach the gateway, and will failover automatically when FG fails over
• Configure IPMP failover as shortest as possible
• On FG cluster you should not set the back-end links as HA monitored interfaces, because if one sever goes down, the FG will failover and failback untill the sever comes up again
• So I think the good solution for link redundancy is to go for LACP from each server to each FG

Once all this done, you need to test all possible scenarios before go prod.

[Magnitude_8]

I don't believe you can achieve complete redundancy without some switches in place. Ideally, you should have a switch stack with connections distributed evenly across them so the system could copy with firewall, switch and NIC failures. At the very least, you'll need a single intermediate switch.

I presume that you have an internet service coming into your FG-100F. How will this fail over without a switch?

My suggestion would be to find a way to get a switch in there.

[BSeklecki_GE]

If you're thinking to use the "hard switch" or "Soft switch" function to accomplish a combined Firewall+Switch hardware stack, I recommend "Abandon all hope ye who enter here"

For example, even if you could Trunk a Dot1Q link between the chassis, you couldn't maintain a spanning tree instance on the soft switch or hard switch. to support NIC teaming by extending a bridge domain (VLAN) across the chassis, it seems, even if the chassis are active-standby or active-active.

I recently made inquiries here and on Cisco's forums related to FirePower product family, and neither vendor are implementing this.

https://community.fortinet.com/t5/Support-Forum/Pre-Sales-Engineering-Question-Bridging-Switching-Ca...

Closest thig would still be a Cisco ASR9K or Cisco ISR4K with a Catalyst Switch Module, but then you're not running a stateful inspection engine.  

[nethori · Accepted solution]

Hi all,
First, thank you to everyone who offered to help, and I apologize for my very late response.

For the final accepted solution under the given conditions (without an intermediate switch), I made the following configurations:

Servers:
For the server interfaces, I created NIC teaming (i.e., IF1 + IF2) using the following settings:

• Teaming mode: Switch-independent
• Load balancing mode: Dynamic
• Standby adapter: IF2

Firewalls:

• Traffic from the servers will flow as follows: everything through IF1 goes to FG1, and everything through IF2 goes to FG2.

• HA (High Availability) is set to Active-Passive mode.

• I configured a higher priority for FG1 to ensure it acts as the primary unit.

• An important note: I enabled Override, meaning when Override is enabled, the system will follow the priority order below:

  1. Number of active monitored ports
  2. Priority
  3. Uptime (if the difference exceeds 5 minutes by default)
  4. Serial number

In my case, I did not configure anything for the number of active monitored ports, which means the primary unit will always be the active one when it is available.

These are the main settings. I know this does not provide full redundancy, but based on testing, it seems to be the most stable configuration.

Thank you again to everyone for your help.

[AEK]

Thanks for sharing, Nethori.

If all redundancy/fail-over tests have been done successfully then you may mark your last post as a solution, so other members can use it in similar scenarios.