Skip to content

Teknotel Edge Firewall (FortiGate 3200F) – Policy Overview

This page documents the FortiGate 3200F used at Teknotel and provides a human-readable intent for the currently exported policy set.

Baseline security principle: explicit allow-list + default deny.

In practice: everything is blocked unless a policy explicitly permits it (FortiGate implicit deny).

What FortiGate 3200F does (short)

FortiGate 3200F is an enterprise / data-center class next‑generation firewall (NGFW). In a typical deployment it provides:

  • Stateful firewalling (L3/L4 rules) and segmentation between zones (LAN/WAN/VPN).
  • Application-aware policies and security services (IPS, anti-malware, web filtering, etc.) when enabled via security profiles.
  • SSL/TLS inspection options (e.g., certificate inspection vs deep inspection) depending on policy requirements.
  • VPN termination (site-to-site IPsec, remote access) and policy-based routing patterns.
  • NAT (source NAT) for outbound internet access where private IP ranges need translation.
  • Logging & observability (traffic logs + security logs) and integration with centralized management / analyzers.

How to read a policy (field cheat-sheet)

  • Interface Pair: traffic direction (e.g., Smartface-Lan → Smartface-Wan means outbound to internet; Smartface-Wan → Smartface-Lan means inbound from internet).
  • Source / Destination: address objects (single host IPs, subnets, groups).
  • Service: allowed L4 services/ports (e.g., SSH, HTTPS, ALL).
  • Action: ACCEPT or DENY.

  • NAT / IP Pool:

  • NAT: source NAT is applied (typical outbound internet pattern for private subnets).

  • Disabled: no address translation (common for routed public IPs and VPN traffic).

  • Security Profiles:

  • no-inspection: traffic is allowed without UTM/IPS scanning.

  • certificate-inspection: basic TLS certificate checks (not full decryption).

  • Log:

  • All: logs all sessions/traffic.

  • UTM: logs security/UTM events (and usually traffic).
  • Disabled: no traffic logs for this rule.

Policy set summary

High-level intent

  • East–West (LAN→LAN) traffic is allowed broadly.
  • Outbound internet is allowed for multiple runner groups.
  • Two site-to-site VPNs exist (Anadolu and TOGG) and include bidirectional-looking rules.
  • Inbound remote access from WAN to specific internal hosts is enabled (SSH/VNC).
  • A final default deny exists (implicit).

Runner IP blocks and NAT rationale (operational context)

Appcircle runners are split into two public IP blocks:

  • Cloud_runners_1st
  • Cloud_runners_2nd

For customers requesting site-to-site VPN, we typically need to provide both:

  • Internal IP ranges (what is reachable over the VPN), and
  • A stable egress/source IP that customers can allow-list.

Some customer security teams expect a clear separation between “internal” and “external” source identities. If we provide only a single IP identity, they may flag/deny traffic with “this IP should be internal, why is it coming from outside?”.

To support a two-IP approach, we use SNAT (NAT) for runner egress where applicable. This allows us to present a predictable firewall/NAT source IP to customers while keeping runner addressing consistent internally.

When a new runner is added, firewall objects/policies must be updated (address groups / ranges and any relevant allow rules) so the runner can successfully reach outbound destinations and customer networks.

Important note on VPN → LAN policies (potential misunderstanding)

The following policies are intended to open customer-initiated traffic into our LAN:

  • appc_to_togg → Smartface-Lan (policy vpn_to_local (11))
  • appc_to_anadolu → Smartface-Lan (policy vpnanadolu_to_local (15))

However, in our real-world usage the connection is usually initiated by our runners towards the customer side (outbound), rather than customers initiating inbound connections into our LAN.

Assessment: We suspect these inbound VPN→LAN policies were enabled due to a misunderstanding by Teknotel, and may be unnecessary.

Supporting signal: In the export, both rules show 0 B traffic, which may indicate they are currently unused (needs operational confirmation).

Action item: Re-validate with the owning team and customer requirements; if not needed, consider disabling or tightening these rules to reduce attack surface.

Policies (intent per rule)

The “Operator notes” sections are intentionally left as placeholders so you can attach real-world context, ticket links, owners, and change history.

1) Internal LAN (east–west)

lan-to-lan (17)

  • Direction: Smartface-Lan → Smartface-Lan
  • Allow: ALL services, all → all, always.
  • Intent: Permit intra-LAN traffic without NAT.
  • Logging: enabled (All).

  • Operator notes:

  • Owner:

  • Rationale:

2) Outbound internet access (egress)

L2internet-private-1st (1)

  • Direction: Smartface-Lan → Smartface-Wan
  • Source: PCloud_runners_1st → Destination: all
  • Allow: ALL services, always.
  • NAT: Enabled.
  • Intent: Provide internet egress for Private Cloud runners (1st).
  • Logging: enabled (All).

  • Operator notes:

  • Owner:

  • Expected destinations (if any allow-list exists):

L2internet-private-2nd (13)

  • Same as above for PCloud_runners_2nd.
  • Intent: Internet egress for Private Cloud runners (2nd).

L2internet-cloud-2nd (16)

  • Direction: Smartface-Lan → Smartface-Wan
  • Source: Cloud_runners_2nd → Destination: all
  • NAT: Disabled.
  • Intent: Internet egress for Cloud runners (2nd) without NAT.
  • Operational note: When new runners are added to this block, ensure the Cloud_runners_2nd address object/group stays up to date so outbound access continues to work.

L2internet-cloud-1st (3)

  • Direction: Smartface-Lan → Smartface-Wan
  • Source: Cloud_runners_1st → Destination: all
  • NAT: Disabled.
  • Intent: Internet egress for the Cloud runner block (1st).
  • Operational note: When new runners are added to this block, ensure the Cloud_runners_1st address object/group stays up to date so outbound access continues to work.

3) Site-to-site VPN (Anadolu)

local_to_anadoluvpn (14)

  • Direction: Smartface-Lan → appc_to_anadolu
  • Source: appc_to_anadolu_local_subnet_1
  • Destination: appcircle_anadolu_ipsec_remote_group
  • Allow: ALL services.
  • NAT: Disabled.
  • Intent: Allow local subnet → Anadolu remote networks over the Anadolu IPsec tunnel.

4) Site-to-site VPN (TOGG)

local_to_vpn (10)

  • Direction: Smartface-Lan → appc_to_togg
  • Source: local_to_togg_ip_range
  • Destination: local_to_togg_remote_ip
  • Allow: ALL services.
  • Intent: Allow local → TOGG remote IP ranges over the TOGG IPsec tunnel.

5) Inbound remote access from WAN (admin / ops)

Wan-to-lan-remote-access-1 (5)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: AC-task-operator
  • Destination: AC-macOS-build
  • Allow: SSH, VNC.
  • Intent: Allow the Task Operator jump host (Google Cloud VM) to access the macOS build machine for runner deployment/maintenance operations. DevOps personnel may also use the same jump path when needed.
  • Logging: Disabled.

Wan-to-lan-remote-access-2 (6)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: AC-jenkins-pipeline, AC-task-operator
  • Destination: AC-test-reports
  • Allow: SSH.
  • Intent: Allow Jenkins pipeline and Task Operator to SSH into AC-test-reports for automated testing and related operational actions.
  • Logging: Disabled.

Wan-to-lan-remote-access-3 (7)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: AC-jenkins-pipeline
  • Destination: 77.92.124.22-host, 77.92.124.8-host
  • Allow: SSH.
  • Intent: Allow Jenkins pipeline to SSH into the prep hosts (77.92.124.22, 77.92.124.8) used for prep-stage operations.
  • Logging: Disabled.

Ops for Private Cloud Runners (20)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: AC-task-operator
  • Destination: PCloud_runners_1st, PCloud_runners_2nd
  • Allow: SSH.
  • Intent: Ops remote access to private cloud runners for maintenance.
  • Logging: UTM.

6) Public / external entry points

Wan-to-test-reports (8)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: all
  • Destination: AC-test-reports
  • Allow: HTTP, HTTPS, multiple *ssh services, plus SMTP/SMTPS variants.
  • Security profile: certificate-inspection.
  • Intent: Public access to AC-test-reports over web (HTTP/HTTPS). The multiple SSH service entries exist to support repository cloning via different Git provider SSH endpoints (provider-specific port/service definitions). SMTP/SMTPS entries support related mail flows (e.g., notifications or report delivery), depending on how the service is used.
  • Logging: Disabled.

Nginx-Proxy-Ext (18)

  • Direction: Smartface-Wan → Smartface-Lan
  • Source: gc-k8s-prod, ovh-runner-prod
  • Destination: AC-nginx-proxy
  • Allow: Custom-SSH, HTTPS.
  • Intent: Enable connectivity between Google Cloud (gc-k8s-prod) and OVH runner production (ovh-runner-prod) towards the internal AC-nginx-proxy (HTTPS and a custom SSH/ops port).
  • Customer context: This rule is in place for the Tüpraş hybrid setup (external access via reverse proxy to reach customer-internal systems).
  • Logging: UTM.

7) Default deny

implicit_deny (0)

  • Interface Pair: Implicit
  • Action: DENY for all → all, ALL services, always.
  • Intent: Make the default deny posture explicit: any traffic not matching a prior allow rule is blocked.
  • Logging: enabled (All).

Optional hardening checklist (during cleanup)

  • Replace Service: ALL with minimal ports where feasible.
  • Replace Source/Destination: all with explicit objects.

  • Ensure inbound rules (WAN → LAN) are:

  • protected by MFA / bastion / VPN,

  • logged,
  • and (where appropriate) inspected.

  • Document each exception with:

  • Owner

  • Ticket / change request
  • Expiration date (if temporary)
  • Validation steps