Technical Tip: High availability dual-site VPN using WireGuard over IPv6 with FortiGate cluster and BGP routing

Description

This article describes how to implement a high-availability, dual-site VPN using WireGuard over IPv6 transport, with full integration on both sites, using FortiGate devices in an active-passive cluster and dynamic routing via BGP.

Scope

FortiGate v7.4, v7.6.

Solution

This section describes a production architecture in which both sites are protected by FortiGate clusters, with WireGuard tunnels used as the transport and BGP dynamically exchanging routes between the sites.

Logical tunnel IPs:

Tunnel 1:

Site A WG: 10.255.255.2/30

Site B WG: 10.255.255.1/30



BGP:

Site A FortiGate:

ASN 65001

Peers:

10.255.255.1

10.255.255.5

Advertises:

10.10.0.0/24

Site B FortiGate:

ASN 65002

Peers:

10.255.255.2

10.255.255.6

Advertises:

10.20.0.0/24

The architecture includes:

Site A:

FortiGate cluster (active-passive).

WireGuard client node.

Site B:

FortiGate cluster (active-passive).

WireGuard server nodes.

Multiple WireGuard tunnels for redundancy.

Use cases:

This design is suitable for environments requiring high flexibility, IPv6 transport, and dynamic routing capabilities.

IPv6-only or IPv6-first environments: This design is appropriate where no public IPv4 connectivity is available or where IPv6 is preferred.

WireGuard operates natively over IPv6 and avoids NAT-related limitations.

Hybrid cloud connectivity: This design can be used to connect on-premises networks protected by FortiGate to cloud workloads running on Linux systems.

It provides a simplified alternative to IPsec deployments in cloud environments.

High-performance VPN requirements: WireGuard provides low overhead and high throughput.

This design is suitable for data replication, backup traffic, and latency-sensitive applications.

Environments with IPsec limitations: This design can be used where IPsec presents challenges such as NAT traversal issues, interoperability constraints, or complex configuration requirements.

Design principles:

• FortiGate handles security and routing.

• WireGuard handles encrypted transport.

• BGP dynamically exchanges routes.

• Multiple tunnels provide failover and load sharing.

Addressing example:

Site A LAN: 10.10.0.0/24.

Site B LAN: 10.20.0.0/24.

WireGuard tunnels:

10.255.255.0/30.

10.255.255.4/30.

BGP ASN:

Site A: 65001.

Site B: 65002.

WireGuard configuration (transport layer).

Each site uses multiple tunnels.

Example configuration:

[Interface]

Address = 10.255.255.2/30

PrivateKey = <private-key>

[Peer]

PublicKey = <remote-peer-1>

Endpoint = [2001:db8::1]:51820

AllowedIPs = 10.255.255.1/32

PersistentKeepalive = 25

[Peer]

PublicKey = <remote-peer-2>

Endpoint = [2001:db8::2]:51820

AllowedIPs = 10.255.255.5/32

PersistentKeepalive = 25

FortiGate cluster configuration.

Configure active-passive high availability.

config system ha

 set mode a-p

 set group-name "FGT-HA"

 set hbdev "port1" 50 "port2" 50

 set session-pickup enable

 set override disable

end

Important:

• Session synchronization must be enabled.

• Interfaces connected to WireGuard nodes must be reachable from both cluster members.

• Routing integration

• Static routing toward WireGuard nodes:

config router static

  edit X

   set dst 10.20.0.0/24

   set gateway <wg-next-hop>

   set device "internal"

  next

end

BGP configuration over WireGuard.

BGP runs between FortiGate devices using tunnel IP addresses.

Site A configuration:

config router bgp

    set as 65001

    set router-id 1.1.1.1

    config neighbor

        edit "10.255.255.1"

            set remote-as 65002

        next

        edit "10.255.255.5"

            set remote-as 65002

        next

    end

    config network

        edit 1

            set prefix 10.10.0.0 255.255.255.0

        next

    end

end

Site B configuration:

config router bgp

    set as 65002

    set router-id 1.1.1.1

    config neighbor

        edit "10.255.255.2"

            set remote-as 65001

        next

    end

    config network

        edit 1

            set prefix 10.20.0.0 255.255.255.0

        next

    end

end

FortiGate advertises local networks via BGP.

Routes are learned dynamically across WireGuard tunnels.

SD-WAN or routing metrics select the best path.

Failover occurs automatically when a tunnel becomes unavailable.

High availability behaviour:

• Active FortiGate handles traffic.

• Passive FortiGate remains synchronised.

On failover:

• Sessions are preserved.

• BGP reconverges automatically.

• Traffic resumes through available WireGuard tunnels.

Verification:

Run the following command:

diagnose sys ha status

Verify BGP state:

get router info bgp summary

Verify routing table:

get router info routing-table all

`

Troubleshooting BGP neighbour down:

• Verify tunnel reachability.

• Verify ASN configuration.

Traffic not flowing:

• Verify firewall policies.

• Verify route installation.

Failover issues:

• Verify session-pickup configuration.

• Verify HA synchronization.

Limitations and considerations:

• WireGuard is not natively supported on FortiGate and requires an external Linux node.

• IPv4-only clients cannot connect to IPv6-only endpoints.

• Additional operational overhead is incurred due to managing external WireGuard nodes.

• This design may not be suitable where strict compliance requires IPsec-based VPN solutions.

Conclusion:

• This design provides a fully resilient VPN architecture by combining:

• WireGuard encrypted transport.

• FortiGate high availability clustering.

• Dynamic routing using BGP.

• The result is a scalable and production-ready solution that supports redundancy, automatic failover, and efficient traffic engineering across multiple VPN paths.