FortiGate SD-WAN Configuration in Dubai, UAE
Build a FortiGate SD-WAN design around real circuits, applications and operational priorities rather than simply adding a second internet link. FourTeck can help scope SD-WAN members, zones, routing, performance SLAs, traffic-steering rules, firewall policies, VPN dependencies, testing and handover for single-site or distributed environments.
Start with the WAN requirement
Share your FortiGate model, FortiOS version, number of sites, current WAN links, routing method, critical applications and expected failover behaviour.
Application-aware WAN path control
Circuits, routing, applications and SLA targets
FortiOS, topology and policy design
Assessment through testing and handover
Direct answer for FortiGate SD-WAN buyers
FortiGate SD-WAN Configuration is the process of defining which WAN or tunnel interfaces participate in SD-WAN, measuring path quality, creating steering rules, aligning routing and firewall policy, and validating how traffic behaves when links become slow or unavailable. It is mainly used by organisations that need resilient internet access, better use of multiple circuits, application-aware path selection or more controlled branch connectivity. Before proceeding, confirm the FortiGate platform and FortiOS release, interface addressing, routing design, internet or MPLS circuits, VPNs, important applications, acceptable latency, jitter and packet-loss thresholds, change-window requirements, rollback plan and whether central management is part of the design.
What FortiGate SD-WAN configuration does
FortiGate SD-WAN gives network administrators a policy-driven way to use multiple paths at the WAN edge. Instead of treating each internet, private WAN or tunnel interface as an isolated route, selected interfaces can become SD-WAN members and can be grouped into zones. Performance SLAs, also called health checks in Fortinet documentation, can measure path conditions and help determine whether a member continues to satisfy the requirements defined for a rule. SD-WAN rules then decide how matched traffic should prefer or select available members.
The practical result depends on design. A business might prefer a low-latency circuit for voice, allow general browsing to use either broadband circuit, keep a private link preferred for an ERP system, or send selected cloud applications directly to the internet while retaining a backup path. This is not simply load balancing. The most useful implementations connect business application needs to routing behaviour, health measurements and security policy so that failover and path selection are predictable.
Who should consider the service
The service may suit organisations adding a secondary ISP, replacing static failover, modernising branch WANs, introducing direct internet access, improving SaaS reachability, consolidating edge security and routing, or standardising connectivity across several sites. It is also relevant when an existing SD-WAN deployment is technically working but the rules, SLA thresholds or routing interaction are difficult to understand.
It may not be appropriate to make production changes immediately when the current routing table, firewall policy, VPN topology or circuit addressing is undocumented. In that situation, discovery and a configuration backup should come first. A small office with one link may not need SD-WAN until a second usable path exists, while larger distributed environments may require FortiManager or broader architecture work in addition to device-level configuration.
Business problems the configuration can help address
A backup link exists but is rarely used
Traditional primary-and-backup routing can leave paid bandwidth idle. SD-WAN can allow selected traffic to use multiple healthy paths, but the steering method should match business expectations. Some applications tolerate session changes and variable paths better than others, so rules should be built from application behaviour rather than from bandwidth percentages alone.
Cloud applications perform inconsistently
A link can be technically up while suffering latency, jitter or packet loss. Performance SLAs can monitor conditions and allow SD-WAN rules to prefer paths that meet the defined targets. The measurement destination and thresholds must be meaningful for the application; arbitrary values can cause unnecessary switching or hide a genuine performance problem.
Branches use different WAN logic
As branch counts grow, one-off configuration choices create operational drift. A consistent design can define naming, zones, health checks, rule order, default behaviour and testing methods. Central management can be considered where several FortiGate devices need repeatable policy and configuration, but it is a separate architecture decision rather than an assumption.
Failover happens differently from expectations
Unexpected failover often comes from the interaction of routing, SLA status, rule strategy, existing sessions, firewall policy and NAT. The remedy is usually not another rule. A structured review should establish the intended path for each traffic class, what constitutes link failure or degradation, and what the user should observe during normal, degraded and recovery states.
Core capabilities to plan around
Define which physical, VLAN, tunnel or supported edge interfaces should participate and how they should be grouped for policy use.
Measure reachability and, where configured, path-quality indicators such as latency, jitter and packet loss against suitable targets.
Match traffic and choose link-selection behaviour according to application, source, destination, service, path health and the intended design.
Ensure routes, firewall policy, NAT, VPNs and SD-WAN behaviour support the same forwarding outcome rather than working against one another.
Service-fit matrix
| Business situation | Relevant assistance | Scope dependency |
|---|---|---|
| Adding a second ISP to one FortiGate | Member creation, routing, SLA checks, rules and failover testing | Interface addressing, NAT, circuit handoff and change window |
| Voice and SaaS need better path selection | Application-aware steering and suitable performance targets | Application identification, traffic profile and realistic SLA values |
| Branches use IPsec overlays | Overlay member design, tunnel health, routing and rule review | VPN topology, routing protocol, addressing and peer design |
| Several FortiGates need standardisation | Template and central-management planning | FortiManager availability, ADOM design, software versions and site exceptions |
| Existing SD-WAN rules are unstable | Configuration audit, rule-order review, SLA tuning and validation | Logs, current configuration, reproducible symptoms and application impact |
FortiGate SD-WAN service information
| Topic | FortiGate SD-WAN Configuration |
| Main purpose | Design and configure resilient, policy-driven WAN path selection on FortiGate |
| Typical environments | Single sites with multiple WAN links, branches, distributed enterprises, VPN overlay networks and cloud-connected offices |
| Assessment support | Can include topology, routing, circuit, application and existing configuration review |
| Configuration support | Scope dependent: members, zones, performance SLAs, rules, routing, policy, VPN interaction and monitoring |
| Management options | Local FortiGate management; FortiManager and other Fortinet services are optional and design dependent |
| Licensing guidance | Base SD-WAN functionality is available in FortiGate/FortiOS; broader security, analytics, management or cloud services can be subscription or license dependent |
| Customer inputs required | FortiGate model, FortiOS version, configuration backup, WAN details, topology, routing, applications, maintenance window and access method |
| Availability guidance | Contact FourTeck to confirm engineering availability and exact project scope |
Configuration, licensing and topology dependencies
Fortinet documents SD-WAN interface members, performance SLAs and SD-WAN rules as central configuration elements. These elements do not operate in isolation. The selected interfaces must have usable connectivity, routing must make destinations reachable, firewall policy must permit the intended sessions, and NAT must match the internet or private-WAN design. If IPsec, GRE, IPIP or other supported tunnel types become SD-WAN members, the tunnel and its underlying transport must also be understood. In more complex environments, dynamic routing can influence which paths are installed and how failures are propagated.
The base SD-WAN capability is built into FortiGate/FortiOS rather than sold as a separate bandwidth license. That does not mean every feature around a Secure SD-WAN architecture is automatically included. FortiManager, advanced analytics, digital experience monitoring, FortiGuard security services, FortiSASE integrations, support contracts and other components can have separate entitlement or subscription requirements. The exact commercial and technical scope should therefore be checked against the current FortiGate model, software release and desired architecture.
Version matters as well. Fortinet continues to add SD-WAN capabilities across FortiOS releases. A design created for an older release may expose different GUI options or feature behaviour from a current release, and an upgrade can affect default objects or supported settings. FourTeck should therefore be given the exact FortiOS version before configuration guidance is finalised. Where the firewall is managed by FortiManager, the manager version, ADOM mode and change process must also be considered.
Finally, performance SLA thresholds should reflect the application and path being measured. A public test target may confirm general internet quality but may not represent the SaaS service, voice platform, data centre or VPN destination that users actually care about. Measurement design should avoid a situation in which a path is marked healthy while the business application is unreachable, or marked unhealthy because the chosen probe target is unsuitable. Thresholds, probe intervals and failure/recovery expectations should be documented before production tuning begins.
A practical FortiGate SD-WAN engagement journey
Collect the FortiGate model and FortiOS release, interface layout, ISP handoffs, addressing, gateways, VLANs, current routes, VPNs, security policies and NAT. For an existing production firewall, take a configuration backup and record the known-good state. The discovery stage should also identify whether remote management depends on the same WAN paths being modified so that engineer access is not accidentally removed during the change.
List critical applications and decide what each one should do in normal, degraded and failed-link conditions. Voice may need low jitter and low latency. Backup traffic may prefer a lower-cost link. A private application may stay on an MPLS or VPN path unless that path fails. Internet browsing may use either link. These decisions turn SD-WAN from a generic feature into an operational policy that can be tested.
Choose the interfaces or tunnels that belong in SD-WAN, decide whether separate zones are useful for different path types, and map how routing will point traffic toward the SD-WAN construct. Where dynamic routing or overlays are involved, document route preference and convergence behaviour. Existing policies referencing physical interfaces may need review when those interfaces become SD-WAN members or zones.
Select probe targets and thresholds that represent the service being protected. FortiGate can monitor path quality and can use SLA status to influence member selection. The design should define what constitutes failure, unacceptable performance and recovery. Overly sensitive values can make traffic oscillate between links; values that are too relaxed can leave users on a poor path for too long.
Create SD-WAN rules in a logical order so specific business traffic is handled before broad catch-all rules. Verify source and destination matching, application or service classification where used, selected link strategy, firewall policies, NAT and route availability. Configuration should also consider DNS, asymmetric traffic and externally initiated sessions where those factors are relevant.
Validate normal traffic, deliberately fail or degrade links where the change plan permits, observe SLA state, routing and sessions, and confirm recovery. Testing should cover the applications the business identified as important rather than relying on a single ping. Record final settings, test results, known dependencies and rollback instructions so future administrators can understand why each rule exists.
Performance SLA design: measure what users actually depend on
Performance SLA is one of the most important parts of an SD-WAN design because it determines how FortiGate evaluates path quality. Current FortiOS documentation describes SD-WAN performance monitoring around reachability and metrics such as latency, jitter and packet loss. Those metrics are useful only when the chosen target and thresholds make sense for the business application.
For a cloud-first office, a general internet probe can provide baseline path health, while a separate application-oriented check may be appropriate for a critical service. For a VPN overlay, the health target should help represent the reachability of the remote side rather than only the local ISP gateway. When voice is important, jitter and latency deserve more attention than they might for bulk file transfer. When transactional applications are sensitive to path changes, recovery behaviour should be tested carefully.
The objective is stable decision-making, not the lowest possible threshold. FourTeck can help translate the application requirement into a monitor design, then validate whether the observed metrics are realistic during normal and busy periods. Thresholds should be adjusted from evidence when necessary rather than copied from a generic example.
Traffic steering: choose a rule for a reason
SD-WAN rules decide which members should carry matched traffic. The correct strategy depends on the objective: resilience, distribution, quality, priority, cost control or some combination. A rule for real-time communications can be different from a rule for software updates or general web access. More rules are not automatically better; an excessive or poorly ordered rule set can become difficult to troubleshoot.
A useful rule design starts with a traffic statement: who is communicating, with what destination or application, over which acceptable paths, and under what health conditions. The engineer can then map that statement into FortiGate configuration. Specific traffic should not be accidentally captured by an earlier broad rule, and the final/default behaviour should be understood for traffic that does not match a special case.
Existing sessions also matter during testing. Some users expect every active application flow to move instantly when a preferred path changes, but session behaviour, NAT and the remote service can affect what the user sees. Test plans should distinguish new-session path selection from ongoing-session continuity.
Routing, VPN overlays and secure branch connectivity
FortiGate SD-WAN frequently sits at the point where underlay circuits and overlay tunnels meet. The underlay might include broadband, leased internet, MPLS or cellular connectivity. The overlay might include IPsec VPN tunnels between branches, hubs, data centres or cloud environments. Fortinet documentation allows supported tunnel interfaces to participate as SD-WAN members, making it possible to steer traffic across different overlay paths when the architecture requires it.
That flexibility introduces dependencies. If two IPsec tunnels use two different internet links, the engineer must understand tunnel source interfaces, peer reachability, IKE/IPsec parameters, route installation and what happens when one underlay fails. If BGP or another routing protocol runs across the overlays, path selection has both routing and SD-WAN dimensions. A design that is correct at the route level can still behave unexpectedly if the SD-WAN rule excludes the preferred tunnel, and a healthy tunnel can still carry a poor application path if the performance SLA is not measuring the relevant endpoint.
Security policy also remains essential. SD-WAN does not replace firewall policy. Traffic still needs an allowed policy path, appropriate inspection profiles when required, and correct NAT behaviour. Direct internet breakout may reduce unnecessary backhaul for SaaS applications, but it also moves the security enforcement point to the branch. The organisation should decide how web, DNS, application control, threat prevention and logging are handled for those internet-bound sessions.
For larger branch estates, central design and change control become important. FortiManager can support centralised management and SD-WAN operations in suitable architectures, but its use should be planned together with FortiGate versions, templates, site-specific variables, routing and rollout methods. A single-site SD-WAN configuration and a multi-hundred-site orchestrated deployment are different projects even when both use the same FortiGate concepts.
Where FortiGate SD-WAN configuration can fit
Head office with dual internet
Use both circuits according to business rules, monitor quality and retain an alternate path for internet-dependent operations. The design should account for public IP services, inbound traffic and VPN termination.
Retail and hospitality branches
Separate payment, guest, corporate and cloud application priorities while using available links appropriately. Site templates can help when many locations share a common design but still require local circuit variables.
Clinics and professional offices
Support access to hosted applications, communications services and central systems with defined path preferences. Privacy, segmentation and application sensitivity should be included in policy design.
Warehouse and logistics sites
Maintain connectivity for inventory, voice, scanners and cloud platforms where primary broadband may need a secondary fixed or cellular path. Coverage and carrier quality remain external dependencies.
Branch-to-hub VPN networks
Use multiple overlays or underlays with health-aware steering where the routing and tunnel design supports it. Hub capacity, route scale and central management become important as site counts increase.
Cloud-focused organisations
Direct selected traffic toward SaaS or cloud destinations while retaining alternate WAN paths. DNS, security inspection, identity and cloud reachability should be planned with the path policy.
Integration and operational considerations
SD-WAN touches more of the network than the WAN page in the FortiGate GUI. Before implementation, identify where default routing is controlled, whether static or dynamic routes are used, which security policies reference WAN interfaces, whether VIPs or IP pools depend on a specific public address, and which VPN tunnels are bound to which circuits. DNS resolvers, DHCP options, web proxies, authentication flows and monitoring systems may also assume a particular path.
High availability requires separate thought. A FortiGate HA cluster can support SD-WAN designs, but link monitoring, switch connectivity, redundant ISP handoffs and session pickup behaviour should be assessed as part of the whole HA architecture. The presence of two firewalls does not automatically create two independent WAN paths, just as two ISPs do not create device redundancy. Power, upstream switching and provider demarcation can remain shared failure points.
Logging and observability should be included in acceptance criteria. During a failover test, the team should be able to see the performance SLA state, selected member, relevant route, firewall session and event timing. FortiAnalyzer, FortiManager, FortiGate Cloud or other monitoring tools may be useful depending on the environment and entitlements, but they should not be assumed as part of every scope. Even without additional platforms, a clear runbook should describe which FortiGate views or CLI commands the operations team uses to diagnose a WAN complaint.
Finally, change control matters because SD-WAN can alter the egress path for many sessions at once. Schedule work within an agreed maintenance window where appropriate, protect remote management access, keep an approved configuration backup, define rollback criteria and confirm who is available to test business applications. A technically correct configuration is only one part of a safe production change.
Questions to resolve before the configuration starts
Identify voice, video, ERP, SaaS, backups, VPN traffic and other services whose path selection should differ from general internet traffic.
Define whether failure means no reachability or whether latency, jitter and packet loss should cause a rule to avoid a degraded link.
Confirm physical WANs, VLAN handoffs, LTE/5G devices, MPLS links and IPsec overlays, including addressing and upstream gateways.
Static routes, BGP, OSPF and tunnel routes can all influence design. Existing route preference must be understood before the forwarding model changes.
A few sites can be administered individually, while larger estates may benefit from FortiManager-based templates and controlled rollout processes.
Agree when the change should be reversed, who authorises rollback, how access is retained and which business tests must pass before closure.
Procurement and project checklist
How FourTeck can assist
FourTeck can help turn an SD-WAN objective into a defined technical scope. The engagement can begin with a review of the existing FortiGate configuration, WAN circuits, routing, VPNs and application requirements. From there, assistance can cover design decisions such as member and zone structure, performance SLA targets, rule sequence, path-selection behaviour and the way security policy and NAT should reference the WAN design.
For implementation, the quotation can identify whether work is performed remotely, on site or in a coordinated hybrid model; how many FortiGate devices are included; whether configuration is new or a change to an existing production environment; and whether FortiManager, IPsec overlays, dynamic routing or HA are part of the scope. Testing can be planned around the applications and failure conditions the customer needs to validate rather than a generic connectivity check.
Documentation can include the agreed configuration logic, member and zone names, SLA objects, rule purpose, route dependencies, test observations and rollback information. Post-change support should also be defined: some customers need only implementation and handover, while others need a follow-up tuning window after enough production data has been observed.
To explore related firewall and network services, review FourTeck firewall services, browse network security products, or see the Fortinet firewall guidance for wider platform planning.
Information that improves quotation accuracy
Send the FortiGate model, FortiOS version, site count, current topology, interface list, WAN providers, bandwidth, IP addressing, routing protocol, VPN design and the applications that require special treatment. Note whether an engineer can access the device remotely, whether an on-site visit is expected, and the preferred maintenance window.
A requirement such as “configure two WANs” can describe a one-hour lab task or a complex production change involving tunnels, BGP, HA and many branches. A quotation becomes more meaningful when the forwarding and testing scope is explicit.
UAE availability and support guidance
Contact FourTeck to confirm current UAE engineering availability for FortiGate SD-WAN assessment, configuration and troubleshooting. The service schedule depends on the number of FortiGate devices, FortiOS versions, whether the environment is already in production, the required access method, topology complexity, routing and VPN dependencies, documentation quality and the customer’s approved change window. Hardware or license procurement, if needed, should be itemised separately from professional configuration work.
Delivery and project coordination can be discussed after the exact requirement is confirmed. Installation or configuration should be included explicitly in the quotation when required rather than assumed as part of firewall supply. If the project includes new FortiGate appliances, FortiManager, support contracts, transceivers, FortiExtender devices or other components, availability may depend on model, quantity, region and vendor lead time.
Dubai, Abu Dhabi, Sharjah and Ajman project coordination
FourTeck can coordinate FortiGate SD-WAN requirements for organisations operating across Dubai, Abu Dhabi, Sharjah and Ajman through one combined project discussion. Multi-site work should identify each site’s FortiGate model, circuit handoff, local addressing, VPN role, maintenance window and whether the location needs remote-only assistance or planned on-site participation. A shared technical template can be useful where branches are similar, but site-specific WAN credentials, public addresses, routing and provider behaviour still need to be recorded. For distributed businesses, it is also useful to define one owner for application testing and one owner for network change approval so that branch rollout does not rely on assumptions made at the head office.
GCC Availability
FourTeck can assist organisations planning FortiGate SD-WAN work across GCC markets with requirement review, firewall and license selection where procurement is part of the project, quotation coordination, configuration scope, rollout planning and renewal guidance. Regional deployments may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman, but one template should not be assumed to fit every location. ISP presentation, public addressing, local routing, cellular options, maintenance practices and site-access rules can differ. Product availability, licensing, delivery schedules, service visits, project scope and vendor lead times can also vary by country, model, quantity and requirement. Buyers should share the destination country, FortiGate model, site count, WAN circuits, desired SD-WAN behaviour, license term if applicable, deployment location and expected timeline so FourTeck can define suitable next steps without making unsupported supply or scheduling assumptions.
Africa Availability
For organisations extending FortiGate SD-WAN projects into Africa, FourTeck can help review appliances, licenses, accessories, subscriptions, branch connectivity, configuration requirements, support needs and regional procurement planning. Network conditions can differ significantly between markets and between individual sites, so the design should account for available fixed circuits, mobile backup, power quality, provider routing, public IP requirements and the operational ability to test a failover event. Availability and fulfilment may depend on destination, product model, quantity, license region, shipping arrangements, vendor lead time, installation scope and local project conditions. Customers should provide the destination country, exact FortiGate requirement, number of sites, preferred deployment schedule and any installation or support expectations. FourTeck can also coordinate regional discussions through FourTeck Africa, with specific project commitments confirmed only after the local requirement is reviewed.
Related options and complementary FourTeck services
FortiGate firewall sizing
If the existing appliance is being replaced or the SD-WAN project introduces new sites, model sizing should consider inspected traffic, VPN, users, sessions, interfaces and expected growth rather than WAN bandwidth alone.
FortiManager planning
Central management can support consistent multi-site configuration and controlled change processes. Suitability depends on estate size, FortiOS versions, ADOM design and the organisation’s administration model.
IPsec VPN design
Branch overlays can be combined with SD-WAN where the architecture requires multiple tunnels or underlays. Tunnel, routing and health-check design should be planned together.
Firewall migration
Moving from another firewall or an older FortiGate is an opportunity to redesign WAN logic instead of replicating legacy static routes. Migration scope should include policy, objects, NAT, VPN and rollback.
Explore more through the Firewall Dubai resource hub or contact FourTeck with your current topology.
What buyers usually need to understand before choosing an SD-WAN design
Businesses often begin by asking how to configure SD-WAN on a FortiGate, but the more important question is what behaviour they expect after the configuration is complete. Two WAN links can be used in several ways: one can remain preferred while the other is reserved for failure, both can carry selected traffic, applications can be steered according to path quality, or overlays can be chosen according to SLA status. Each approach changes what users experience during congestion, outage and recovery.
Is FortiGate SD-WAN just load balancing?
No. Load distribution can be part of the design, but FortiGate SD-WAN also supports health-aware and policy-driven path selection. A business can define different rules for different traffic classes and use performance information to avoid a path that is technically up but no longer suitable for a sensitive application. The value comes from combining policy, measurement and routing, not simply splitting sessions between two interfaces.
Does SD-WAN need a separate Fortinet license?
Fortinet describes the core SD-WAN functionality as built into FortiGate/FortiOS, without a separate bandwidth license for enabling basic SD-WAN operation. Buyers should still distinguish that capability from subscriptions or products that may be used around the wider solution. Security services, FortiManager, analytics, cloud-delivered services, support and other features can have their own commercial requirements.
Another frequent concern is whether SD-WAN can use MPLS, broadband and 4G/5G together. FortiGate can use a range of supported interface types as SD-WAN members, including physical interfaces and supported tunnel interfaces, so mixed-path architectures are possible. The design still needs to respect how each service is delivered. An MPLS connection may use private routing and no NAT, an internet circuit may require NAT and public DNS, and a cellular link may introduce carrier NAT or data-plan constraints. Treating all three as identical members without understanding these differences can create inconsistent results.
Buyers also search for the “best” performance SLA values. There is no universal set. Latency, jitter and packet-loss tolerance vary by application and geography. A voice service generally cares more about jitter and delay than a file download does. A cloud application hosted nearby should not necessarily use the same threshold as an application accessed across a long international path. A practical approach is to collect baseline measurements during normal operation, understand application tolerance, and then set thresholds that identify genuinely poor conditions without causing frequent unnecessary path changes.
Failover time is another area where expectations should be clarified. The visible user impact is influenced by probe interval, failure detection, routing, rule logic, existing sessions, NAT and application behaviour. Even if FortiGate quickly selects another healthy member, an established application session tied to the previous public IP may need to reconnect. For that reason, acceptance testing should include the actual application experience and not only route-table changes.
For organisations with several branches, the next question is often whether every firewall should be configured manually. A small estate can be manageable with local administration, but consistency becomes harder as branch counts grow. FortiManager can be considered for centralised deployment, templates, objects and operational control. The decision depends on the number of sites, configuration similarity, software versions, change-governance process and whether the organisation already uses FortiManager.
Pricing for SD-WAN configuration is therefore usually scope based. A single FortiGate with two known ISP links and a clear change window is materially different from an HA pair with BGP, multiple IPsec overlays, central management and a requirement to migrate dozens of branches. Buyers can help FourTeck prepare a more useful quotation by sharing a sanitized configuration backup where appropriate, a topology diagram, WAN circuit details, the expected traffic policy, site count, access method and test plan. This also makes it easier to separate initial engineering from optional after-hours work, travel, hardware, licensing and ongoing support.
Finally, troubleshooting usually becomes simpler when the design is documented in business terms. Instead of a rule called “rule-3,” use a clear purpose such as “Voice prefers ISP-A when SLA is met.” Instead of monitoring an arbitrary public address, record why the probe target represents a service. Instead of assuming the backup link works, test it deliberately and capture the result. These practices make future incidents easier to interpret and reduce the risk that an administrator removes an object that appears unnecessary but actually supports failover logic.
Decision questions buyers ask before implementation
Can I add an existing WAN interface to SD-WAN without affecting users?
It can require changes to routes and policies that currently reference the physical interface, so production impact must be assessed first. The safe method is to review the current configuration, map dependencies, take a backup, protect management access and make the change inside an approved window when the risk warrants it. FourTeck can scope the conversion rather than assuming it is a non-disruptive GUI change.
Should the performance SLA test the ISP gateway or an internet destination?
The correct target depends on what you need to prove. An ISP gateway may show that the first hop is reachable but not that the wider internet or application works. A public endpoint can show broader reachability but may not represent a private service or SaaS path. Many designs use more than one health check or choose application-relevant destinations, provided the target is stable and appropriate.
Can SD-WAN improve Microsoft 365, voice or other SaaS traffic?
It can help select among available WAN paths according to policy and measured conditions, but it cannot fix an application problem outside those paths or guarantee cloud performance. The configuration should identify the traffic accurately, choose useful measurements and define what happens when one path fails the target. DNS, internet peering and remote-service behaviour remain outside the firewall’s direct control.
Do I need FortiManager for branch SD-WAN?
Not for basic SD-WAN on a single FortiGate. FortiManager becomes a consideration when central administration, templating, multi-site change control or orchestrated operations are needed. The value depends on branch count, standardisation goals and the existing management estate, and the license or platform scope should be confirmed separately.
What should be tested after the change?
Test normal internet access, important SaaS and private applications, VPN connectivity, the preferred path for selected traffic, failover when a link is unavailable, behaviour when a path is degraded if that can be safely reproduced, and recovery after the path returns. Confirm logs and monitoring as well. A successful ping is not enough evidence for a business application.
What does FourTeck need to prepare a configuration quote?
Provide the firewall model and FortiOS version, number of sites, WAN circuit details, topology, current routing, VPN dependencies, important applications, expected path logic, maintenance window and whether remote access is possible. Also state whether you need assessment only, implementation, after-hours work, documentation, training or post-change tuning so those tasks can be separated clearly.
Why businesses contact FourTeck for SD-WAN work
The useful part of professional assistance is not a promise that one configuration works everywhere. It is the ability to clarify the requirement, identify dependencies and convert the desired business behaviour into a testable FortiGate design. FourTeck can help customers decide whether the project is a simple dual-WAN configuration, an SD-WAN troubleshooting exercise, a branch template initiative, an overlay-routing project or part of a larger firewall refresh.
That distinction affects the bill of materials and the engineering scope. A customer may already own suitable FortiGate appliances and only need configuration. Another may need new appliances, FortiCare or FortiGuard subscriptions, FortiManager, cellular backup or transceivers. A third may need migration from an existing vendor and wants the new SD-WAN design introduced during the cutover. FourTeck can help separate these items so the quotation is understandable.
For background on the company and broader services, visit About FourTeck Firewall Dubai. No project scope, site visit, delivery date or compatibility outcome should be assumed until the environment and requirements have been reviewed.
Frequently asked questions
What is FortiGate SD-WAN Configuration mainly used for?
It is used to make FortiGate manage multiple WAN or tunnel paths according to policy, link health and application requirements. Typical goals include resilient internet access, better use of multiple circuits, application-aware steering and more consistent branch connectivity.
Does FortiGate SD-WAN require a separate license?
Fortinet documents the base SD-WAN functionality as available on FortiGate/FortiOS without a separate SD-WAN bandwidth license. Other elements such as FortiGuard services, FortiManager, analytics, cloud services or support can have separate licensing or subscription requirements.
Can FortiGate use two internet providers at the same time?
Yes, a suitable SD-WAN design can use multiple healthy members according to configured rules. Whether traffic is balanced, preferred on one link or selected by performance depends on the rule strategy, routing, application requirements and circuit characteristics.
What are performance SLAs in FortiGate SD-WAN?
Performance SLAs are health checks used to evaluate path reachability and quality. Depending on configuration, FortiGate can monitor metrics such as latency, jitter and packet loss and use SLA status as part of SD-WAN path selection. Targets and thresholds should match the real application need.
Can IPsec VPN tunnels be used as SD-WAN members?
Supported tunnel interfaces can participate in FortiGate SD-WAN designs. The overlay and its underlay still need correct routing, peer reachability, security policy and health monitoring, so tunnel-based SD-WAN should be designed as part of the full VPN architecture.
Will SD-WAN guarantee that cloud applications never disconnect?
No. SD-WAN can select an alternate healthy path, but existing sessions, NAT, remote-service behaviour, DNS and failures outside the available WAN paths can still affect applications. The correct expectation should be defined and tested for each important service.
Can FourTeck configure an existing production FortiGate?
Configuration changes can be scoped for an existing FortiGate, subject to access, backup, topology review, maintenance-window approval and rollback planning. The current FortiOS version and dependencies should be assessed before production changes are scheduled.
What information is needed for a FortiGate SD-WAN quotation?
Provide the FortiGate model, FortiOS version, number of sites, WAN circuits and bandwidth, IP addressing, routing, VPN design, important applications, desired failover or steering behaviour, access method, change window and required documentation or support.
Is FortiGate SD-WAN configuration assistance available in the UAE?
Contact FourTeck to confirm current UAE engineering availability. Scheduling and scope depend on the number of devices, topology complexity, remote or on-site requirements, change windows and any hardware, licensing or central-management components included in the project.
Plan the FortiGate SD-WAN change around your real traffic
Share the firewall model, FortiOS release, WAN circuits, VPN topology, important applications and the behaviour you expect during normal operation, degradation and failure. FourTeck can help define the configuration, testing and handover scope for a quotation.