FortiGate Firewall Policy Configuration in Dubai, UAE
Firewall policies decide which traffic is allowed to cross a FortiGate and what controls are applied while that traffic is processed. FourTeck helps organisations turn business access requirements into a clearer, more maintainable policy set covering interfaces, address objects, services, NAT, inspection, logging and change validation.
Representative FortiGate platform image. The exact appliance, FortiOS release and available policy features depend on the customer environment.
Direct answer: what does FortiGate firewall policy configuration involve?
A FortiGate firewall policy is a set of conditions and actions that controls traffic moving between interfaces or zones. Configuration work normally includes defining source and destination networks, permitted applications or services, schedules, NAT requirements, security inspection, authentication where needed, logging and the sequence of the rules. Businesses should consider a structured review when they are commissioning a new firewall, changing VLANs, publishing an application, connecting branches, introducing VPN access, tightening segmentation or cleaning up a rule base that has grown over time. Before any change, confirm the FortiGate model, FortiOS version, routing design, existing policies, critical applications, rollback plan and the maintenance window available for validation.
What the service does
The purpose of the service is to translate real network requirements into FortiGate policy entries that are specific enough to control access and practical enough for administrators to maintain. That may begin with an empty rule base on a new appliance, but it can also involve reviewing years of accumulated rules, consolidating duplicate objects, separating temporary access from permanent access, correcting broad policies and documenting why each important rule exists.
Policy configuration is not limited to an “allow” or “deny” decision. A rule can also determine whether source NAT is used, which security profiles inspect traffic, whether identity is involved, what is logged, how encrypted sessions are inspected and which source and destination interfaces are valid. The final configuration therefore needs to reflect routing, VLANs, VPN interfaces, public services, address objects, FortiGuard subscriptions and operational monitoring.
Who should consider it
The service can be relevant to SMEs, multi-branch organisations, schools, clinics, hotels, warehouses, professional offices, retail environments, data-centre teams and larger enterprises using FortiGate at the internet edge or for internal segmentation. It is particularly useful when an IT team knows which systems must communicate but wants assistance turning that requirement into a maintainable policy structure.
It can also help organisations inheriting an existing FortiGate from a previous administrator, moving to new WAN links, creating additional VLANs, changing remote-access or site-to-site VPN design, introducing new servers, tightening guest Wi-Fi access or preparing for an audit. The exact engagement depends on whether the customer needs advice, implementation, cleanup, troubleshooting, documentation or a controlled change with pre- and post-change testing.
Business problems a clearer policy design can address
Rules have become too broad
Policies using wide address ranges, large service groups or loosely defined interfaces may allow more traffic than the business actually requires. The configuration review can break access into understandable paths and use more specific objects where appropriate.
Changes keep breaking applications
A rule that looks simple can depend on routing, NAT, DNS, certificates, authentication, VIPs or upstream systems. Mapping the full traffic path before editing reduces avoidable surprises and gives the change team a practical test list.
Troubleshooting takes too long
Clear names, sensible address groups, documented intent and appropriate logging help administrators work out which policy should match a session and why a connection is allowed or blocked.
Segmentation is inconsistent
When users, servers, voice, CCTV, printers, guest networks and management systems share a site, policy design can define which network segments may communicate and which flows should remain separated.
Security profiles are applied without a plan
Inspection profiles should fit the traffic and available licensing. Applying every profile to every rule can create unnecessary overhead, while applying too little inspection may not meet the intended control objective.
Temporary rules became permanent
Project, vendor and troubleshooting access often survives long after the original task. A review can identify rules whose business owner, purpose or expiry is unclear and place them into a decision process rather than deleting them blindly.
Core configuration areas
Define where traffic enters and leaves so the rule reflects the actual topology rather than an abstract source-to-destination statement.
Use host, subnet, FQDN, group or identity-based references where supported and appropriate to the design.
Permit the protocols and ports the business process needs instead of relying on unrestricted service definitions where avoidable.
Review outbound source translation, IP pools, virtual IPs, destination translation and central NAT dependencies according to the active FortiOS configuration.
Apply suitable antivirus, IPS, application control, DNS, web filtering or other profiles where the subscription and traffic use case require them.
Collect the events needed for troubleshooting and review, then test critical business flows after configuration changes.
Service-fit matrix
| Business situation | Relevant assistance | Scope dependency |
|---|---|---|
| New FortiGate deployment | Rule structure, objects, NAT, profiles, logging and acceptance testing | Model, FortiOS, VLANs, WAN design, subscriptions and applications |
| Existing rule-base cleanup | Policy inventory, naming review, duplicates, unused candidates and owner validation | Change history, logging evidence, application ownership and risk tolerance |
| New VLAN or network segment | Inter-VLAN policy, least-required services, DHCP/DNS dependencies and testing | Routing location, gateway design, server dependencies and user roles |
| Published server or application | VIP/DNAT review, inbound rule, service restriction and inspection planning | Public IPs, server ports, certificates, upstream routing and application design |
| VPN access change | VPN-interface policy, user/group restrictions, destination access and logs | VPN type, identity source, route design, client version and business need |
| Policy troubleshooting | Expected rule match, route/NAT checks, session review, packet capture planning | Reproducible traffic flow, timestamps, source/destination and access availability |
Service information and scope guidance
| Topic | FortiGate Firewall Policy Configuration |
|---|---|
| Main purpose | Plan, implement, review or troubleshoot traffic-control policies on FortiGate |
| Suitable environments | Office, branch, campus, warehouse, hospitality, retail, education, healthcare, data-centre and hybrid networks |
| Assessment support | Available according to agreed scope and customer-provided configuration details |
| Planning support | Traffic-flow mapping, policy grouping, object naming, rule order, change and rollback planning |
| Configuration support | Configuration dependent; can include policies, NAT, profiles, logging and related objects |
| Integration considerations | Routing, VPN, FortiManager, FortiAnalyzer, FortiSwitch, FortiAP, identity, DNS, servers and third-party systems |
| Licensing guidance | Security-profile availability can depend on FortiGuard subscriptions and the installed FortiOS release |
| Remote or on-site coordination | Project dependent; confirm access method, site requirements and maintenance window |
| UAE availability guidance | Contact FourTeck to confirm current service availability and scheduling |
| Important note | No policy should be changed solely from a generic template; the intended business flow and existing environment must be validated first. |
Dependencies that should be confirmed before configuration
FortiGate policy behaviour is tied to the wider configuration. The same rule idea can require a different implementation depending on whether interfaces are physical ports, VLANs, zones, IPsec tunnels, SD-WAN zones or other logical interfaces. NAT can be configured in different ways, including policy-based source translation and central NAT designs. Published services can depend on virtual IPs or other destination-translation settings. Identity-aware rules need working authentication. Security profiles can rely on active subscriptions and may behave differently according to inspection mode and FortiOS capabilities.
Encrypted traffic deserves particular planning. Certificate inspection and deeper SSL inspection serve different purposes and can have different certificate, privacy, application-compatibility and performance implications. Some applications use certificate pinning or other behaviours that may require exclusions or alternative treatment. For that reason, the service scope should identify what traffic will be inspected, what certificates are available, which user groups are affected and how exceptions will be approved. The correct approach is configuration dependent rather than a single profile copied across every policy.
A controlled configuration journey
Identify source, destination, protocol, business owner, frequency, criticality and whether the traffic is inbound, outbound, inter-VLAN, VPN or management related.
Confirm interfaces, zones, routes, public addresses, VLAN gateways, upstream and downstream devices, VPN interfaces and any SD-WAN dependencies.
Create or rationalise address, service and group objects using naming that gives future administrators useful context.
Choose source and destination interfaces, objects, services, action, NAT, security profiles, logging and sequence according to the requirement.
Back up the configuration, agree the maintenance window, record rollback conditions and apply the approved change using appropriate administrator access.
Test expected traffic, confirm unexpected access is not introduced, inspect logs and update change records, diagrams or policy documentation as agreed.
Capability focus: precise rule matching instead of broad access
A manageable firewall starts with rules that describe real traffic. On FortiGate, policy conditions can include incoming and outgoing interfaces, sources, destinations, services, schedules and other controls. The design should make it possible for an administrator to look at a policy and understand which business flow it represents. Rules that use “any” everywhere may be quick to create, but they reduce that clarity and can make later troubleshooting, audits and access reviews more difficult.
Granularity does not mean creating thousands of tiny rules without reason. Excessive fragmentation can make a rule base difficult to operate. A sensible balance groups flows that share the same trust level, source community, destination purpose, service requirement and inspection treatment. For example, employee browsing to the internet may be handled differently from server updates, guest Wi-Fi, backup traffic, VoIP, database access or vendor remote support because each flow has a different risk and operational profile.
FourTeck can help customers identify where a broad rule is justified, where it should be narrowed and where a group should be separated for better logging or security control. Any cleanup activity should be based on evidence and business-owner confirmation. A policy with few hits is not automatically safe to delete; it may support a quarterly process, disaster-recovery path, vendor maintenance task or low-frequency application that remains important.
Capability focus: security profiles matched to the traffic
FortiGate policies can carry security inspection profiles for functions such as antivirus, intrusion prevention, application control, web filtering and DNS filtering, depending on the device configuration and active subscriptions. These controls are most useful when the policy is designed around a known traffic type. An internet browsing policy for office users may require a different combination of profiles from a site-to-site replication rule, a printer VLAN, a public web service or a management network.
Inspection also affects performance and compatibility. Encrypted sessions need an SSL inspection strategy if the organisation expects security engines to examine more than the outer certificate or handshake information. Deep inspection can provide greater visibility into HTTPS content, but it introduces certificate-distribution, privacy, application-support and processing considerations. It should therefore be planned with endpoint management, application owners and organisational policy rather than enabled indiscriminately.
A configuration engagement can review which rules currently have profiles, which subscriptions are available, whether inspection mode is appropriate and whether logs provide enough evidence that the intended control is working. The aim is not to enable the greatest number of features. The aim is to apply relevant controls to the traffic that needs them while maintaining a supportable design.
Capability focus: NAT, publishing and routing-aware policy design
Many policy problems are actually traffic-path problems. A FortiGate can permit a session correctly, yet the connection may still fail because the route points elsewhere, the return path is asymmetric, the source address is translated differently from what a remote system expects, or a public service is mapped to the wrong internal destination. NAT should therefore be reviewed together with policy and routing rather than treated as an isolated checkbox.
Outbound internet access may use the outgoing interface address or an IP pool, depending on the requirement. Inbound services may use virtual IP objects or central destination NAT features according to the FortiOS design. Environments using central SNAT have a separate translation table, which changes how an administrator should read the policy and diagnose the translated source. Hairpin or loopback scenarios introduce another path where internal users reach a service through a public address. Each design needs its own validation.
For a configuration request, provide public and private addresses, ISP details, expected source addresses, server locations, required ports and any third-party allow lists. This information allows the policy and NAT behaviour to be checked together. If routing is dynamic, include the relevant BGP or OSPF context. If SD-WAN is involved, identify the zone, health checks and path-selection expectations so a firewall rule is not blamed for a routing decision made elsewhere.
Typical business environments and use cases
Office internet edge
Separate staff, guest, server and management access; apply internet security profiles; control outbound services; and maintain usable logs for troubleshooting.
Multi-VLAN segmentation
Define controlled paths between users, servers, voice, CCTV, printers, wireless networks, building systems and administrative networks.
Branch connectivity
Permit only the traffic required between branches and central systems while keeping local internet access, SD-WAN and VPN policy understandable.
Public applications
Control inbound access to published web, mail, VPN or business services with suitable destination translation, service restriction and inspection.
Vendor and partner access
Create narrowly scoped access paths with identifiable source, destination, service, duration and ownership instead of long-lived unrestricted exceptions.
Migration and firewall replacement
Review inherited policies before moving them to another FortiGate so obsolete objects and accidental broad access are not carried forward without question.
Integration and operational considerations
Firewall policy is one layer in the network path. A change can interact with core switching, static or dynamic routing, DNS, DHCP, identity services, endpoint certificates, FortiSwitch, FortiAP, FortiManager, FortiAnalyzer, cloud services, VPN peers, ISP routers and application-side access controls. For that reason, policy troubleshooting should start with a defined five-tuple or application flow: source, destination, protocol or service, direction and expected result. Without that information, an administrator can spend time editing the wrong layer.
Central management adds another dependency. If policies are controlled by FortiManager, local changes may be overwritten or may not follow the organisation’s approval workflow. The engagement should establish which system is authoritative before any edits are made. Logging is similar: FortiGate may store logs locally, forward them to FortiAnalyzer, send them to syslog or use a cloud service depending on the environment. The logging plan should support operational needs without assuming that every traffic event must be retained indefinitely.
High-availability pairs require change awareness as well. Administrators should know cluster health, configuration synchronisation, management method and failover considerations before applying production changes. Where the firewall is part of a critical transaction path, the change plan should identify business owners who can validate applications after implementation rather than relying only on network-level ping tests.
Questions to resolve before changing a policy
Document the source, destination, service, direction and expected result. “Allow the ERP” is not enough if the ERP depends on DNS, database, authentication, update and reporting connections.
Confirm VLAN gateways, tunnels, zones and routes so the rule is written for the actual ingress and egress interfaces.
Identify whether the remote system expects the interface IP, an IP pool, a fixed public address or no translation at all.
Decide whether security profiles and SSL inspection are required, supported and compatible with the application.
Create practical checks for both permitted and blocked traffic, including application-level testing when the service is important.
Define when to revert the change if unexpected failures occur and confirm that a usable configuration backup exists.
Procurement and configuration checklist
☐ Exact FortiGate model and FortiOS version
☐ Number of firewalls and HA status
☐ Current topology or network diagram
☐ WAN, VLAN, VPN and zone details
☐ Source and destination networks
☐ Required ports, protocols and applications
☐ NAT or public-service publishing requirements
☐ Security profiles and subscription status
☐ Authentication or identity dependencies
☐ Logging and reporting destination
☐ Change window and downtime tolerance
☐ Testing and rollback expectations
☐ Documentation or handover requirement
☐ Remote or on-site coordination requirement
FourTeck consultation and configuration support
FourTeck can support the planning and implementation conversation from the point where a business states the required access through to a scoped configuration change. The first step is usually requirement clarification: what must communicate, what should be blocked, which users or systems are involved, where the traffic enters and exits, and what security or operational controls apply. This helps separate a policy problem from a routing, VPN, application or infrastructure problem before changes begin.
For existing FortiGate environments, the review can include policy names, rule order, objects, service groups, NAT behaviour, security profiles and logging according to the agreed service scope. Where a rule base contains old or unclear entries, FourTeck can help organise a review list for customer approval. The customer remains an important part of that process because only the business can confirm whether an infrequently used connection is obsolete or critical.
Customers planning a broader firewall project can also review FourTeck firewall products, network security services and the Fortinet firewall planning reference. A quotation can separate advisory work, configuration tasks, implementation coordination, documentation and any hardware or licensing requirement so the buyer understands what is included.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for FortiGate firewall policy configuration assistance. Service scheduling depends on the number of devices, FortiOS versions, policy count, topology complexity, the customer’s access method, whether changes are advisory or hands-on, and the maintenance window required. A small standalone office with a few rules can have a very different scope from a multi-site organisation using high availability, SD-WAN, FortiManager, complex NAT and many VPN peers.
For Dubai, Abu Dhabi, Sharjah and Ajman projects, provide the firewall location, remote-access possibility, site contact, required change window and any need for on-site coordination. Installation or configuration work should be included in the quotation when required rather than assumed to be part of a product purchase. Customers can use the FourTeck contact page to share non-sensitive project details and request a scoped response.
GCC Availability
Organisations operating across the GCC often want firewall policy standards that can be repeated across multiple branches while still allowing local differences for WAN circuits, address ranges, applications and regulatory requirements. FourTeck can assist with requirement review, policy design discussions, configuration scope, rollout planning, troubleshooting and quotation coordination for projects that may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman. The practical starting point is to define whether the requirement is one firewall, a standard branch template, a policy cleanup exercise or a broader Fortinet deployment.
Availability, licensing, project visits, remote-access arrangements and delivery schedules can vary by country, firewall model, quantity and local requirement. Buyers should provide the destination country, FortiGate model, FortiOS version, number of sites, desired policy changes, preferred support method and expected timeline. If hardware, subscriptions or other Fortinet components are also required, those items should be quoted separately with current regional availability confirmed. Customers with Kuwait requirements can also review FourTeck Kuwait technology support as part of regional planning.
Africa Availability
Businesses with offices or projects in Africa may need FortiGate policy assistance for new branches, standardised access controls, VPN connectivity, firewall replacement, troubleshooting or rule-base review. FourTeck can help organisations prepare the technical information needed to evaluate the configuration task, including the installed model, software version, current policies, WAN design, local network ranges, business applications, security subscriptions and any remote-management platform. This can be useful for regional IT teams coordinating sites from a central office while local staff handle cabling, ISP access or physical tasks.
Service and fulfilment conditions depend on destination, firewall model, project scope, remote-access method, local network readiness, licensing region, travel needs and vendor lead time where products or subscriptions are included. Share the destination country, number of firewalls, intended schedule and support expectations before assuming a delivery or on-site date. For East African requirements, buyers may also review FourTeck Kenya and the broader FourTeck Africa reference for regional technology planning.
What buyers usually need to understand before a FortiGate policy change
A frequent question is whether a FortiGate firewall policy is simply a port-opening rule. In practice, it is a traffic decision that sits inside a larger network design. The rule identifies the direction of traffic and the networks or systems involved, but the session may also depend on routing, NAT, authentication, security inspection, application behaviour and logging. That is why a policy request should be written as a business flow rather than as “open port 443.” Port 443 can represent user web browsing, an internal application, a VPN portal, a published web server or a management interface, and each case may require a different rule path and security treatment.
Why does policy order matter?
Firewall rules are evaluated according to the platform’s matching logic, so a broad rule can capture traffic before a more specific rule has the opportunity to apply. Administrators should review sequence when adding exceptions, tightening access or introducing a new inspection profile. The best place for a rule depends on its conditions and purpose, not on a universal numeric position.
Should every rule use deep SSL inspection?
No. Deep inspection is a design choice that depends on the traffic, risk, certificate deployment, privacy requirements, application compatibility, appliance capacity and organisational policy. Some flows may use certificate inspection, some may require deeper inspection and some may need carefully justified exceptions. The configuration should reflect the intended control rather than apply one profile indiscriminately.
Is an allow-any policy acceptable temporarily?
Temporary broad access can make troubleshooting easier in a lab, but it should not become the default production design. If broad access is needed for a controlled test, document the owner, reason, expiry, logging and rollback plan. Once the required traffic is understood, replace the temporary rule with a narrower policy that reflects the real application path.
Why can a new rule still fail to pass traffic?
The session may be using another interface, missing a route, hitting an earlier rule, being translated unexpectedly, failing on the server, blocked by an endpoint firewall or returning through another path. Troubleshooting should compare the expected session with the actual route, policy match, NAT result and application response instead of repeatedly changing the firewall rule without evidence.
Another common buyer concern is whether policy cleanup automatically improves security. Cleanup can improve clarity and reduce unnecessary access, but only when it is performed with context. Deleting a rule because it has not matched recently can disrupt seasonal systems, emergency access, low-frequency backups or vendor support. A safer review uses hit data where available, change history, object references, application ownership and a defined observation period. The business owner should confirm whether the traffic is still required before an important rule is retired.
Customers also ask whether FortiGate configuration can be standardised across branches. A common template can be valuable when sites have similar VLANs, business applications, security profiles and naming conventions. However, IP addressing, ISP circuits, local printers, voice platforms, CCTV systems, payment devices, public services and local partner links often create exceptions. Standardisation works best when the organisation defines a core policy baseline and then records site-specific deviations rather than trying to make every branch identical.
For quotation planning, the number of rules is only one part of the effort. A firewall with 40 well-documented rules may be easier to review than one with 15 rules that rely on nested groups, multiple VPNs, central NAT, undocumented VIPs and unclear ownership. Useful scoping inputs include the firewall count, HA design, FortiOS version, number of sites, policy count, object count, VPNs, NAT design, central management, desired changes, testing requirements and whether the customer expects configuration documentation.
The most useful outcome is a policy set that another qualified administrator can understand months later. Names should explain purpose, objects should be reusable without becoming overly broad, logs should support troubleshooting, and change records should state why an access path exists. FourTeck can help structure that process for organisations that need an initial configuration, a targeted change, a rule-base review or a wider Fortinet project in the UAE.
Practical questions that shape the right configuration
How specific should a firewall rule be?
It should be specific enough to represent an approved business flow without becoming so fragmented that normal administration becomes difficult. Start with the real source community, destination purpose and required service. If different traffic needs different inspection, logging, schedules or ownership, separate it. If several flows share the same security treatment and business context, a well-designed group may be more maintainable.
Can the existing rules be copied to a replacement FortiGate?
They may be migrated or converted, but that does not remove the need for review. Interface names, switch modes, NAT, certificates, VPNs, authentication, central management and FortiOS features can differ. A migration is also an opportunity to identify obsolete objects and temporary exceptions, provided cleanup is separated from cutover risk and approved by the customer.
What information is needed to troubleshoot a blocked connection?
Provide a timestamp, source IP, destination IP or name, destination port or application, expected interface path and whether the failure is consistent. It also helps to know whether the connection worked previously, whether NAT is expected and whether the destination is internal, internet-based, reached through VPN or published through a virtual IP.
When should a rule use logging?
Logging should be sufficient for troubleshooting, security monitoring, audit and operational needs without creating unnecessary volume. Critical access, blocked attempts, public services and security-profile events commonly need visibility, but the exact setting depends on retention, FortiAnalyzer or other log destinations, disk capacity and the organisation’s monitoring process.
How should temporary vendor access be handled?
Use identifiable source, destination and service conditions where possible, record the responsible business owner, define the approved time window and remove or disable the access when the task ends. If the source address cannot be fixed, consider whether a VPN or authenticated access method is more appropriate than exposing a broad inbound rule.
What should be tested after a firewall policy change?
Test the intended application, not only basic connectivity. Confirm the permitted source can reach the correct destination on the expected service, the return path works, required security inspection is active and logs appear where expected. Where the change tightens access, also test that unauthorised sources or services remain blocked.
Related FourTeck options
FortiGate firewall selection
Useful when the policy project is part of a new deployment or replacement and the appliance must be sized around inspected traffic, interfaces and growth.
Firewall migration planning
Relevant when rules must move from an older FortiGate or another firewall platform and require interface, NAT, object and service validation.
Fortinet UAE support topics
Useful for organisations that also need VPN, renewal, replacement or wider Fortinet deployment planning.
Business technology consultation
Suitable when firewall policy depends on switches, wireless, servers, cloud connectivity or a wider infrastructure redesign.
Why businesses contact FourTeck for policy work
The value of configuration assistance is not a generic promise that every network will become secure after one change. It is the ability to organise the requirement, identify the dependencies, plan the rule correctly, keep the customer involved in decisions and validate the result against the intended business traffic. This is especially useful when a rule touches systems owned by different teams or when the firewall has accumulated years of undocumented changes.
FourTeck can assist with requirement clarification, configuration review, policy naming, object organisation, NAT planning, security-profile alignment, troubleshooting, migration discussion, quotation coordination and implementation planning according to the agreed scope. Customers should provide accurate topology and application information and should avoid sending passwords or sensitive configuration archives through unsecured public channels. Where engineering access is required, the project can define an appropriate secure method.
Frequently asked questions
What is a FortiGate firewall policy?
It is a rule that controls traffic crossing the FortiGate according to conditions such as interfaces, source, destination, service, schedule and other settings. The rule can also apply NAT, security profiles, authentication and logging depending on the design.
Can FourTeck configure policies on an existing FortiGate?
Yes, subject to an agreed service scope, supported access method and review of the current FortiGate model, FortiOS version, topology and change requirements. The quotation should state whether the work is advisory, remote configuration, on-site coordination or a combination.
Do firewall policies require a FortiGuard subscription?
Basic traffic-control policies do not mean every subscription is required, but security services such as web filtering, antivirus, IPS and other FortiGuard functions can depend on active entitlements. The exact requirement should be checked against the profiles the customer wants to use.
Can a policy be created without using NAT?
Yes. NAT is used only where the traffic design requires address translation. Internal routing, some VPN flows and other scenarios may not need source translation. The correct setting depends on the route, remote network and expected source address.
How do you decide the order of FortiGate rules?
Rule sequence should ensure the intended specific traffic is matched by the correct policy before a broader policy can capture it. The design must be reviewed as a whole because the correct position depends on interfaces, objects, services and the existing rule base.
Can old firewall rules be deleted during a cleanup?
They can be retired after evidence and business-owner review indicate they are no longer required. A low hit count alone is not enough to prove a rule is obsolete because some traffic is infrequent but still important.
Does FortiGate policy configuration include SSL inspection?
It can, if SSL inspection is part of the agreed scope. The appropriate profile depends on the traffic, endpoint certificates, privacy requirements, application compatibility, FortiOS features and appliance capacity.
What should I send for a configuration quotation?
Send the FortiGate model, FortiOS version, firewall count, site location, network diagram where available, the traffic flows to add or change, current policy count, VPN and NAT context, preferred change window and whether documentation or on-site work is required.
Is policy configuration available for multi-branch networks?
Yes, but multi-branch projects should define whether the goal is a standard template, central FortiManager policy, individual site changes or a wider SD-WAN and VPN redesign. Scope and availability depend on the number of sites and configuration complexity.
Prepare the traffic requirement before you change the firewall
Share the FortiGate model, FortiOS version, network path, source, destination, required service, NAT expectation and preferred change window. FourTeck can review the requirement and prepare an appropriate configuration or consultation scope for your UAE environment.