This technical blog documents a dual-side high availability deployment where Ray HA is integrated with Fortinet HA using IPsec tunnel connectivity. The architecture was validated in a lab environment using continuous ping tests from both directions while the Fortinet primary device and Ray primary device were brought down to observe failover behavior. The document gives priority to the Ray side because Ray is the solution vendor and the Ray platform is the main HA, gateway, policy-based IPsec, and SLA monitoring component in this deployment.
The Ray side uses policy-based IPsec. The Fortinet side uses IPsec with static route forwarding toward the Ray subnet. Ray-side SLA monitoring and Fortinet-side DPD tuning were used to improve failure detection and tunnel recovery behavior. The original failover observation was approximately 80 seconds. After optimization, traffic recovered in under 25 seconds, with observed Ray-side failover recovery between approximately 15 and 19 seconds in the shared ping validation images.
Validated Improvement
Before tuning: approximately 80 seconds failover recovery. After Ray SLA and Fortinet DPD tuning: under 25 seconds, with observed Ray primary failure recovery around 15-19 seconds.
Although HA exists on both sides, the design is Ray-centric. The Ray HA cluster is the solution layer that provides LAN-side gateway continuity, policy-based IPsec encryption domain control, SLA-based tunnel/path monitoring, and failover optimization. Fortinet HA remains an important integration peer at the remote site, but the technical value being demonstrated is how Ray integrates with an existing Fortinet HA firewall environment and improves continuity using Ray HA and Ray SLA behavior.
The deployment uses HA on both sides. On the Ray side, two Ray devices operate as a high availability pair. One Ray device is active during normal operation, and the secondary Ray device becomes active when the primary Ray device is unavailable. On the Fortinet side, two Fortinet firewalls operate as an HA pair, where the Fortinet secondary unit takes over when the Fortinet primary device fails.
| Layer | Ray Side | Fortinet Side | Purpose |
|---|---|---|---|
| Gateway / Firewall HA | Ray Primary and Ray Secondary in HA | Fortinet Primary and Fortinet Secondary in HA | Protects against appliance failure on both sides |
| IPsec Model | Policy-based IPsec | IPsec with static route | Builds secure site-to-site connectivity |
| Failover Detection | Ray SLA monitoring and HA state detection | Fortinet DPD and HA state detection | Improves failure detection and tunnel recovery |
| Traffic Direction | Ray LAN to Fortinet LAN through policy match | Fortinet LAN to Ray LAN through static route | Ensures bidirectional private network communication |
| Validation | Ray-to-Fortinet ping and Ray primary down test | Fortinet-to-Ray ping and Fortinet primary down test | Confirms traffic continuity during failover |
Figure : Dual-side HA topology with Fortinet HA and Ray HA cluster integrated through primary and backup IPsec paths.
The IPsec integration is asymmetric in configuration style but aligned in traffic objective. The Ray side uses policy-based IPsec, while the Fortinet side forwards traffic using IPsec with static route configuration. This is a common integration model when one side uses encryption-domain policies and the other side uses route-based or interface-based forwarding logic.
On the Ray side, IPsec is configured as policy-based. This means traffic is encrypted based on matching source and destination subnets. When traffic from the Ray local subnet matches the Fortinet remote subnet selector, Ray sends the traffic through the IPsec tunnel. Ray SLA is then used to track the health of the tunnel or reachability path so the system can react faster during failure.
On the Fortinet side, the IPsec tunnel is paired with a static route. The static route sends traffic destined for the Ray local subnet into the IPsec tunnel. DPD is tuned on the Fortinet side so the firewall detects an unavailable peer faster and recovers tunnel forwarding more quickly.
Ray side logic: Source: Ray local subnet Destination: Fortinet local subnet Action: encrypt using policy-based IPsec SLA: monitor tunnel/path health Fortinet side logic: Destination: Ray local subnet Route: static route through IPsec tunnel DPD: detect remote peer failure faster HA: secondary unit takes over when primary fails
The key technical improvement in this deployment came from failure detection tuning. During the initial test, when the primary device went down, traffic shifted to the secondary path in approximately 80 seconds. After tuning Ray-side SLA and Fortinet-side DPD, the recovery time reduced to under 25 seconds.
| Optimization Area | Before Tuning | After Tuning | Technical Impact |
|---|---|---|---|
| Primary device failure recovery | Approx. 80 seconds | Under 25 seconds | Reduced application and user traffic interruption |
| Ray-side failure detection | Slower SLA/path reaction | Faster SLA-based detection | Ray can move traffic to the available path faster |
| Fortinet-side peer detection | Longer dead peer detection behavior | DPD tuned for faster peer failure detection | Fortinet can clear/recover tunnel state faster |
| End-to-end tunnel continuity | Longer outage window | Short outage window | Improved business continuity for site-to-site traffic |
Ray SLA gives the Ray HA side faster visibility into tunnel or path failure and should be positioned as the primary optimization layer. Fortinet DPD acts as the supporting remote-peer optimization.
Failover was validated using continuous ICMP traffic in both directions. The test approach was simple and effective: keep traffic running continuously, bring down the primary device, observe packet loss or latency spike, and verify how quickly traffic resumes through the secondary device or path.
Traffic was initiated from the Ray network toward the Fortinet local subnet, targeting host 192.168.201.2, as shown in Figure.
Figure : Continuous ping from Ray side to Fortinet side during Fortinet primary down and Ray primary down events.
Fortinet primary device down observation:
icmp_seq=3 icmp_seq=1 time=8.82 ms icmp_seq=2 time=1159 ms icmp_seq=3 received icmp_seq=4 time=9.55 ms
When the Fortinet primary device was brought down, traffic continued with only one visible high-latency response of approximately 1159 ms. No major packet loss is visible in this section of the test. This indicates that Fortinet HA failover completed quickly enough for the Ray-to-Fortinet traffic stream to continue.
Ray primary device down observation:
icmp_seq=3 icmp_seq=20 received icmp_seq=36 received
When the Ray primary device was brought down, the sequence jumped from 20 to 36. This indicates approximately 15 missed ping responses, which is roughly 15 seconds when using the normal one-second ping interval. This validates that Ray HA failover and SLA-based recovery completed under the 25-second target.
Traffic was initiated from the Fortinet network toward the Ray local subnet, targeting host 192.168.101.176 as shown in the figure.
Figure : Continuous ping from Fortinet side to Ray side during Fortinet primary down and Ray primary down events.
Fortinet primary device down observation:
icmp_seq=3 time=9.34 ms icmp_seq=4 time=618 ms icmp_seq=5 time=8.43 ms
When the Fortinet primary device was brought down, one response showed a temporary latency spike of approximately 618 ms. After this, latency returned to normal values. This confirms that Fortinet HA failover did not create a long traffic outage in the reverse direction.
Ray primary device down observation:
icmp_seq=21 received icmp_seq=41 received
When the Ray primary device was brought down, the sequence jumped from 21 to 41. This indicates approximately 19 missed ping responses, or around 19 seconds of recovery time. This still meets the optimized target of under 25 seconds.
| Test Scenario | Traffic Direction | Observation | Recovery Interpretation |
|---|---|---|---|
| Fortinet primary down | Ray to Fortinet | Temporary latency spike around 1159 ms | Fortinet HA completed quickly with no major visible loss |
| Ray primary down | Ray to Fortinet | Sequence jump from 20 to 36 | Approx. 15 seconds recovery |
| Fortinet primary down | Fortinet to Ray | Temporary latency spike around 618 ms | Fortinet HA completed quickly with no major visible loss |
| Ray primary down | Fortinet to Ray | Sequence jump from 21 to 41 | Approx. 19 seconds recovery |
Traceroute was used to validate bidirectional reachability through the IPsec path. In both traceroute outputs, the second hop shows timeout. This is common in firewall/VPN paths because some devices do not respond to traceroute or TTL-expired probes. The key validation point is that the final destination was reached successfully in both directions.
traceroute to 192.168.101.169 1 _gateway (192.168.201.1) 6.755 ms 6.564 ms 6.527 ms 2 * * * 3 192.168.101.169 8.782 ms 8.701 ms 8.844 ms
Analysis: Fortinet-side traffic reaches the Ray-side destination 192.168.101.169 at hop 3. This confirms that Fortinet static routing and the IPsec path toward Ray are functioning.
Figure : Traceroute from Fortinet side to Ray-side destination 192.168.101.169.
traceroute to 192.168.201.8 1 192.168.101.2 1.934 ms 1.791 ms 1.783 ms 2 * * * 3 192.168.201.8 11.605 ms 11.584 ms 11.775 ms
Analysis: Ray-side traffic reaches the Fortinet-side destination 192.168.201.8 at hop 3. This confirms that the Ray policy-based IPsec path and Fortinet-side forwarding are working in the Ray-to-Fortinet direction.
Figure : Traceroute from Ray side to Fortinet-side destination 192.168.201.8.
| Direction | Destination | Visible Path | Result |
|---|---|---|---|
| Fortinet -> Ray | 192.168.101.169 | 192.168.201.1 -> *** -> 192.168.101.169 | Reachable at hop 3. |
| Ray -> Fortinet | 192.168.201.8 | 192.168.101.2 -> *** -> 192.168.201.8 | Reachable at hop 3. |
When the Fortinet primary device is brought down, Fortinet HA moves traffic processing to the secondary unit. In the shared test images, this produced only a temporary latency spike. From the Ray-vendor perspective, this confirms that Ray can continue to communicate with the Fortinet HA environment while the remote firewall role changes.
When the Ray primary device is brought down, the Ray secondary device takes over the active role. This is the most important validation item for the Ray solution. The observed traffic recovery was approximately 15 seconds in the Ray-to-Fortinet direction and approximately 19 seconds in the Fortinet-to-Ray direction. Both results are under the 25-second target after Ray SLA and Fortinet DPD optimization.
The Ray primary device down test is the strongest evidence in this blog. It proves that the Ray HA pair can shift traffic to the secondary Ray device within the optimized recovery window, improving from the earlier approx. 80-second behavior to under 25 seconds.
For stable site-to-site IPsec behavior, routing, NAT, and firewall policy must be cleanly separated. NAT should be disabled for private LAN-to-LAN IPsec traffic and enabled only for Internet-bound traffic. Static routes on Fortinet must point Ray-bound traffic into the tunnel, and Ray policy-based selectors must match the intended local and remote subnets.
| Configuration Item | Recommended Setting | Reason |
|---|---|---|
| Ray IPsec type | Policy-based IPsec | Matches Ray and Fortinet subnet pairs and encrypts selected traffic |
| Fortinet route | Static route for Ray subnet via IPsec | Prevents Fortinet from sending Ray-bound traffic toward the default Internet route |
| NAT for VPN traffic | Disabled / exempted | Preserves original private subnets required by IPsec selectors and routing |
| NAT for Internet traffic | Enabled as per WAN policy | Allows user Internet access without affecting VPN traffic |
| Ray SLA | Enabled and tuned | Improves tunnel/path failure detection and failover speed |
| Fortinet DPD | Enabled and tuned | Improves dead peer detection and tunnel recovery |
Traceroute should be used after ping validation to verify the forwarding path from both sides. The current shared evidence contains ping images. The traceroute validation should confirm that Ray-to-Fortinet and Fortinet-to-Ray traffic follows the expected tunnel route and does not take an incorrect Internet/default route.
| Traceroute Direction | Command/Test | Expected Validation |
|---|---|---|
| Ray to Fortinet | traceroute <Fortinet local subnet IP> | Traffic should follow the Ray IPsec path toward the Fortinet side |
| Fortinet to Ray | execute traceroute <Ray local subnet IP> | Traffic should follow the Fortinet IPsec/static route toward the Ray side |
| After Fortinet primary down | Repeat traceroute | Path should remain reachable after Fortinet HA failover |
| After Ray primary down | Repeat traceroute | Path should recover through Ray secondary within the optimized window |
| Issue | Likely Cause | Recommended Check |
|---|---|---|
| Tunnel is up but traffic fails | NAT applied to VPN traffic or selector mismatch | Verify NAT exemption and Ray/Fortinet local-remote subnet definitions |
| Fortinet to Ray traffic fails | Missing or incorrect Fortinet static route | Verify route to Ray subnet points to IPsec tunnel |
| Ray to Fortinet traffic fails | Policy-based IPsec selector mismatch | Verify Ray policy source/destination subnet pairs |
| Failover takes too long | SLA or DPD timers too slow | Review Ray SLA and Fortinet DPD tuning |
| Failover works one way only | Asymmetric routing or missing policy | Check both directions. Ray to Fortinet and Fortinet to Ray |
| High packet loss during HA event | HA sync, switch path, or tunnel renegotiation delay | Check HA sync state, switch redundancy, and tunnel logs |
This validation confirms that Ray HA can successfully integrate with Fortinet HA using IPsec connectivity while maintaining bidirectional communication between Ray and Fortinet local networks. The Ray side uses policy-based IPsec, while the Fortinet side uses IPsec with static route forwarding. This mixed integration model worked successfully when routing, NAT exemption, firewall policy, SLA, and DPD were configured correctly.
The primary technical outcome is the improvement in failover performance. The earlier observed recovery time was approximately 80 seconds. After Ray-side SLA optimization and Fortinet-side DPD tuning, failover recovery improved to under 25 seconds. In the shared ping validation, Ray primary failure recovered in approximately 15 seconds in one direction and approximately 19 seconds in the reverse direction.
For enterprise environments that need stable site-to-site connectivity with minimal downtime, Ray HA with policy-based IPsec, SLA monitoring, and Fortinet HA integration provides a practical and validated deployment model. The Ray platform remains the key solution layer for HA continuity and failover optimization.
