Skip to main content
On this page

​
Coverage by target cloud

​
How the backends compare

Each row compares a capability of Network Firewall with its adaptation on each backend. A dash means this row is not stated for that backend.

​
Infrastructure-only adaptation

​
On Google Cloud

​
How it works

Your Network Firewall setup (the firewall, its policy and the rule groups the policy references) is translated when the stack is built. The build creates a Cloud NGFW network firewall policy with one policy rule for each translated rule. Cloud NGFW works differently from a routed firewall. There is no firewall instance and no firewall subnet: Google enforces the policy inside the VPC network, on the networks the policy is associated with. Once it is deployed, Google filters the traffic and Tensor9 is not in the path. Stateful 5-tuple rules and domain lists become policy rules. Suricata signatures and TLS inspection have no policy-rule form; you set them up with Cloud NGFW security profiles and a TLS inspection policy, as described below.
On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On Google Cloud, the Cloud NGFW policy that the build creates is applied inside the VPC network, so there is no separate firewall to route through. Tensor9 is not in the path.On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On Google Cloud, the Cloud NGFW policy that the build creates is applied inside the VPC network, so there is no separate firewall to route through. Tensor9 is not in the path.

Your workloads stay as they are; Google applies the Cloud NGFW policy inside the VPC network, with no separate firewall to route through.

​
What the build creates

Cloud NGFW has no rule groups or rule collections. The build creates one network firewall policy and one policy rule per AWS rule, so a rule group of ten rules becomes ten policy rules. Each rule has a priority, an action (allow or deny), a direction (ingress or egress) and a match. Priorities start at 1001 and follow the AWS rule order, with all 5-tuple rules first and then the domain rules, so the order stays the same on every build. The build does not associate the policy with any network. You choose which VPC networks it governs and create that association. All Network Firewall resources must be in the stack’s root module; otherwise the build stops with an error.
The build creates one network firewall policy holding a flat list of policy rules in priority order: 5-tuple rules first, then domain rules. Each AWS rule becomes one policy rule. The policy applies to the VPC networks you associate it with.The build creates one network firewall policy holding a flat list of policy rules in priority order: 5-tuple rules first, then domain rules. Each AWS rule becomes one policy rule. The policy applies to the VPC networks you associate it with.

One policy with a flat list of rules, evaluated in priority order, applied to the VPC networks you associate.

​
How the rules translate

Stateful 5-tuple rules. Each rule becomes an INGRESS policy rule that keeps its source and destination ranges, protocol and destination port. TCP, UDP and ICMP stay as they are, and an IP or ANY protocol becomes all. An ANY address becomes 0.0.0.0/0, and an ANY port removes the port match. Pass rules become allow rules, drop and reject rules become deny rules, and alert rules become allow rules with rule logging turned on, so the traffic is recorded but not blocked. Domain lists. Each domain list becomes an EGRESS policy rule that matches the list’s domains as destination FQDNs: allow for an allowlist, deny for a denylist. A list that matches on TLS SNI matches TCP port 443; a list that matches only on the HTTP Host header matches TCP port 80. A leading-dot entry such as .example.com becomes *.example.com.
Stateful 5-tuple rules become ingress policy rules, and a domain allowlist becomes egress policy rules that match destination FQDNs. A group of Suricata rules is not translated; the closest Cloud NGFW feature is a security profile, which you configure yourself.Stateful 5-tuple rules become ingress policy rules, and a domain allowlist becomes egress policy rules that match destination FQDNs. A group of Suricata rules is not translated; the closest Cloud NGFW feature is a security profile, which you configure yourself.

Stateful rules become ingress rules and domain lists become egress rules; Suricata signatures do not translate.

​
Limitations

Where Network Firewall and Cloud NGFW differ
  • Suricata signatures are not supported. A rule group of raw Suricata IDS/IPS rules creates no policy rule. Cloud NGFW security profiles are the closest feature; they are set at the organization level and need the Enterprise tier.
  • TLS inspection behaves differently: you configure a TLS inspection policy. The build does not recreate the TLS inspection configuration. You set up Cloud NGFW TLS inspection yourself after the build.
  • Logging behaves differently: only former alert rules log. The Network Firewall logging configuration is not recreated. Cloud NGFW logs rule hits to Cloud Logging for rules with logging on, and the build turns it on only for rules that were alert rules on AWS.
  • Stateful rules behave differently: each becomes an ingress rule. Every 5-tuple rule is created with direction INGRESS, including rules that filtered outbound traffic on AWS. Review those rules and add egress rules where you need them.
  • Rule groups behave differently: they are flattened. Each AWS rule becomes one policy rule, and the rule-group structure is not kept. Evaluation follows the assigned priorities: 5-tuple rules first, in AWS order, then domain rules.
  • You must associate the policy with your VPC networks. The policy has no effect until it is associated with a network. For intrusion prevention at the Enterprise tier, you also attach a firewall endpoint.
  • You must keep the Network Firewall resources in the root module. If any aws_networkfirewall_* resource is in a child module, the build stops with an error.
  • Stateless rules are not supported. The build translates stateful rules and domain lists only. A stateless rule group, including custom actions such as publish-metric, creates no rule on Cloud NGFW, so the traffic it handled falls to Cloud NGFW’s own default. Re-create those rules directly on Cloud NGFW.
  • Policy default actions behave differently: they are not kept. The AWS policy’s stateless and stateful default actions and its stream exception policy have no equivalent setting. Traffic that matches no rule follows Cloud NGFW’s own default, so confirm that default matches your AWS policy.
  • Source-port matching is not supported. Rules on Cloud NGFW match the destination port only. A rule that also restricts the source port becomes broader than it was on AWS, and the build warns about it.
  • Several firewall policies behave differently: they merge into one. If the stack defines more than one firewall policy, all of their rule groups go into one policy on Cloud NGFW, and the build warns about the merge.
  • Rules the build cannot read behave differently: they become deny rules. A stateful rule whose action, protocol, address or port comes from a variable or a dynamic block, or whose protocol is an application protocol such as HTTP, TLS or DNS, is created as a deny rule, with the unread parts matching anything. A domain list whose type comes from a variable becomes a deny list. A domain list whose domains come from a variable creates no rule at all.

​
Other considerations

  • Google runs the enforcement. Cloud NGFW is managed and enforced inside the VPC network: Google handles its availability and scaling, and Tensor9 is not in the packet path.
  • Choose the tier. Allow and deny rules run at the Standard tier. Security profiles and TLS inspection need the Enterprise tier and, for security profiles, organization-level configuration.
  • Before going live. Associate the policy with the right VPC networks, and check the direction of rules that were meant for outbound traffic.
  • Nothing to migrate. A firewall holds no data. The build creates the resources on Cloud NGFW, and there is no traffic history or state to copy.
  • Read the build warnings. Each rule or setting that did not translate exactly, as listed under Limitations, appears as a warning in the build output with what to re-create.
  • References to the firewall’s ARN or ID. A firewall has no endpoint for applications to call, so these have no equivalent on Cloud NGFW. An output that reads one is removed, with a warning; any other reference stops the build with an error naming the attribute.

​
On Azure

​
How it works

Your Network Firewall setup (the firewall, its policy and the rule groups the policy references) is translated when the stack is built. The build creates an Azure Firewall, an Azure Firewall Policy and a rule collection group that holds the translated rules. Your workloads and their routes do not change; only the firewall that inspects the traffic is different. Azure Firewall is a managed, stateful firewall, like Network Firewall. Microsoft runs it, so once it is deployed it inspects traffic itself and Tensor9 is not in the path. Stateful 5-tuple rules and domain lists become Azure rules. Suricata signatures, TLS inspection and flow logging have no Azure rule form; you set them up on Azure Firewall Premium and Azure Monitor, as described below.
On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On Azure, the same subnet routes through an Azure Firewall that the build creates. Azure Firewall inspects the traffic itself; Tensor9 is not in the path.On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On Azure, the same subnet routes through an Azure Firewall that the build creates. Azure Firewall inspects the traffic itself; Tensor9 is not in the path.

Your workloads and routes stay as they are; an Azure Firewall inspects the traffic instead of Network Firewall.

​
What the build creates

The build creates an Azure Firewall at the Standard tier (AZFW_VNet) with a public IP, attached to an Azure Firewall Policy. The policy holds one rule collection group. Stateful 5-tuple rules go into network rule collections, and domain lists go into application rule collections. The firewall is placed in the AzureFirewallSubnet of your virtual network, which is a deployment input. Azure sets allow or deny on a whole rule collection, not on each rule. The build therefore splits each kind of rule by action into an allow collection and a deny collection. The allow collection gets the lower priority number, so Azure evaluates allow rules before deny rules, whatever their order in the AWS rule group.
The build creates an Azure Firewall in the AzureFirewallSubnet with a public IP. It is attached to an Azure Firewall Policy, which holds one rule collection group with network rule collections and application rule collections.The build creates an Azure Firewall in the AzureFirewallSubnet with a public IP. It is attached to an Azure Firewall Policy, which holds one rule collection group with network rule collections and application rule collections.

One firewall, one policy, and one rule collection group that holds the translated rules.

​
How the rules translate

Stateful 5-tuple rules. Each rule keeps its protocol, source and destination addresses and destination port. TCP, UDP and ICMP stay as they are, and an IP or ANY protocol becomes Any. An ANY or 0.0.0.0/0 address, and an ANY port, become *. Pass and alert rules become allow rules; drop and reject rules become deny rules. Domain lists. Each domain list becomes an application rule whose destination FQDNs are the list’s domains: an allow rule for an allowlist, a deny rule for a denylist. A list that matches on TLS SNI becomes an HTTPS rule on port 443; a list that matches only on the HTTP Host header becomes an HTTP rule on port 80. A leading-dot entry such as .example.com becomes *.example.com.
Stateful 5-tuple rules become network rules, and a domain allowlist becomes application rules. A group of Suricata rules is not translated; the closest Azure feature is Premium intrusion detection, which you enable yourself.Stateful 5-tuple rules become network rules, and a domain allowlist becomes application rules. A group of Suricata rules is not translated; the closest Azure feature is Premium intrusion detection, which you enable yourself.

Stateful rules and domain lists become Azure rules; Suricata signatures do not translate.

​
Limitations

Where Network Firewall and Azure Firewall differ
  • Suricata signatures are not supported. A rule group of raw Suricata IDS/IPS rules creates no Azure rule. Azure Firewall Premium IDPS is the closest feature; if you rely on custom Suricata detections, plan to re-create them there.
  • TLS inspection behaves differently: you configure it on Premium. The build does not recreate the TLS inspection configuration. Outbound TLS decryption and inspection is a Premium policy feature that you enable after the build.
  • Logging behaves differently: you enable Azure diagnostic logs. The Network Firewall logging configuration is not recreated. Azure Firewall writes flow and rule logs through Azure Monitor diagnostic settings, which you enable on the firewall.
  • Alert and reject actions behave differently: they become allow and deny. Azure sets one action per rule collection and has no alert-only or reject-with-reset action. Alert rules become allow rules, reject rules become deny rules, and allow rules are evaluated first.
  • You must route traffic through the firewall. The build creates the firewall and its rules, not the routes. Point your virtual network’s route tables at the firewall’s private IP so the workload subnets’ traffic passes through it, as the VPC route tables did on AWS.
  • Stateless rules are not supported. The build translates stateful rules and domain lists only. A stateless rule group, including custom actions such as publish-metric, creates no rule on Azure Firewall, so the traffic it handled falls to Azure Firewall’s own default. Re-create those rules directly on Azure Firewall.
  • Policy default actions behave differently: they are not kept. The AWS policy’s stateless and stateful default actions and its stream exception policy have no equivalent setting. Traffic that matches no rule follows Azure Firewall’s own default, so confirm that default matches your AWS policy.
  • Source-port matching is not supported. Rules on Azure Firewall match the destination port only. A rule that also restricts the source port becomes broader than it was on AWS, and the build warns about it.
  • Several firewall policies behave differently: they merge into one. If the stack defines more than one firewall policy, all of their rule groups go into one policy on Azure Firewall, and the build warns about the merge.
  • Rules the build cannot read behave differently: they become deny rules. A stateful rule whose action, protocol, address or port comes from a variable or a dynamic block, or whose protocol is an application protocol such as HTTP, TLS or DNS, is created as a deny rule, with the unread parts matching anything. A domain list whose type comes from a variable becomes a deny list. A domain list whose domains come from a variable creates no rule at all.

​
Other considerations

  • Microsoft runs the firewall. Azure Firewall is a managed service: Microsoft handles its availability, scaling and patching, and Tensor9 is not in the packet path.
  • Choose the tier. The build creates a Standard-tier firewall, which covers allow and deny rules. IDPS and TLS inspection need the Premium tier, which you choose and which has its own cost.
  • Before going live. Supply the AzureFirewallSubnet, add the routes, and confirm that Azure Firewall’s handling of unmatched traffic is what you expect.
  • Nothing to migrate. A firewall holds no data. The build creates the resources on Azure Firewall, and there is no traffic history or state to copy.
  • Read the build warnings. Each rule or setting that did not translate exactly, as listed under Limitations, appears as a warning in the build output with what to re-create.
  • References to the firewall’s ARN or ID. A firewall has no endpoint for applications to call, so these have no equivalent on Azure Firewall. An output that reads one is removed, with a warning; any other reference stops the build with an error naming the attribute.

​
On OCI

​
How it works

Your Network Firewall setup (the firewall, its policy and the rule groups the policy references) is translated when the stack is built. The build creates an OCI Network Firewall attached to an OCI Network Firewall policy whose security rules hold the translated rules. The OCI Network Firewall is a managed, stateful firewall, like Network Firewall. Oracle runs it, so once traffic is routed through it, it inspects that traffic itself and Tensor9 is not in the path. Stateful 5-tuple rules and domain lists become security rules. Suricata signatures, TLS inspection and flow logging have no security-rule form; you set them up on the firewall itself, as described below.
On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On OCI, the same subnet routes through an OCI Network Firewall that the build creates. The firewall inspects the traffic itself; Tensor9 is not in the path.On AWS, a workload subnet routes traffic through a Network Firewall endpoint, which inspects it before it reaches the internet. On OCI, the same subnet routes through an OCI Network Firewall that the build creates. The firewall inspects the traffic itself; Tensor9 is not in the path.

Your workloads and routes stay as they are; an OCI Network Firewall inspects the traffic instead of Network Firewall.

​
What the build creates

An OCI security rule does not hold a CIDR, a port or a domain directly. Its condition refers by name to separate policy objects: an address list for addresses, a service for a port, and a url list for domains. So for each AWS rule the build creates the objects the rule needs and a security rule that refers to them. A CIDR or port used by several rules becomes one object that they all share. The firewall and its policy are placed in the compartment and private subnet supplied with the deployment. Each security rule takes its own action: allow, drop or reject.
The build creates an OCI Network Firewall attached to a firewall policy. Each security rule refers by name to objects the build also creates: an address list for CIDRs, a service for a port, and a url list for domains.The build creates an OCI Network Firewall attached to a firewall policy. Each security rule refers by name to objects the build also creates: an address list for CIDRs, a service for a port, and a url list for domains.

A security rule holds no addresses or ports itself; it refers by name to address lists, services and url lists.

​
How the rules translate

Stateful 5-tuple rules. Each source or destination CIDR becomes an IP address list, and each destination port becomes a TCP service. The security rule’s condition refers to them; an ANY address or port is left out of the condition, so it matches any value. Pass becomes ALLOW, drop becomes DROP, reject becomes REJECT, and alert becomes ALLOW. The rule itself has no protocol; see Limitations. Domain lists. Each domain list becomes a url list of simple patterns and a security rule that refers to it: ALLOW for an allowlist, DROP for a denylist. A leading-dot entry such as .example.com becomes *.example.com.
Stateful 5-tuple rules become security rules that refer to an address list and a service. A domain allowlist becomes a url list and a security rule that refers to it. A group of Suricata rules is not translated; the closest OCI feature is the firewall's own intrusion detection, which you enable yourself.Stateful 5-tuple rules become security rules that refer to an address list and a service. A domain allowlist becomes a url list and a security rule that refers to it. A group of Suricata rules is not translated; the closest OCI feature is the firewall's own intrusion detection, which you enable yourself.

Stateful rules and domain lists become security rules over named objects; Suricata signatures do not translate.

​
Limitations

Where Network Firewall and the OCI Network Firewall differ
  • Suricata signatures are not supported. A rule group of raw Suricata IDS/IPS rules creates no security rule. The firewall’s own intrusion detection is the closest feature; if you rely on custom Suricata detections, plan to re-create them there.
  • TLS inspection behaves differently: you attach decryption profiles and rules. The build does not recreate the TLS inspection configuration. You configure decryption on the policy after the build.
  • Logging behaves differently: you enable the firewall’s own logs. The Network Firewall logging configuration is not recreated. The OCI Network Firewall has its own traffic logging, which you enable.
  • Protocols behave differently: rules match on port only. The security rules have no protocol. A destination port becomes a TCP service, so a UDP rule with a port is matched as TCP, and a rule without a port matches any protocol.
  • Domain matching behaves differently: TLS SNI and HTTP Host are not distinguished. Each domain list becomes a url list of simple patterns, whether it matched on TLS SNI or on the HTTP Host header.
  • Alert rules behave differently: they become ALLOW rules. The rule lets the traffic through; no alert is configured for it.
  • You must route traffic through the firewall. The build creates the firewall and its rules, not the routes. Point your VCN route tables at the firewall’s private IP so the workload subnets’ traffic passes through it, as the VPC route tables did on AWS.
  • Stateless rules are not supported. The build translates stateful rules and domain lists only. A stateless rule group, including custom actions such as publish-metric, creates no rule on the OCI Network Firewall, so the traffic it handled falls to the OCI Network Firewall’s own default. Re-create those rules directly on the OCI Network Firewall.
  • Policy default actions behave differently: they are not kept. The AWS policy’s stateless and stateful default actions and its stream exception policy have no equivalent setting. Traffic that matches no rule follows the OCI Network Firewall’s own default, so confirm that default matches your AWS policy.
  • Source-port matching is not supported. Rules on the OCI Network Firewall match the destination port only. A rule that also restricts the source port becomes broader than it was on AWS, and the build warns about it.
  • Several firewall policies behave differently: they merge into one. If the stack defines more than one firewall policy, all of their rule groups go into one policy on the OCI Network Firewall, and the build warns about the merge.
  • Rules the build cannot read behave differently: they become deny rules. A stateful rule whose action, protocol, address or port comes from a variable or a dynamic block, or whose protocol is an application protocol such as HTTP, TLS or DNS, is created as a deny rule, with the unread parts matching anything. A domain list whose type comes from a variable becomes a deny list. A domain list whose domains come from a variable creates no rule at all.

​
Other considerations

  • Oracle runs the firewall. The OCI Network Firewall is a managed service: Oracle handles its availability, scaling and patching, and Tensor9 is not in the packet path.
  • Reading the policy. To audit the result, read each security rule together with the address lists, services and url lists it refers to.
  • Before going live. Add the routes, and check rules that used UDP or ICMP, since their protocol is not kept.
  • Nothing to migrate. A firewall holds no data. The build creates the resources on the OCI Network Firewall, and there is no traffic history or state to copy.
  • Read the build warnings. Each rule or setting that did not translate exactly, as listed under Limitations, appears as a warning in the build output with what to re-create.
  • References to the firewall’s ARN or ID. A firewall has no endpoint for applications to call, so these have no equivalent on the OCI Network Firewall. An output that reads one is removed, with a warning; any other reference stops the build with an error naming the attribute.

​
Debug this service

For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping. Follow the BYOC service-adapter debugging runbook to capture and interpret the diagnostic evidence. Service Catalog.