Skip to main content
Yosefw
Explorer
February 26, 2026
Question

Scalable Hub-and-Spoke Design with BGP, VRFs, and AWS DX (No VDOM per Customer)

  • February 26, 2026
  • 3 replies
  • 275 views

Hi all,

I’m looking for guidance on designing a scalable hub-and-spoke architecture on a FortiGate.

Design Overview

  • I have AWS connected to a FortiGate via Direct Connect (DX) and advertising routes via BGP.

  • The FortiGate acts as a hub.

  • Multiple vendors (customers) connect to the same FortiGate.

  • Each vendor has a dedicated BGP peering session.

Requirement

I need strict separation between vendors:

  • Customer A must NOT be able to communicate with Customer B.

  • Each customer should be isolated at the routing level.

  • Only the VRF associated with the AWS DX connection should have visibility of all customer prefixes.

  • Traffic flow should be:

    Customer → FortiGate → AWS
    AWS → FortiGate → Specific Customer

But never:

Customer A → FortiGate → Customer B

Constraints

  • The solution must be scalable (10+ customers, potentially more).

  • I do NOT want:

    • One VDOM per customer.

    • VDOM links between customers.

  • I’m looking to use VRFs instead of VDOMs for segmentation.

What I’m Trying to Achieve

Conceptually:

  • Each customer has its own VRF and BGP instance.

  • The AWS DX connection sits in a separate “core” VRF.

  • Routes from customer VRFs are selectively leaked only into the AWS VRF.

  • AWS routes are selectively leaked into each customer VRF.

  • No route leaking between customer VRFs.

Questions

  1. Is this design supported on FortiGate using VRFs?

  2. Is route leaking between VRFs supported in a scalable way?

  3. Is there an official guide or best-practice document for this type of multi-tenant BGP design?

  4. Would this require inter-VDOM routing under the hood, or can it be fully handled with VRFs?

Any design recommendations or documentation references would be greatly appreciated.

Thanks in advance.

Running 200F 7.4.11

 

                        │                  FortiGate                                                │                                                                           │  ┌─────────────┐                                        DX                │  │  VRF 0      │  VRF 1  ◄──────────────────► Vendor A  AWS ◄──────────────────┼──┤  (Global /  │  VRF 2  ◄──────────────────► Vendor B                         │  │   AWS-Facing│  VRF 3  ◄──────────────────► Vendor C                         │  └─────────────┘  VRF N  ◄──────────────────► Vendor N                         │        │ Route Leaking                                                    │   (AWS prefix only)                              

 

3 replies

Jean-Philippe_P
Staff & Editor
Staff & Editor
March 2, 2026

Hello jo1992, 

 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Staff & Editor
March 3, 2026

Hello,

 

We are still looking for an answer to your question.

 

We will come back to you ASAP.

Jean-Philippe - Fortinet Community Team
Jean-Philippe_P
Staff & Editor
Staff & Editor
March 4, 2026

Hey again jo1992,

 

I found this answer, can you tell us if it helps, please?

 

Design Overview

Your proposed design involves using a FortiGate as a hub in a hub-and-spoke architecture, with AWS connected via Direct Connect (DX) and BGP for route advertisement. Each vendor (customer) connects to the FortiGate with a dedicated BGP peering session, and you want to ensure strict separation between vendors using VRFs instead of VDOMs.

 

Requirements and Constraints

  • Separation: Each customer must be isolated at the routing level, ensuring no communication between different customers.
  • Visibility: Only the VRF associated with the AWS DX connection should have visibility of all customer prefixes.
  • Traffic Flow:
    • Customer → FortiGate → AWS
    • AWS → FortiGate → Specific Customer
    • No Customer A → FortiGate → Customer B
  • Scalability: The solution should support 10+ customers.
  • No VDOMs: Avoid using one VDOM per customer or VDOM links between customers.

 

Proposed Solution

  1. VRF Configuration:

    • Each customer has its own VRF and BGP instance.
    • The AWS DX connection is placed in a separate "core" VRF.
    • Routes from customer VRFs are selectively leaked only into the AWS VRF.
    • AWS routes are selectively leaked into each customer VRF.
    • No route leaking between customer VRFs.
  2. Route Leaking:

    • Use static routes or BGP to selectively leak routes between the customer VRFs and the AWS VRF.
    • Ensure that route leaking is configured to prevent any cross-communication between customer VRFs.

 

Questions and Answers

  1. Is this design supported on FortiGate using VRFs?

    Yes, FortiGate supports VRF configurations that allow for the separation of routing domains, which is suitable for your design.
  2. Is route leaking between VRFs supported in a scalable way?

    Yes, route leaking between VRFs is supported and can be configured using static routes or BGP. This allows for scalable management of multiple VRFs.
  3. Is there an official guide or best-practice document for this type of multi-tenant BGP design?

    While there is no specific guide for your exact scenario, the Fortinet documentation on Route Leaking Between VRFs with BGP and Implementing VRF can provide useful insights.
  4. Would this require inter-VDOM routing under the hood, or can it be fully handled with VRFs?

    This can be fully handled with VRFs without the need for inter-VDOM routing, as long as the VRFs are properly configured for route leaking.

 

Recommendations

  • Documentation: Review the Fortinet documentation on VRF implementation and route leaking for detailed configuration steps.
  • Testing: Before deploying, test the configuration in a controlled environment to ensure that the route leaking and isolation requirements are met.
  • Monitoring: Implement monitoring to ensure that the traffic flows as expected and that there is no unintended communication between customer VRFs.
Jean-Philippe - Fortinet Community Team
Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.