FortiGate Remote Access VPN in Dubai, UAE
Remote access is no longer just a matter of opening a tunnel to the office. A dependable FortiGate design should identify who is connecting, which device is being used, what applications are actually required, how the session is authenticated, and what must be logged or restricted after access is granted. FourTeck helps businesses translate those requirements into a practical FortiGate and FortiClient remote-access plan.
Start with the environment, not a template
Share the FortiGate model, FortiOS version, user count, identity platform, endpoint mix, applications that must be reached, and whether the project is a new deployment or an SSL-VPN migration.
Direct answer for buyers
FortiGate Remote Access VPN is a controlled method for connecting individual users or endpoints to business resources through a FortiGate security gateway. It is mainly used for hybrid work, travelling staff, administrators, contractors, and other approved users who need encrypted access to internal systems. Organisations should consider it when they already use FortiGate or want remote connectivity governed by FortiOS security policies. Before proceeding, confirm the FortiGate model and firmware, user and device count, authentication design, endpoint operating systems, internal applications, routing model, split- versus full-tunnel policy, logging needs, FortiClient edition, and any migration requirement from older SSL-VPN tunnel configurations.
What the solution actually does
A FortiGate remote-access deployment establishes an encrypted path between a remote endpoint and a FortiGate that acts as the VPN gateway. Once a user is authenticated and the tunnel is established, FortiGate policies determine which internal networks, servers, applications, or internet paths that session may use. The design can be intentionally narrow, giving a user access only to a specific application subnet, or broader when the business requires access to several internal services.
For current FortiOS designs, IPsec should be evaluated first for tunnel-based remote access. Agentless VPN can serve selected browser-based access requirements without installing a tunnel client, but it is not a universal replacement for full network-layer connectivity. The correct choice depends on applications, user workflow, security policy, operating systems, device ownership, and the FortiGate platform in use.
Who should consider it
The strongest fit is an organisation that needs named users to reach private resources from home, customer sites, hotels, project offices, or mobile connections while keeping access under central security policy. Typical buyers include IT managers supporting hybrid teams, security teams reducing uncontrolled remote entry points, system administrators who need secure management access, and procurement teams replacing legacy VPN arrangements.
The solution is not automatically the right answer for every remote-work requirement. If users primarily need SaaS applications, a cloud-delivered access model may be more suitable. If access should be restricted per application rather than providing network-level reachability, ZTNA may deserve separate evaluation. FourTeck can help compare these approaches before equipment, licenses, or implementation time are committed.
Business problems a well-designed remote-access VPN can address
Uncontrolled remote entry
Instead of exposing individual services directly to the internet, the organisation can place remote access behind a FortiGate gateway and require authentication before users reach approved internal destinations. Firewall policy, routing, identity groups, and logging then become part of the access path.
Legacy SSL-VPN dependency
Businesses planning FortiOS upgrades may need to move users away from SSL-VPN tunnel mode. Fortinet replaced this tunnel mode with IPsec beginning with FortiOS 7.6.3, so migration should be tested before a firmware change interrupts established remote-working routines.
Inconsistent user configuration
Manually configured endpoints can drift over time. Where the scale and licensing justify it, FortiClient EMS can distribute remote-access profiles, manage endpoint registration and help maintain more consistent settings across supported devices.
Overly broad internal access
A VPN should not automatically mean access to the entire internal network. User groups, destination objects, firewall policies, segmentation, DNS design, and application requirements can be combined to limit remote users to the resources they actually need.
A VPN can solve a connectivity requirement, but the quality of the outcome depends on how identity, endpoint trust, routing, policy, monitoring, support, and user experience are designed around it. The objective is not simply to make a client show “connected”; it is to produce a connection that is supportable, appropriately restricted, measurable, and aligned with the organisation’s operating model.
Core capabilities to evaluate
IPsec remote access
FortiGate can act as a dial-up IPsec gateway for FortiClient and supported native clients. IKEv2 should be preferred for modern deployments, with cryptographic parameters and authentication aligned to current Fortinet guidance and organisational policy.
Multi-factor authentication
Remote access can incorporate MFA through supported Fortinet identity components and compatible identity services. The final design should confirm the exact user store, MFA method, fallback process, certificate strategy, and group mapping.
SAML and central identity
FortiOS supports SAML-based authentication for FortiClient remote-access IPsec VPNs. Microsoft Entra ID and FortiAuthenticator are documented options, while other identity providers require compatibility and configuration review.
Split or full tunnel
Split tunnelling sends selected corporate routes through the VPN while other traffic uses the local internet path. Full tunnelling can send broader traffic through the FortiGate. The decision affects security inspection, bandwidth, latency, DNS, and user experience.
Endpoint posture
With appropriate FortiClient and EMS capabilities, posture information can help determine whether a device meets conditions such as endpoint registration, operating-system state, antivirus status, encryption, or domain membership before remote access is allowed.
Monitoring and analysis
FortiGate logging records authentication and IPsec events. Organisations with broader operational requirements can evaluate FortiAnalyzer for retention, dashboards, correlation, alerting, and investigation workflows rather than relying only on local logs.
Is FortiGate Remote Access VPN the right fit?
| Requirement | Suitable when | Confirm before ordering or configuration |
|---|---|---|
| Hybrid workforce | Users need encrypted access to private applications from varied locations. | Concurrent users, device platforms, destination applications and authentication workflow. |
| SSL-VPN tunnel migration | The organisation is moving to FortiOS 7.6.3 or later. | Existing portals, routes, SAML/MFA, FortiClient profiles, DNS, policies and cutover testing. |
| Restricted networks | Travellers encounter locations where conventional IPsec traffic can be impeded. | Whether supported IPsec-over-TCP options and client versions suit the deployment. |
| Central client control | IT needs to push profiles and manage FortiClient at scale. | FortiClient edition, EMS deployment model, endpoint count and subscription term. |
| Application-specific access | VPN is needed for some workflows but not every application. | Whether ZTNA could provide a narrower model for selected apps while VPN remains for network-level needs. |
Buyer information and current platform guidance
| Topic | FortiGate remote access for individual users and endpoints |
|---|---|
| Primary tunnel method | IPsec VPN for current tunnel-based FortiOS deployments |
| SSL-VPN tunnel status | Removed from FortiOS 7.6.3 and later; migration to IPsec should be planned before upgrading from affected legacy deployments |
| Browser-based option | Agentless VPN, the current name for SSL-VPN web mode, where supported and suitable |
| Client options | FortiClient and selected native VPN clients; support and capabilities depend on operating system, client version and configuration |
| Authentication | MFA, certificates, local or remote identity services, RADIUS, LDAPS and SAML are among the design options; exact support is configuration dependent |
| IKE guidance | IKEv2 should be preferred for modern FortiClient remote-access designs |
| IPsec over TCP | Available in supported releases for environments where UDP or ESP traversal is restricted; version and configuration requirements must be confirmed |
| Central endpoint management | FortiClient EMS or FortiClient Cloud, depending on licensing and deployment requirements |
| Logging | FortiGate local logs; FortiAnalyzer can be considered for broader retention, dashboards and analysis |
| Licensing | FortiGate, FortiClient and EMS licensing should be reviewed separately because needs vary by edition, endpoint count and management model |
| Availability | Contact FourTeck for current UAE licensing, service scope, compatible FortiGate options and project coordination |
Important migration and compatibility notice
Many search results and older deployment guides still describe FortiGate SSL-VPN tunnel mode as a standard remote-access choice. That is no longer accurate for FortiOS 7.6.3 and later. Fortinet replaced SSL-VPN tunnel mode with IPsec VPN, so an organisation running older firmware should not treat a firmware upgrade as a routine change if remote users still depend on SSL-VPN tunnels. The existing authentication, address pools, DNS behaviour, split-tunnel routes, firewall policies, client profiles, certificates, SAML flow, MFA process, bookmarks and user communication plan need to be reviewed before cutover.
Agentless VPN remains a different option for selected browser-based access. It does not provide the same general network-layer tunnel experience as an IPsec client connection and can have application limitations. The right decision is therefore not “SSL versus IPsec” in the abstract; it is a workload-by-workload decision based on what remote users must reach and how those applications behave.
Compatibility also depends on the FortiGate model, firmware train, FortiClient version, operating system, identity provider, certificate infrastructure, network path and licensing. Small G-series models have had model-specific SSL-VPN limitations in some FortiOS releases, reinforcing the need to validate the exact appliance and software combination rather than assuming two FortiGate models behave identically. FourTeck can review the deployed model and release before recommending a migration path.
A practical deployment journey
Discover the requirement
Identify user populations, locations, devices, internal resources, SaaS dependencies, internet breakout policy, administrative use cases, working hours, expected concurrency and business-critical workflows. This prevents the project from becoming a generic tunnel configuration with unclear access boundaries.
Validate the platform
Confirm the FortiGate model, FortiOS version, public-facing interface, WAN design, HA arrangement, certificates, current VPN configuration, identity servers, DNS, routing and security policies. For migrations, capture the existing SSL-VPN behaviour before making changes.
Design identity and trust
Choose the identity source, MFA method, certificate use, SAML or RADIUS workflow, group mapping, device ownership rules and any endpoint-posture requirement. Consider how new starters, leavers, contractors, lost devices and emergency access will be handled.
Build policies and routes
Define address pools, route distribution, split or full tunnel, DNS, firewall policies, destination subnets, application access, internet egress, logging and security inspection. Least privilege should be intentional rather than added after users are already connected.
Pilot representative users
Test from office internet, home broadband, mobile hotspots and other realistic networks. Include Windows, macOS or mobile platforms actually in use. Validate MFA, reconnection, DNS, large-file transfers, line-of-business applications, printing only where required, and behaviour during network changes.
Roll out and operate
Publish user guidance, deploy managed profiles where applicable, monitor authentication failures, document support procedures and review access periodically. Remote access should become an operational service with ownership, not a one-time firewall change that is left untouched for years.
Authentication that fits the business identity model
Strong authentication is one of the most important controls in remote access because the gateway is intentionally reachable from outside the corporate network. Fortinet’s current best-practice guidance recommends central identity integration and MFA rather than relying only on locally created firewall accounts. That does not mean every organisation must use the same identity stack. Some businesses may integrate Microsoft Entra ID through SAML, others may use FortiAuthenticator, RADIUS or an existing directory service, while certificate authentication can add device-level assurance when deployed correctly.
The operational questions are as important as the login screen. IT should decide how groups are mapped to firewall policy, how terminated users are disabled, how contractors expire, what happens when a phone used for MFA is lost, how certificates are issued and revoked, and whether administrators require a separate policy from general staff. A design that works for ten permanent employees may not be appropriate for hundreds of users, seasonal contractors or a company with multiple identity domains.
SAML can make the remote-access experience consistent with an organisation’s existing identity provider and conditional-access processes, but the FortiGate and FortiClient versions, IKE settings, certificates and identity-provider configuration still have to match. Fortinet documentation for current FortiOS supports SAML-based authentication for FortiClient remote-access IPsec VPNs and uses IKEv2. FourTeck can help map the identity requirement before configuration starts so that the project does not discover late that the preferred client version, authentication method or certificate workflow needs additional work.
IPsec design, transport and user experience
Remote users do not all connect from clean, predictable networks. A consultant may work from a hotel, an engineer may use a mobile hotspot, and a manager may switch between Wi-Fi and cellular service. Traditional IPsec commonly uses UDP ports 500 and 4500 and can also involve ESP. Some guest networks, carrier environments or upstream security devices restrict that traffic. Current FortiOS provides IPsec-over-TCP options for supported FortiClient versions, including the ability to use a custom TCP port such as 443, which can help in restrictive environments. This capability has specific IKEv2 and client-version requirements and should be tested rather than assumed.
The tunnel model also affects performance. Full tunnelling can route internet-bound traffic through the corporate gateway, which may improve central inspection and policy consistency but also consumes WAN bandwidth and can increase latency for remote users. Split tunnelling can reduce that backhaul by sending only defined corporate destinations through the VPN, but it requires precise route and DNS planning and a clear security rationale. Neither approach is universally superior.
Questions that shape the transport choice
Will users frequently connect from networks that block or interfere with UDP? Do they move between Wi-Fi and mobile networks during active sessions? Is all internet traffic expected to pass through the FortiGate, or only corporate destinations? Are there applications that depend on source-IP location, local printers, local subnets, multicast or other behaviours that may not suit a default tunnel design?
Testing should use representative applications and network conditions, not only a successful ping. Voice, database clients, ERP, file shares, remote desktop, SSH, developer tools and web applications can expose different routing, latency or DNS issues.
Central management, posture and operational control
FortiClient can be configured locally for smaller or simpler deployments, but central management becomes increasingly valuable as the user population grows. FortiClient EMS can provision remote-access profiles and help administrators keep endpoint configuration consistent. Depending on the selected FortiClient edition and licensing, EMS can also participate in endpoint visibility and posture-based access decisions. This can reduce reliance on users entering gateway names, authentication settings and tunnel details manually.
Posture checks can add context to the access decision. Fortinet’s current guidance describes conditions such as active antivirus, current operating-system patches, disk encryption, domain membership and registration with EMS. These controls are useful when the organisation wants more assurance than a valid username and MFA token alone. They also introduce an operational dependency: IT must define what happens when a device falls out of compliance, how exceptions are handled, and whether a user can remediate the condition without losing access to the systems needed to fix it.
For FortiOS 8.0, Fortinet documents enhanced exchange of security posture tags between FortiClient and FortiOS for supported FortiClient and EMS versions. That is a good example of why version alignment matters. Buyers should not purchase a generic “VPN license” without establishing which management and posture capabilities they actually want. FourTeck can help separate basic connectivity needs from centrally managed FortiClient, ZTNA and broader endpoint-security requirements so that the bill of materials reflects the intended operating model.
Ideal business environments and use cases
Hybrid office teams
Staff need access to file services, ERP, intranet resources, internal web applications or management systems from home or while travelling. Group-based policies can separate ordinary users from finance, engineering or administrative access.
IT and support administrators
Infrastructure teams may require remote management access to internal firewalls, switches, servers, hypervisors or monitoring platforms. Their access should normally be more tightly controlled, separately grouped and logged than general employee access.
Contractors and project partners
Third-party personnel may need temporary access to a limited application or subnet. Expiry dates, dedicated groups, MFA, restricted policies and clear ownership are important so external access does not persist after the engagement ends.
Multi-site businesses with roaming users
A company may already use FortiGate at offices and branches but also have employees moving between sites, client locations and home networks. Remote-access policy can complement site-to-site VPNs rather than trying to replace them.
Remote access should be separated conceptually from site-to-site connectivity. A site-to-site tunnel connects networks or gateways, whereas remote access authenticates individual users or endpoints. The hardware sizing, identity controls and policy structure therefore require different inputs even when both functions run on the same FortiGate.
Integration and operational considerations
A remote-access VPN rarely exists in isolation. The FortiGate must route traffic to internal networks, resolve names through suitable DNS servers, authenticate users against an identity source, present trusted certificates where required, and apply firewall policies that match business roles. If the internal application is hosted behind additional firewalls, in a data centre, across SD-WAN, or in a public cloud, return routes and security policy must also recognise the remote-client address pool. Missing return routes are a common reason a VPN appears connected while the application remains unreachable.
High availability requires separate thought. If a FortiGate HA pair protects a business-critical environment, the remote-access design should be tested during WAN and firewall failover conditions. Users may reconnect rather than retain an uninterrupted session, and application behaviour can vary. Capacity planning should consider not only the number of user accounts but concurrent tunnel count, traffic profile, encryption load, security inspection, internet backhaul if full tunnelling is used, and other workloads already handled by the firewall.
Logging must be sized and retained according to operational and governance needs. Local FortiGate logs can support troubleshooting, while FortiAnalyzer may be appropriate where longer retention, dashboards, event correlation or consolidated visibility are required. Organisations should decide what the help desk needs to see when a user reports “VPN not working”: authentication result, IKE negotiation, assigned address, endpoint identity, policy hit, DNS response and destination connectivity all provide different clues.
Buyer questions to resolve before a quotation
Procurement and implementation checklist
How FourTeck can assist
FourTeck can help define the remote-access requirement before products or subscriptions are selected. That can include reviewing an existing FortiGate environment, identifying the target FortiOS release, estimating user scale, mapping authentication requirements, discussing FortiClient and EMS choices, defining IPsec tunnel policy, planning split or full tunnelling, and identifying migration work where legacy SSL-VPN tunnels are still in use.
For implementation projects, the quotation can separate supply, license or subscription items from configuration services so the buyer understands what is included. Testing scope, user migration, identity-provider changes, certificate work, documentation, knowledge transfer and post-change support should be stated explicitly rather than assumed. Where an environment contains multiple firewalls or third-party identity systems, FourTeck can help identify dependencies that may affect effort and sequence.
Useful information to send with your request
Provide the FortiGate model, serial-number status only if appropriate for support validation, current FortiOS release, user count, present VPN method, identity platform, required applications, endpoint mix, deployment location, preferred schedule and whether you need supply only, remote configuration, onsite coordination, migration or an end-to-end scope.
For related firewall options, visit Fortinet firewall solutions in Dubai or review the FourTeck firewall services.
UAE availability and support guidance
FortiGate remote-access requirements in the UAE can involve hardware, FortiClient subscriptions, FortiToken or identity components, FortiAnalyzer, professional configuration work, or a combination of these. Availability may therefore depend on the exact FortiGate model, endpoint quantity, license edition, subscription term, region, current vendor lead time and the scope of services requested. Contact FourTeck to confirm current UAE availability rather than assuming that a generic VPN package matches the deployed environment.
Delivery and project coordination can be discussed once the requirement is confirmed. If installation or configuration assistance is needed, include it in the quotation request so responsibilities are clear. For an existing FortiGate, the configuration assessment should establish whether the appliance has sufficient capacity and whether the planned FortiOS release is compatible with the intended access method. You can review broader FourTeck firewall products or contact the Dubai team with the environment details.
Dubai, Abu Dhabi, Sharjah and Ajman project coordination
Businesses across Dubai, Abu Dhabi, Sharjah and Ajman can request requirement review, quotation coordination and project planning for FortiGate remote access. The exact delivery or service arrangement depends on the solution scope, location, quantity, license requirements and implementation needs. A remote-access project may be limited to licensing and configuration guidance, or it may involve firewall sizing, identity integration, migration, endpoint rollout and testing. Sharing the deployment location and expected schedule early helps FourTeck distinguish between procurement lead time and engineering work, and ensures that any onsite requirement is discussed as part of the quotation rather than assumed after the order.
GCC Availability
Organisations planning FortiGate remote access across the GCC can ask FourTeck to review the requirement at a regional level rather than treating every location as an isolated VPN purchase. The United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain and Oman may have different procurement, delivery, licensing and project conditions, so the destination country should be confirmed together with the exact FortiGate model, endpoint quantity, FortiClient or EMS requirement, identity design and expected deployment schedule. FourTeck can assist with model and license selection, quotation coordination, configuration scope, migration planning and renewal guidance where relevant. Product availability, subscription entitlement, vendor lead time, delivery schedule, service visits and implementation scope can vary by country and project. For Kuwait-specific business enquiries, buyers can also review FourTeck Kuwait technology support. No regional stock, customs outcome or fixed installation date should be assumed until the destination and bill of materials are confirmed.
Africa Availability
For businesses, NGOs, professional-services firms and distributed organisations evaluating FortiGate remote access in Africa, FourTeck can help structure the requirement around the destination, user population, security policy and operating environment. Regional projects may involve FortiGate hardware, FortiClient licensing, endpoint management, MFA, accessories, subscriptions, configuration assistance, renewal planning or remote implementation support. Availability and fulfilment can depend on the destination country, model, quantity, license region, power or regulatory considerations, shipping arrangements, vendor lead time and local project conditions. Buyers should share the destination, exact requirement, endpoint count, preferred deployment schedule and any onsite or remote support expectation. For East African requirements, FourTeck Kenya and FourTeck Uganda provide regional contact paths. Broader enquiries can be coordinated through FourTeck without assuming local inventory, immediate shipment or country-wide onsite coverage.
Related options to consider
FortiClient VPN/ZTNA
Suitable where businesses want a managed FortiClient agent with VPN and ZTNA capabilities. Edition, endpoint count, EMS hosting model and term should be confirmed before ordering.
FortiToken and FortiAuthenticator
Identity and MFA components can strengthen remote-access authentication. The correct combination depends on the existing user directory, token preference, scale and identity architecture.
FortiAnalyzer
Considered when centralised log retention, reporting, dashboards or investigation requirements go beyond what the FortiGate itself should store and present.
Universal ZTNA or FortiSASE
Application-specific or cloud-delivered access models may fit some remote-work scenarios better than a network-level VPN. They should be compared on application coverage, user location, policy and subscription requirements.
FortiGate sizing review
If the existing firewall is being replaced or remote users are growing significantly, evaluate concurrent VPN demand together with firewall, inspection, SD-WAN and other workloads rather than sizing on VPN alone.
Why businesses contact FourTeck for remote access planning
The value of assistance is usually in requirement clarification, not in adding generic features to a quotation. FourTeck can help a buyer distinguish between the FortiGate gateway requirement, FortiClient endpoint management, identity and MFA components, logging, licensing and professional services. This is particularly useful when an existing SSL-VPN tunnel deployment must be migrated without losing SAML authentication, user-group policy, DNS behaviour or application reachability.
A structured review can also prevent overbuying. A small office with a limited number of managed endpoints may not need the same EMS architecture as a distributed enterprise. Conversely, manually maintaining many endpoint profiles may create avoidable support overhead. The right scope is based on the organisation’s operational model, not a fixed bundle. FourTeck can coordinate bill-of-material guidance, configuration scope, migration planning, quotation and current availability. For company information, visit About FourTeck Firewall Dubai.
What buyers are trying to understand before choosing a FortiGate remote-access design
One of the most common sources of confusion is whether FortiGate remote access still means SSL-VPN. Older documentation, forum answers and existing environments often use “FortiGate VPN” and “SSL-VPN” almost interchangeably. Current platform direction is different. FortiOS 7.6.3 and later no longer provide SSL-VPN tunnel mode, so businesses upgrading to those releases should plan an IPsec migration for users who previously relied on a tunnel client. Browser-based Agentless VPN remains a separate method for selected web applications, but it should not be treated as a drop-in replacement for every tunnel use case.
Is IPsec difficult for travelling users?
It can be affected by networks that restrict UDP or ESP, which is why current FortiOS includes IPsec-over-TCP capabilities for supported FortiClient versions. The practical question is whether your users encounter restrictive hotels, guest networks or carrier paths often enough to justify testing TCP transport as part of the design.
Do all users need FortiClient EMS?
Not necessarily. EMS becomes more valuable when administrators need central profile deployment, visibility, endpoint registration or posture-aware controls. A smaller deployment may use a simpler client model. The decision should be based on endpoint scale, operational consistency and security policy rather than assuming EMS is mandatory for every tunnel.
Should remote users get the whole LAN?
Usually the safer design is to map groups to the applications and subnets they require. Finance users, engineers, administrators and contractors often need different resources. FortiGate policies make those distinctions possible, but only if the access model is defined before broad allow rules are created.
Another high-value buying question concerns licensing. The FortiGate appliance, FortiClient edition, EMS hosting model, MFA components and logging platform are separate decisions. FortiClient VPN/ZTNA subscriptions are commonly sold by endpoint count and term, while some smaller use cases can have different client options. Buyers should therefore ask for a quotation based on named or managed endpoints, expected scale and the management features they actually need. A quote that simply says “FortiGate VPN license” may be too vague to compare accurately.
Capacity should also be understood in the context of the entire firewall. A FortiGate may simultaneously handle internet firewalling, IPS, application control, web filtering, SD-WAN, site-to-site VPNs, logging and remote-access encryption. The number of registered users alone does not show the real load. Concurrent sessions, traffic volume, full-tunnel internet backhaul, inspection policy, model architecture and WAN bandwidth all matter. When remote access is business-critical, high availability and WAN resilience should be discussed alongside VPN configuration rather than after deployment.
Buyers also ask whether SAML and Microsoft Entra ID can continue to be used after moving from SSL-VPN to IPsec. Current FortiOS documentation supports SAML-based authentication for FortiClient remote-access IPsec VPNs, including designs with FortiGate acting as the service provider. The exact IdP workflow, certificate handling, FortiClient version and IKEv2 settings must still be verified. A pilot with representative users is important because a successful authentication test does not automatically validate DNS, routing, application access, sleep-and-resume behaviour or network transitions.
Finally, a remote-access project should decide how support will work after rollout. Help-desk staff need enough information to distinguish incorrect credentials from MFA failure, certificate errors, IKE negotiation problems, missing routes, DNS issues, policy blocks and application-side problems. A documented support path reduces the tendency to rebuild the client profile every time a user cannot reach an application. FourTeck can include configuration documentation, testing and handover requirements in the project discussion where those services are required.
Questions that help prevent the wrong remote-access purchase
What should we confirm before upgrading a FortiGate that still uses SSL-VPN tunnel mode?
Confirm the target FortiOS release first. If the destination is 7.6.3 or later, tunnel-mode SSL-VPN must be migrated to IPsec. Inventory user groups, portals, address pools, split routes, DNS, SAML or other authentication, certificates, firewall policies and FortiClient profiles. Build and test the IPsec workflow before the production upgrade so user access is not discovered as an upgrade-day dependency.
Can we use Microsoft Entra ID with FortiGate IPsec remote access?
Current FortiOS documentation includes SAML-based remote-access IPsec designs using Microsoft Entra ID as an identity provider. The working configuration depends on FortiOS and FortiClient versions, IKEv2, certificates, SAML settings and user-group policy. Treat identity integration as part of the design and pilot rather than as an interchangeable checkbox.
When does IPsec over TCP become useful?
It is useful when users operate behind networks that permit web-style TCP traffic but block or impair conventional IPsec UDP or ESP traffic. FortiOS supports dial-up IPsec over TCP in current releases, but the feature has IKEv2 and FortiClient-version requirements. Test it against the real travel networks or restrictive environments your workforce encounters.
How do we decide between split and full tunnelling?
Start with the traffic that must be inspected and the applications users need. Full tunnel gives the organisation more control over internet egress through the FortiGate but consumes corporate bandwidth and can add latency. Split tunnel can improve efficiency for SaaS and local internet traffic but requires careful route, DNS and endpoint-security policy. The answer is driven by security architecture and user workflow, not a universal default.
Do we need a new FortiGate for more remote users?
Not automatically. First measure the existing appliance model, concurrent VPN demand, encrypted throughput, inspection workload, WAN bandwidth, CPU and memory headroom, and other services already running. If the firewall is near capacity or the new design introduces full-tunnel inspection for many users, a sizing review may indicate an upgrade. FourTeck can help compare the current platform with the expected workload.
What information produces a more accurate quotation?
Provide the exact FortiGate model, current and target FortiOS version, endpoint and concurrent-user estimates, FortiClient platforms, identity source, MFA preference, required internal applications, split/full-tunnel policy, EMS requirement, license term, migration scope and implementation expectations. That allows hardware, subscriptions and services to be quoted as separate, understandable components.
Frequently asked questions
Is FortiGate SSL-VPN tunnel mode still available in current FortiOS?
FortiOS 7.6.3 and later replace SSL-VPN tunnel mode with IPsec VPN. Organisations still using SSL-VPN tunnels should plan and test an IPsec migration before upgrading to those releases. Browser-based web mode continues separately as Agentless VPN where supported.
Can FortiClient connect to FortiGate using IPsec?
Yes. FortiClient is a documented dial-up client for FortiGate IPsec remote access. The exact profile, authentication, IKE version, transport, certificates and endpoint-management method depend on the FortiOS and FortiClient versions and the organisation’s policy.
Can MFA be used for FortiGate remote access?
Yes. Fortinet supports several identity and MFA approaches, including FortiToken, FortiAuthenticator and integrations through supported remote identity services. The correct method should be selected around the existing identity platform, user lifecycle and required assurance.
Can Microsoft Entra ID SAML be used with IPsec remote access?
Current FortiOS documentation includes SAML-based FortiClient remote-access IPsec using Microsoft Entra ID. Compatibility depends on the deployed FortiOS and FortiClient versions, IKEv2, certificates and identity-provider configuration, so the exact workflow should be validated.
What is Agentless VPN?
Agentless VPN is the current name for FortiGate SSL-VPN web mode from FortiOS 7.6.3 onward. It provides browser-based access without a tunnel client for supported applications. Because application support is more limited than a general tunnel, it should be evaluated per use case.
Do we need FortiClient EMS for every deployment?
No. EMS is valuable when central provisioning, endpoint visibility, managed profiles or posture-based controls are required, especially at larger scale. The need depends on the FortiClient edition, endpoint count and operating model rather than being automatic for every basic VPN use case.
Can IPsec run over TCP when users are behind restrictive networks?
Supported FortiOS releases can use dial-up IPsec over TCP, including configurable TCP ports, to help in environments where UDP or ESP is blocked. This option requires compatible FortiClient versions and IKEv2, so it should be validated during design and pilot testing.
How should we size a FortiGate for remote access?
Sizing should consider concurrent users, traffic per user, encryption, full- or split-tunnel routing, inspection services, WAN bandwidth, existing firewall workload, high availability and growth. A user-count figure alone is not enough to select a model reliably.
What should we send FourTeck for a quotation?
Send the FortiGate model, current and target FortiOS version, endpoint and concurrent-user estimates, endpoint operating systems, authentication and MFA requirements, FortiClient or EMS needs, applications and subnets to be reached, migration scope, deployment location and required implementation services.
Plan the remote-access design before the rollout
Share your FortiGate model, firmware, user count, authentication platform and application requirements. FourTeck can help review the migration, licensing and configuration scope and prepare a UAE quotation based on the actual environment.