Reducing the number of customer-edge WAN routers by terminating multiple WAN circuits on a single FortiGate.

Executive Summary

In this design, multiple WAN circuits are terminated directly on a single FortiGate, eliminating the need for separate customer-edge WAN routers.

This is not a cost optimization, but a structural redesign of the network edge.

Why This Article Exists

Many network designs still assume that WAN circuits should first terminate on dedicated edge routers, and only then be handed over to a firewall. In this validation, that assumption was intentionally removed.

The FortiGate was used not only as a security device, but also as the routing termination point for multiple WAN circuits.

The Traditional Approach

A common enterprise edge design looks like this:

• WAN circuit
• Customer-edge router
• Firewall
• Internal network

This separation may look clean on paper, but it also increases device count, operational overhead, and failure points.

The Design Shift

In this design, multiple WAN circuits are terminated directly on a single FortiGate.

• No dedicated customer-edge WAN router is placed in front of the firewall
• The firewall handles both security enforcement and WAN-side routing termination
• The edge becomes simpler and easier to understand

This is not about collapsing roles recklessly. It is about removing an unnecessary device boundary where the firewall is already capable of handling the required function.

Basic Topology

The following topology was used in this validation.

This structure defines how traffic is separated before any routing decision is made.

Each LAN-side segment was intentionally kept simple. In this case, the FortiWiFi unit provided two client-side segments: one wired and one Wi-Fi.

Each segment was forwarded to a different upstream path through a separate WAN-facing route policy.

Validation Results

Both clients reached the same destination, but through different upstream paths.

Wired Client

IPv4 Address: 192.168.1.110
Default Gateway: 192.168.1.99

tracert 172.31.255.254

1  192.168.1.99
2  172.16.1.100
3  172.31.255.254

Wi-Fi Client

IPv4 Address: 10.10.80.2
Default Gateway: 10.10.80.1

tracert 172.31.255.254

1  10.10.80.1
2  172.16.2.100
3  172.31.255.254

Both clients reach the same destination, but through completely different upstream paths.

This is not load balancing. The egress path is explicitly determined by the ingress segment.

FortiGate Configuration

The separation in this validation was implemented with FortiGate policy routes.

config router policy
    edit 1
        set input-device "internal"
        set gateway 172.16.1.100
        set output-device "wan1"
    next
    edit 2
        set input-device "wifi"
        set gateway 172.16.2.100
        set output-device "wan2"
    next
end

Traffic entering from the wired segment was forwarded to WAN1 via 172.16.1.100, while traffic entering from the Wi-Fi segment was forwarded to WAN2 via 172.16.2.100.

This example uses a straightforward policy-route configuration rather than newer SDN-style abstractions. That choice is intentional: the goal here is clarity, reproducibility, and narrow validation scope.

Scope Limitation

This validation intentionally avoids additional abstraction layers.

• No LAG
• No VRF
• No SVI-based segmentation in this example

FortiGate can support SVI-based designs, but they were intentionally excluded here in order to keep the structure narrow, visible, and easier to validate.

Why This Matters

Reducing customer-edge WAN routers is not merely a hardware reduction exercise.

It changes how the network edge is defined:

• fewer devices
• fewer failure domains
• clearer traffic behavior
• simpler operational visibility

If a design only works with advanced abstractions, it is not a robust starting point. This validation shows that the edge can be simplified first, and extended later only when necessary.

Conclusion

This is not about removing routers for the sake of reduction.

It is about removing the assumption that separate customer-edge WAN routers are always required.

Contact for Deployment Validation

---

Related reading:
Read our Network Architecture Philosophy

Related case study:
[Insert link to your 20→4 fixed page here]