The workload is untouched; the Cloud NGFW policy is enforced on the subnet in the VPC fabric, so there is no separate appliance the traffic passes through.
#### Architecture Network Firewall spreads its configuration across a firewall, its policy, and the rule groups the policy references. Cloud NGFW collapses that into one network firewall policy holding a flat list of policy rules. The build emits the policy and one **policy rule per translated rule**; the rule groups do not survive as a grouping layer, so a stateful rule group of ten rules becomes ten policy rules. Each policy rule has an integer **priority**, an **action** of allow or deny, a **direction** of ingress or egress, and a match. The priority is the evaluation order, and the build assigns a deterministic priority per rule so the sequence is stable across rebuilds. The policy is **associated with the VPC networks** it governs rather than placed in a route; that association, and the choice of which networks to govern, is a property of the customer's project.
One policy, a flat list of priority-ordered rules, associated with the VPC networks it governs: each AWS rule becomes exactly one policy rule, and the priority is the evaluation order.
#### How the rule groups map The policy's rule groups translate by kind, each rule becoming one policy rule. A stateful rule group of 5-tuple rules becomes a set of **ingress** policy rules: each rule keeps its protocol, its source and destination IP ranges, and its ports in an L4 match, and its AWS action sets the policy-rule action (pass or alert becomes allow, drop or reject becomes deny). A rule group built from a domain list becomes **egress** policy rules that match on destination FQDNs, with allow or deny taken from whether the list is an allowlist or a denylist. A rule group written as raw Suricata signatures has no policy-rule form. Cloud NGFW runs signature-based intrusion prevention through security profiles, which is a distinct capability rather than an allow/deny rule, so the build surfaces those signatures for the operator to enable through a security profile instead of discarding them. >The allow/deny rules that make up most policies translate directly. \>
The allow/deny rule groups translate onto policy rules one for one; a Suricata signature group has no policy-rule form and points at Cloud NGFW's security profiles instead.
#### Stateful 5-tuple rules A stateful rule in Network Firewall matches on the 5-tuple: protocol, source address, destination address, source port, and destination port, with an action of pass, drop, or alert. A Cloud NGFW policy rule matches on source and destination IP ranges plus an L4 configuration of protocol and ports, so each rule translates onto one policy rule. TCP, UDP, and ICMP map to themselves; an AWS `ANY` address becomes `0.0.0.0/0`, and an `ANY` destination port drops the port constraint so the rule matches any port. Two properties are explicit on Cloud NGFW that Network Firewall leaves implicit. The first is **direction**: a 5-tuple rule becomes an ingress policy rule, and the build sets the direction rather than inferring it at match time. The second is the **action**: Cloud NGFW rules are allow or deny individually, so an AWS drop or reject becomes a deny policy rule rather than an omission, and an alert rule becomes an allow rule with rule logging turned on so the traffic is recorded without being blocked. * **One AWS rule, one policy rule:** a `tcp` rule from `10.0.0.0/16` to any host on port `443` becomes a single ingress policy rule with an L4 match on tcp and port 443. * \>**Each rule keeps its action.**> pass and alert become allow, drop and reject become deny, and an alert rule turns on rule logging so it records without blocking. * **Wildcards normalize:** an AWS `ANY` address becomes `0.0.0.0/0`, and an `ANY` destination port removes the port constraint. #### Domain allowlists Network Firewall filters egress by domain through a rule group built from a domain list: a set of target domains, tagged for TLS SNI or HTTP Host matching, generated as an allowlist or a denylist. Cloud NGFW expresses the same control through a policy rule whose match specifies a set of destination FQDNs. A domain list translates into egress policy rules: the domains become the FQDN objects the rule matches, and the list's allowlist or denylist nature sets the rule action. The protocol side follows the domain tag. A TLS-SNI target becomes an FQDN match on TCP port 443, and an HTTP-Host target becomes a match on TCP port 80. Wildcards reconcile: a Network Firewall entry beginning with a leading dot (`.example.com`, the domain and its subdomains) becomes the Cloud NGFW FQDN wildcard form `*.example.com`, >and an exact domain stays as itself. \> * **Domains become FQDN matches:** each domain-list target becomes a destination FQDN an egress policy rule matches on. * **SNI vs Host sets the port:** a TLS-SNI target matches on TCP port 443; an HTTP-Host target matches on TCP port 80. * **Leading-dot wildcards translate.** `.example.com` becomes `*.example.com`, matching the domain and its subdomains. #### Suricata signatures and TLS inspection Two Network Firewall capabilities are deep-packet features rather than allow/deny rules, and Cloud NGFW serves them through surfaces separate from the policy rules. The first is the Suricata signature engine: a rule group can hold raw Suricata IDS/IPS rule strings that match on packet content. Cloud NGFW runs signature-based intrusion prevention through **security profiles**, which are organization-scoped and available at the enterprise tier. The protection has a native form, but the AWS signature text is not a policy rule and does not translate into one, so the build surfaces the signatures for the operator to configure on a security profile. The second is TLS inspection. Network Firewall can decrypt outbound TLS with a certificate and inspect the plaintext. Cloud NGFW performs TLS inspection through a **TLS inspection policy**, a distinct object from the firewall policy rules. The build reports the TLS-inspection configuration rather than recreating it in a rule. Flow and alert logging is likewise not a rule: Cloud NGFW records rule hits through the rule's own logging and Cloud Logging, and the AWS logging configuration is replaced by that rather than emitted. * **Suricata → security profiles:** intrusion prevention is an organization-scoped, enterprise-tier security profile; the AWS signature text is surfaced for the operator to configure, not converted into a policy rule. * **TLS inspection → TLS inspection policy:** outbound decrypt-and-inspect is a separate policy object, reported as an advanced feature rather than recreated in a rule. * **Logging → rule logging and Cloud Logging:** rule hits are recorded through the rule's own logging; the AWS logging configuration is not a rule and does not become one. #### Traffic steering A firewall only filters traffic it governs, and on Cloud NGFW the scope of governance is an association rather than a route. Network Firewall attaches an inspection endpoint into a subnet, and the VPC route tables send traffic through that endpoint; the exact wiring depends on the VPC layout and is not part of the firewall's rules. Cloud NGFW has no appliance to route through. The policy is enforced in the VPC fabric, and it takes effect on a network once the policy is **associated** with that network. The build emits the policy and its rules; the choice of which VPC networks the policy governs is a property of the customer's project, so that association is the operator's to set. At the enterprise tier, running intrusion prevention also involves attaching a firewall endpoint, which is a separate operator step. The rules are in place; the association determines where they apply. * **The policy and rules are emitted:** the network firewall policy and one policy rule per translated rule are provisioned at the build. * **Association sets the scope:** the policy governs a VPC network once it is associated with it, and which networks to govern is a property of the customer's project. * **Intrusion prevention adds an endpoint:** at the enterprise tier, running signature-based prevention involves attaching a firewall endpoint, a separate operator step from the allow/deny rules. #### Limitations The list below is the whole go/no-go picture for Cloud NGFW. The allow/deny rule tree translates into policy rules; the deep-packet features and the network association are where an AWS Network Firewall and Cloud NGFW genuinely diverge. △ Where AWS Network Firewall and GCP Cloud NGFW diverge, read before you adopt * **Suricata signatures do not become rules:** a rule group of raw Suricata IDS/IPS strings has no policy-rule form. Cloud NGFW's security profiles are the native form for signature-based prevention, but they are organization-scoped and enterprise-tier, and the signature text is surfaced for the operator to configure rather than translated. * **TLS inspection is a separate policy object:** outbound TLS decrypt-and-inspect is a Cloud NGFW TLS inspection policy, not a firewall-policy rule. The build reports the TLS-inspection configuration rather than recreating it, so it is enabled by the operator after the build. * **Rule groups flatten into policy rules.** Cloud NGFW has no rule-collection grouping, so each AWS rule becomes one policy rule and the rule-group organization is not preserved. The build assigns a deterministic priority per rule so evaluation order is stable, but the original grouping is not a Cloud NGFW concept. * **Stateless custom actions are dropped:** the 5-tuple of a stateless rule translates, but AWS-specific custom actions (publish-metric actions and their dimensions) have no Cloud NGFW analog and are surfaced, not recreated. * **Multiple policies merge onto one:** if the stack defines more than one firewall policy, the matched rule groups aggregate into a single Cloud NGFW policy. The per-policy separation is reported rather than silently collapsed. * **Network association is wired by the operator:** the policy and rules are emitted, but which VPC networks the policy governs (and, for intrusion prevention, the firewall-endpoint attach) depend on the customer's project layout and are the operator's to complete. #### Other considerations Beyond the rule translation, a few operational realities are worth planning for when a Network Firewall stack moves to Cloud NGFW. * **Nothing to migrate:** a firewall holds no data. The policy and its rules are provisioned at the build, and there is no traffic history or state to copy. * **Google operates the enforcement layer.** Cloud NGFW is a managed, distributed layer in the VPC fabric, so Google runs its availability and scaling, and Tensor9 is not in the packet path. * **The enterprise tier follows the features you use:** allow/deny filtering runs at the standard tier; the security profiles and TLS inspection the advanced Network Firewall features re-home onto require the enterprise tier and, for security profiles, organization-level configuration. * \>**References to the firewall's identity have no equivalent.**> a firewall is a traffic-inspection layer, not an app-consumed endpoint, so an external read of the firewall's ARN or endpoint identity has no portable Cloud NGFW equivalent and is reported rather than repointed. ## On Azure | Operation | Area | Support | Depth | Notes | | ----------------------------- | ---------------- | ------------ | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Suricata rule strings | Advanced rules | Partial | Most usage | raw Suricata IDS/IPS signatures (rules\_source.rules\_string) re-home onto Azure Firewall Premium IDPS, not a plain rule collection; surfaced for the operator to re-home rather than silently dropped | | TLS inspection | Advanced rules | Out of scope | Full surface | aws\_networkfirewall\_tls\_inspection\_configuration is a distinct managed surface (Azure Firewall Premium TLS inspection), surfaced not recreated | | Flow / alert logging | Observability | Out of scope | Full surface | aws\_networkfirewall\_logging\_configuration is replaced by Azure Firewall's own diagnostic-log surface, not a translated rule | | 5-tuple stateful rules | Rule translation | Supported | Common | each stateful\_rule (protocol / source+destination CIDR / port) maps to a network\_rule\_collection rule: protocols, source\_addresses, destination\_addresses, destination\_ports | | Domain allowlists / denylists | Rule translation | Supported | Most usage | a rules\_source\_list (TLS\_SNI / HTTP\_HOST targets) projects onto an application\_rule\_collection rule with destination\_fqdns; a leading-dot AWS wildcard becomes an Azure \*.domain wildcard | | Stateless 5-tuple rules | Rule translation | Partial | Most usage | the 5-tuple match projects; AWS-specific custom actions (publishMetricAction / dimensions) have no Azure analog and are surfaced, not recreated | | VPC inspection routing | Traffic steering | Partial | Common | the firewall + policy + rules emit; the inspection subnet (AzureFirewallSubnet) + route-table steering is deployment-specific and wired by the operator (surfaced, never assumed) | #### How it works An AWS Network Firewall is a managed firewall attached to a firewall policy, and the policy references a tree of rule groups that decide what traffic to allow, drop, or alert on. To run that same protection on the customer's Azure, Tensor9 reads the firewall, its policy, and the whole rule-group tree, and emits the Azure-native equivalent: an **Azure Firewall**, an **Azure Firewall Policy**, and a rule-collection group that holds the translated rules. Azure Firewall is a managed, stateful firewall, the same category of product as Network Firewall. Microsoft runs its data plane, so once the build is done the Azure Firewall inspects packets directly and Tensor9 is not in the path. What translates cleanly is the allow/deny rule tree. What has no plain-rule form (the Suricata signature engine, TLS inspection, and flow logging) moves onto Azure Firewall Premium's own surfaces, and each of those is named in the sections below rather than assumed.
The workload and its routing are untouched; only the firewall that inspects the traffic changes, and it runs in Azure.
#### Architecture Network Firewall spreads its configuration across three resource types: the firewall, its policy, and the rule groups the policy references. Azure Firewall keeps the same separation. The build emits an Azure Firewall running in a dedicated `AzureFirewallSubnet` with a public IP, attached to an Azure Firewall Policy, and the policy holds a single rule-collection group. Inside that group the translated rules land in two collections. A **network rule collection** holds the stateful 5-tuple rules (protocol, source and destination addresses, destination ports). An **application rule collection** holds the domain allowlists (the FQDNs egress traffic may reach). The firewall runs at the Standard tier for allow/deny filtering; the Premium tier adds the intrusion-detection and TLS-inspection surfaces the advanced Network Firewall features move onto, covered further down.
One firewall, one policy, one rule-collection group: the firewall inspects traffic, the policy states the rules, and the group holds the two rule collections translated from the AWS configuration.
#### How the rule groups map The policy's rule groups translate by kind. A stateful rule group of 5-tuple rules becomes a network rule collection: each rule keeps its protocol, its source and destination addresses, and its destination ports, and an AWS `ANY` or `0.0.0.0/0` becomes the Azure any-address token. A rule group built from a domain list becomes an application rule collection, where each entry is a destination FQDN the traffic may reach. Every rule group in the policy folds into the one emitted rule-collection group. A rule group written as raw Suricata signatures is the one kind with no rule-collection form. Azure runs signature-based intrusion detection at the Premium tier, which is a distinct engine rather than an allow/deny rule, so the build surfaces those signatures for the operator to enable on Premium instead of silently discarding them. The allow/deny rules that make up the bulk of most policies translate directly.
The allow/deny rule groups translate onto rule collections one for one; a Suricata signature group has no rule-collection form and points at Premium intrusion detection instead.
#### Stateful 5-tuple rules A stateful rule in Network Firewall matches on the classic 5-tuple: protocol, source address, destination address, source port, and destination port, with an action of pass, drop, or alert. Azure's network rule collection matches on the same fields, so each rule translates field for field. TCP, UDP, and ICMP map as themselves; an AWS `IP` or `ANY` protocol becomes Azure's `Any`. A CIDR is kept verbatim, and a wildcard address becomes the Azure any-address token. Two differences are worth stating flatly. Azure evaluates a rule collection under a single action, so the translated network rule collection is emitted with an `Allow` action and holds the rules that permit traffic; a rule whose intent is to drop is expressed by absence from the allowlist plus the collection's default deny, not by a per-rule drop verb. And Azure orders rule collections by an explicit numeric priority rather than by the rule-group reference order, so the build assigns a deterministic priority to the collection. * **Protocol, addresses, and ports come across field for field:** a `tcp` rule from `10.0.0.0/16` to any host on port `443` becomes the same match in the network rule collection. * **Wildcards normalize:** an AWS `ANY` or `0.0.0.0/0` address becomes Azure's any-address token, and an `IP`/`ANY` protocol becomes `Any`. * **Allow-plus-default-deny, not per-rule drop.** Azure evaluates a collection under one action, so permitted traffic is listed and everything else is denied by default rather than by a drop rule. #### Domain allowlists Network Firewall filters egress by domain through a rule group built from a domain list: a set of target domains, tagged for TLS SNI or HTTP Host matching, generated as an allowlist or a denylist. Azure expresses the same control as an application rule collection, where each rule names a set of destination FQDNs and the protocol (HTTP or HTTPS) the match applies to. A domain list translates into that collection: the domains become the destination FQDNs, and a TLS-SNI target maps to an HTTPS rule while an HTTP-Host target maps to an HTTP rule. AWS and Azure spell wildcards differently, and the build reconciles it. A Network Firewall entry that begins with a leading dot (`.example.com`, meaning the domain and its subdomains) becomes Azure's `*.example.com` form. An exact domain stays as it is. The result is that egress a Network Firewall policy allowed to `*.example.com` is allowed to the same set of hosts on Azure. * **Domains become destination FQDNs:** each domain-list target lands in the application rule collection as an FQDN the workload may reach. * **SNI vs Host sets the protocol:** a TLS-SNI target becomes an HTTPS rule; an HTTP-Host target becomes an HTTP rule. * **Leading-dot wildcards translate.** `.example.com` becomes Azure's `*.example.com`, matching the domain and its subdomains. #### Suricata signatures and TLS inspection Two Network Firewall capabilities are deep-packet features rather than allow/deny rules, and Azure serves them through its Premium tier rather than through a rule collection. The first is the Suricata signature engine: a rule group can hold raw Suricata IDS/IPS rule strings that match on packet content, not only the 5-tuple. Azure Firewall Premium runs its own signature-based intrusion detection and prevention, so the protection has a native equivalent, but the AWS signature text is not a rule collection and does not translate into one. The build surfaces the signatures so the operator can enable equivalent detection on Premium. The second is TLS inspection. Network Firewall can decrypt outbound TLS with a certificate and inspect the plaintext against its rules. Azure Firewall Premium terminates and inspects TLS as a distinct policy capability, separate from the rule collections. The build does not recreate the decryption configuration inside a rule; it reports the TLS-inspection configuration as an advanced feature to enable on Premium. Flow and alert logging is the same story: Network Firewall's logging configuration is replaced by Azure Firewall's own diagnostic logs rather than emitted as a rule. * **Suricata → Premium intrusion detection:** the signature protection runs on Azure Firewall Premium's intrusion detection, but the AWS signature text is surfaced for the operator to enable, not converted into a rule. * **TLS inspection → Premium TLS inspection:** outbound decrypt-and-inspect is a Premium policy capability, reported as an advanced feature rather than recreated in a rule. * **Logging → diagnostic logs.** Azure Firewall emits flow and rule-hit logs through Azure Monitor diagnostic settings; the AWS logging configuration is not a rule and is not emitted as one. #### Traffic steering A firewall only inspects traffic that reaches it, and on both clouds the routing that steers traffic through the firewall is a separate concern from the rules. Network Firewall attaches an inspection endpoint into a subnet, and the VPC route tables send traffic through that endpoint. The exact subnet and route-table wiring depends on the VPC layout, and it is not encoded in the firewall's own rules. Azure works the same way. The emitted Azure Firewall lives in the `AzureFirewallSubnet`, and the VNet route tables have to point at the firewall's private address for it to inspect a given subnet's traffic. The build emits the firewall, the policy, and the rules, and it declares the inspection subnet as a value the operator supplies, because the right subnet and the routes that steer traffic through the firewall are properties of the customer's network, not of the AWS rule tree. The operator wires the route so traffic is inspected; the firewall and its rules are already in place. * **The firewall and rules are emitted:** the Azure Firewall, its policy, and the translated rule collections are provisioned at the build. * **The inspection subnet is supplied by the operator:** the firewall attaches to the `AzureFirewallSubnet`, which is a property of the customer's VNet rather than of the AWS rules. * **The route is the operator's to wire:** the VNet route tables must point the workload subnets at the firewall for it to inspect their traffic, exactly as the VPC route tables did on AWS. #### Limitations The list below is the whole go/no-go picture for Azure Firewall. The allow/deny rule tree translates; the deep-packet features and the routing are where an AWS Network Firewall and Azure Firewall genuinely diverge. △ Where AWS Network Firewall and Azure Firewall diverge, read before you adopt * **Suricata signatures do not become rules:** a rule group of raw Suricata IDS/IPS strings has no rule-collection form. Azure Firewall Premium's intrusion detection is the native equivalent, but the signature text is surfaced for the operator to enable, not translated. If a policy leaned on custom Suricata detections, plan to re-express them on Premium. * **TLS inspection is a Premium capability, not a rule:** outbound TLS decrypt-and-inspect is configured on the Premium policy, separate from the rule collections. The build reports the TLS-inspection configuration rather than recreating it, so it is enabled by the operator after the build. * **Rule collections enforce one action.** Azure evaluates a network or application rule collection under a single action, so permitted traffic is listed in an allow collection and everything else is denied by default. A policy that mixed pass and drop rules within one rule group is expressed as an allowlist plus the default deny, not as per-rule drops. * **Stateless custom actions are dropped:** the 5-tuple of a stateless rule translates, but AWS-specific custom actions (publish-metric actions and their dimensions) have no Azure analog and are surfaced, not recreated. * **Multiple policies merge onto one:** if the stack defines more than one firewall policy, the matched rule groups aggregate into a single Azure policy and rule-collection group. The per-policy separation is reported rather than silently collapsed. * **Inspection routing is wired by the operator:** the firewall and its rules are emitted, but the AzureFirewallSubnet attachment and the VNet routes that steer traffic through the firewall depend on the customer's network layout and are the operator's to complete. #### Other considerations Beyond the rule translation, a few operational realities are worth planning for when a Network Firewall stack moves to Azure Firewall. * **Nothing to migrate:** a firewall holds no data. The Azure Firewall, policy, and rules are provisioned at the build, and there is no traffic history or state to copy. * **Microsoft operates the data plane.** Azure Firewall is a managed service, so once it is provisioned Microsoft runs its availability, scaling, and patching, and Tensor9 is not in the packet path. * **The tier follows the features you use:** allow/deny filtering runs at the Standard tier; the intrusion-detection and TLS-inspection surfaces the advanced Network Firewall features move onto require the Premium tier, which is an operator choice with its own cost. * **References to the firewall's identity have no equivalent:** a firewall is a traffic-inspection appliance, not an app-consumed endpoint, so an external read of the firewall's ARN or endpoint identity has no portable Azure equivalent and is reported rather than repointed. ## On OCI | Operation | Area | Support | Depth | Notes | | ----------------------------- | ---------------- | ------------ | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Suricata rule strings | Advanced rules | Partial | Most usage | raw Suricata signatures re-home onto the OCI Network Firewall's own inspection surface, not a plain security rule; surfaced, never silently dropped | | TLS inspection | Advanced rules | Out of scope | Full surface | aws\_networkfirewall\_tls\_inspection\_configuration re-homes onto OCI decryption profiles / rules (a distinct surface), surfaced not recreated | | Flow / alert logging | Observability | Out of scope | Full surface | aws\_networkfirewall\_logging\_configuration is replaced by the OCI Network Firewall's own logging, not a translated rule | | 5-tuple stateful rules | Rule translation | Supported | Common | each stateful\_rule projects onto a security rule whose condition references emitted address lists (source / destination CIDR) + a service (the destination port) | | Domain allowlists / denylists | Rule translation | Supported | Most usage | a rules\_source\_list projects onto a url\_list + a security rule whose condition references it; ALLOWLIST → ALLOW, DENYLIST → DROP | | Stateless 5-tuple rules | Rule translation | Partial | Most usage | the 5-tuple match projects; AWS-specific custom actions have no OCI analog and are surfaced, not recreated | | VPC inspection routing | Traffic steering | Partial | Common | the firewall + policy + rules emit; the firewall's subnet attachment + route-table steering is deployment-specific and wired by the operator (surfaced, never assumed) | #### How it works An AWS Network Firewall is a managed firewall attached to a firewall policy, and the policy references a tree of rule groups that decide what traffic to allow, drop, or alert on. To run that same protection on the customer's OCI, Tensor9 reads the firewall, its policy, and the whole rule-group tree, and emits the Oracle-native equivalent: an **OCI Network Firewall** attached to an **OCI Network Firewall Policy** whose security rules state the translated decisions. The OCI Network Firewall is a managed, stateful firewall, the same category of product as Network Firewall. Oracle runs its data plane, so once the firewall is attached to a subnet and the route points at it, it inspects packets directly and Tensor9 is not in the path. The allow/deny rules become security rules, though OCI expresses them through named objects rather than inline values, which the next section walks through. The Suricata signature engine and TLS inspection move onto the firewall's own inspection surface and decryption profiles, named below rather than assumed.
The workload and its routing are untouched; only the firewall that inspects the traffic changes, and it runs in OCI.
#### Architecture Network Firewall spreads its configuration across the firewall, its policy, and the rule groups the policy references. The OCI Network Firewall keeps the firewall and policy, but its rules are shaped differently. A **security rule** in the policy does not hold a CIDR, a port, or a domain inline. Its condition references **named objects**: an address list for source and destination addresses, a service for a port, and a url list for domains. So the build emits more than a rule. For each translated rule it emits the address lists, services, and url lists the rule needs, then a security rule whose condition points at them by name. That indirection has a real payoff: a CIDR that appears in several rules becomes one address list they all reference, rather than being repeated inline. The firewall attaches to a subnet in a compartment, and the security rules take their action (allow, drop, or reject) per rule.
A security rule holds no addresses or ports of its own; its condition references named address lists, services, and url lists the build emits alongside it.
#### How the rule groups map The policy's rule groups translate by kind. A stateful rule group of 5-tuple rules becomes a set of security rules: for each rule the build emits an address list for the source and destination CIDRs and a service for the destination port, then a security rule whose condition references them and whose action is taken from the AWS action (pass becomes allow, drop becomes drop, reject becomes reject). A rule group built from a domain list becomes a url list holding the domains and a security rule that references it, allow for an allowlist and drop for a denylist. A rule group written as raw Suricata signatures is the one kind with no security-rule form. The OCI Network Firewall runs its own signature-based inspection as a capability of the same firewall rather than as a security rule, so the build surfaces those signatures for the operator to enable on the firewall's inspection surface rather than discarding them. The allow/deny rules that make up the bulk of most policies translate directly.
The allow/deny rule groups translate onto security rules over emitted address lists, services, and url lists; a Suricata signature group has no security-rule form and points at the firewall's inspection surface instead.
#### Stateful 5-tuple rules A stateful rule in Network Firewall matches on the 5-tuple: protocol, source address, destination address, source port, and destination port, with an action of pass, drop, or alert. An OCI security rule matches on the same shape, but through the named objects rather than inline values. For each rule the build emits an address list for the source CIDR and one for the destination CIDR, a service for the destination port, and a security rule whose condition names those objects. Where the AWS rule uses `ANY` for an address or port, that part of the condition is omitted, so the rule matches any value there. The action maps per rule. A pass becomes `ALLOW`, a drop becomes `DROP`, and a reject becomes `REJECT`, which is the OCI verb for an actively refused connection. Because the addresses and ports live in named objects, a CIDR or port that several rules share is emitted once and referenced by each rule, so the emitted policy stays compact even when the AWS rule set repeats the same networks. * **Match lives in named objects:** a `tcp` rule from `10.0.0.0/16` to any host on port `443` becomes an address list, a service, and a security rule whose condition references them. * **The action is kept per rule:** pass becomes `ALLOW`, drop becomes `DROP`, and reject becomes `REJECT`. * **Shared networks are emitted once:** a CIDR or port used by several rules becomes one address list or service the rules reference, and an `ANY` value is omitted from the condition so it matches anything. #### Domain allowlists Network Firewall filters egress by domain through a rule group built from a domain list: a set of target domains, tagged for TLS SNI or HTTP Host matching, generated as an allowlist or a denylist. The OCI Network Firewall expresses the same control through a **url list** and a security rule that references it. A domain list becomes a url list holding the domains as URL patterns, and a security rule whose condition names that url list, with an action of allow for an allowlist or drop for a denylist. The domains become URL patterns. A Network Firewall entry that begins with a leading dot (`.example.com`, the domain and its subdomains) becomes the OCI wildcard URL pattern, and an exact domain stays as it is. Egress a Network Firewall policy allowed to `*.example.com` is allowed to the same set of hosts through the url list the security rule references. * **Domains become a url list:** each domain-list target lands in a url list as a URL pattern, and a security rule references the list. * **Allowlist vs denylist sets the action:** an allowlist becomes an `ALLOW` security rule and a denylist becomes a `DROP` one. * **Leading-dot wildcards translate.** `.example.com` becomes the OCI wildcard URL pattern, matching the domain and its subdomains. #### Suricata signatures and TLS inspection Two Network Firewall capabilities are deep-packet features rather than allow/deny rules, and the OCI Network Firewall serves them as capabilities of the same firewall rather than as security rules. The first is the Suricata signature engine: a rule group can hold raw Suricata IDS/IPS rule strings that match on packet content. The OCI Network Firewall runs its own signature-based intrusion detection and prevention, so the protection has a native form, but the AWS signature text is not a security rule and does not translate into one. The build surfaces the signatures for the operator to enable on the firewall's inspection surface. The second is TLS inspection. Network Firewall can decrypt outbound TLS with a certificate and inspect the plaintext. The OCI Network Firewall decrypts and inspects TLS through decryption profiles and decryption rules , a distinct part of the policy from the security rules. The build reports the TLS-inspection configuration for the operator to attach rather than recreating it in a security rule. Logging follows the same pattern: the OCI Network Firewall records traffic through its own logging, so Network Firewall's separate logging configuration is replaced by the firewall's logging rather than emitted as a rule. * **Suricata → the firewall's inspection surface:** signature-based inspection is a capability of the same firewall; the AWS signature text is surfaced for the operator to enable, not converted into a security rule. * **TLS inspection → decryption profiles and rules:** outbound decrypt-and-inspect is a distinct part of the policy, reported as an advanced feature rather than recreated in a security rule. * **Logging is the firewall's own:** the OCI Network Firewall records traffic through its logging; the AWS logging configuration is not a rule and is not emitted as one. #### Traffic steering A firewall only inspects traffic that reaches it, and on both clouds the routing that steers traffic through the firewall is separate from the rules. Network Firewall attaches an inspection endpoint into a subnet, and the VPC route tables send traffic through that endpoint. The exact subnet and route-table wiring depends on the VPC layout and is not part of the firewall's rules. The OCI Network Firewall attaches to a subnet in a compartment, and the VCN route tables have to point at the firewall's private address for it to inspect a given subnet's traffic. The build emits the firewall, the policy, the security rules, and the named objects the rules reference, and it declares the compartment and the firewall subnet as values the operator supplies, because those are properties of the customer's tenancy and network rather than of the AWS rule tree. The operator wires the route so traffic is inspected; the firewall and its rules are already in place. * **The firewall, rules, and named objects are emitted:** the OCI Network Firewall, its policy, the security rules, and the address lists, services, and url lists they reference are provisioned at the build. * **The compartment and subnet are supplied by the operator:** the firewall attaches to a subnet in a compartment, which are properties of the customer's tenancy rather than of the AWS rules. * **The route is the operator's to wire:** the VCN route tables must point the workload subnets at the firewall for it to inspect their traffic, exactly as the VPC route tables did on AWS. #### Limitations The list below is the whole go/no-go picture for the OCI Network Firewall. The allow/deny rule tree translates into security rules over named objects; the deep-packet features and the routing are where an AWS Network Firewall and the OCI Network Firewall genuinely diverge. △ Where AWS Network Firewall and the OCI Network Firewall diverge, read before you adopt * **Suricata signatures do not become rules:** a rule group of raw Suricata IDS/IPS strings has no security-rule form. The OCI Network Firewall's own signature inspection is the native form, but the signature text is surfaced for the operator to enable, not translated. If a policy leaned on custom Suricata detections, plan to re-express them on the firewall's inspection surface. * **TLS inspection is a separate part of the policy:** outbound TLS decrypt-and-inspect is a decryption profile and decryption rules, not a security rule. The build reports the TLS-inspection configuration rather than recreating it, so it is attached by the operator after the build. * **Rules match through named objects:** a security rule references address lists, services, and url lists rather than inlining a CIDR or port. The translation is faithful, but the emitted policy is a set of named objects plus rules rather than a flat rule list, which is worth knowing when reading or auditing it. * **Stateless custom actions are dropped:** the 5-tuple of a stateless rule translates, but AWS-specific custom actions (publish-metric actions and their dimensions) have no OCI analog and are surfaced, not recreated. * **Multiple policies merge onto one:** if the stack defines more than one firewall policy, the matched rule groups aggregate into a single OCI policy. The per-policy separation is reported rather than silently collapsed. * **Inspection routing is wired by the operator:** the firewall and its rules are emitted, but the compartment, the firewall subnet, and the VCN routes that steer traffic through the firewall depend on the customer's tenancy and network and are the operator's to complete. #### Other considerations Beyond the rule translation, a few operational realities are worth planning for when a Network Firewall stack moves to the OCI Network Firewall. * **Nothing to migrate:** a firewall holds no data. The firewall, policy, rules, and named objects are provisioned at the build, and there is no traffic history or state to copy. * **Oracle operates the data plane:** the OCI Network Firewall is a managed service, so once it is attached Oracle runs its availability, scaling, and patching, and Tensor9 is not in the packet path. * **The policy reads as named objects plus rules:** auditing the emitted firewall means reading the security rules together with the address lists, services, and url lists they reference, which is the OCI shape rather than a single inline rule list. * **References to the firewall's identity have no equivalent:** a firewall is a traffic-inspection appliance, not an app-consumed endpoint, so an external read of the firewall's ARN or endpoint identity has no portable OCI equivalent and is reported rather than repointed. [Service Catalog](/service-adapters/catalog).