Converting Firewall Policy from Cisco ASA ACL

[johnlloyd13]

hi,

i'm migrating a cisco asa ACL to a FGT.

just to confirm, i'll always need to create 2x FW policy: inbound and outbound rule for each single ACL?

an example would be below:

!! ASA:

access-list DMZ-IN extended permit tcp object SERVER-SUBNET 10.200.0.0 255.255.0.0

access-group DMZ-IN in interface dmz

!! FGT:
edit DMZ-IN 1
set srcintf "any"
set dstintf "port 1" !! DMZ interface
set srcaddr "SERVER-SUBNET"
set dstaddr "10.200.0.0_16-SUBNET"
set service "ALL_TCP"
set schedule "always"
set logtraffic enable
set status enable
set action accept
set nat disable
next

edit DMZ-IN 2 !! JUST CLONE REVERSE FW POLICY 1
set srcintf "port 1"
set dstintf "any"
set srcaddr "10.200.0.0_16-SUBNET"
set dstaddr "SERVER-SUBNET"
set service "ALL_TCP"
set schedule "always"
set logtraffic enable
set status enable
set action accept
set nat disable
next

[kaman · Accepted solution]

Hi johnlloyd13,

FortiGate does not inspect traffic bidirectionally by default in a single rule. FortiGate policies are unidirectional, meaning:

One policy for traffic from A ➝ B

If return traffic doesn't match a session or there's no NAT, you may need a reverse policy B ➝ A depending on the use case.

Traffic parameters are checked against the configured policies for a match. If the parameters do not match any configured policies, the traffic is denied.

Traffic flow initiated from each direction requires a policy, that is, if sessions can be initiated from both directions, each direction requires a policy.

Just because packets can go from point A to point B on port X does not mean that the traffic can flow from point B to point A on port X. A policy must be configured for each direction.

Note: FortiOS does not perform a reverse-path check on reply traffic that matches an allowed session based on the IP tuple. The request traffic can be sent on one interface and the reply traffic could return on another interface.

Reference Link: https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/656084/firewall-policy

Additionally, avoid using 'any' interface as either the source or the destination interface in a firewall policy that allows traffic. Instead, use specific interfaces along with specific addresses/subnets in the firewall policies.
This granular approach will filter out any unexpected traffic and only allow the necessary traffic. Additionally, this decreases the chances of any potential audit and compliance issues.

Please refer to the document below for more information:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Best-practices-for-firewall-policy-configu...

If you have found a solution, please like and accept it to make it easily accessible to others.

Regards,
Aman

[kaman · Accepted solution]

Hi johnlloyd13,

FortiGate does not inspect traffic bidirectionally by default in a single rule. FortiGate policies are unidirectional, meaning:

One policy for traffic from A ➝ B

If return traffic doesn't match a session or there's no NAT, you may need a reverse policy B ➝ A depending on the use case.

Traffic parameters are checked against the configured policies for a match. If the parameters do not match any configured policies, the traffic is denied.

Traffic flow initiated from each direction requires a policy, that is, if sessions can be initiated from both directions, each direction requires a policy.

Just because packets can go from point A to point B on port X does not mean that the traffic can flow from point B to point A on port X. A policy must be configured for each direction.

Note: FortiOS does not perform a reverse-path check on reply traffic that matches an allowed session based on the IP tuple. The request traffic can be sent on one interface and the reply traffic could return on another interface.

Reference Link: https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/656084/firewall-policy

Additionally, avoid using 'any' interface as either the source or the destination interface in a firewall policy that allows traffic. Instead, use specific interfaces along with specific addresses/subnets in the firewall policies.
This granular approach will filter out any unexpected traffic and only allow the necessary traffic. Additionally, this decreases the chances of any potential audit and compliance issues.

Please refer to the document below for more information:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Best-practices-for-firewall-policy-configu...

If you have found a solution, please like and accept it to make it easily accessible to others.

Regards,
Aman

[johnlloyd13]

hi kaman,

thanks for the reply and the link provided! i did read this somewhere before that's why i just need to re-confirm. i'll create 2x FW policy then to ensure bi-directional traffic.

i'll use "any" since i don't have the time to analyze traffic flow for 500 plus ACL lines.

[filiaks1]

Also see the service FortiConverter Service for Firewall Migration I have not used it but it could be helpfull.

[johnlloyd13]

hi,

i use forticonverter but it's not really helpful. 

it just produce a single FW policy and didn't create the reverse.

you still need to do this manually.

[aguerriero]

The ASA and fortigate are both stateful and both maintain session tables. If you create a TCP rule in a specific direction then return traffic as part of the session will be permitted back in. So only one rule would be needed in the direction you want to permit sessions.

You would only use those two rules if you wanted to allow bidirectional session establishment, which your ASA policy does not. 

[johnlloyd13]

hi,

i doubt that since my scenario is just purely ACL rules that permits traffic between few interfaces in the ASA with no NAT.

per the fortinet link, you'll need a firewall policy in each direction.

https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/656084/firewall-policy

i only create a single FW policy for outbound SNAT rule.

[aguerriero]

Good luck.

[johnlloyd13]

hi,

i'd prefer doing this in a lab instead of using AI.

AI is not always a fool proof solution.

[aguerriero · Accepted solution]

That's fine if you want to learn the syntax. but your assumption that 2 policies is required to replace that rule is incorrect unless you are splitting security levels and using default asa security levels for deny or permit by actions.

If you want to a concept in fortigate that is similar in asa security levels you should look into creating zones in the fortigate and place your interfaces with the equal security levels in the fortigate zones. 

Again good luck.