Converting Firewall Policy from Cisco ASA ACL

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-configuration/ta-p/193255

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

Regards,
Aman

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

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. 

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

access-list DMZ-IN extended permit tcp 
this portion says that access list with name DMZ-IN is extended which can filter on both source and destination protocol or port or source and destination address

object SERVER-SUBNET
object then references a source object group called SERVER-SUBNET which will contain other objects or subnets.

10.200.0.0 255.255.0.0
This is a destination subnet which could also be a call to an object or directly to a subnet.

access-group DMZ-IN in interface dmz

the interface name is dmz, and the direction of the applied policy is any traffic that ingresses the interface named DMZ.


The policy is a single direction policy applied ingress on an interface named DMZ that only allows source object SERVER-SUBNET to reach destination subnet 10.200.0.0 255.255.0.0

Return traffic is allowed because an ASA is a stateful firewall, the same as a fortigate. 

hi,

the original ASA ACL had 2 ACLs which is in and out.

so i just followed accordingly so i don't have a miss anything since there were around 500 ACL which i needed to convert.

the only traffic matched is the 'out' FW policy rule. the 2 ASA interface are on different security levels.

The biggest question is how many of 500 are actually used/needed now with the ASA. My wild guess is less than half if it's been used for years. I would audit those to figure out which ones are actually needed to be there first. Otherwise, every time a migration need to happen, somebody else if not you need to do the same unnecessary work to convert garbage, which would never be used.

Toshi