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

[johnlloyd13]

hi,

i just tested and confirmed only 1 FW policy is needed.

i created both in/out FW policy and only the 'out' FW policy had a hit/traffic.

not sure why fortinet doc indicated to create 2 FW policies.

[Toshi_Esumi]

That only means there is no out->in traffic coming from outside so far. 

Toshi

[aguerriero]

His original question was converting that one single ASA policy to a fortigate policy. That ASA policy is not bidirectional... it is stateful. 

[Toshi_Esumi]

Probably opposite. Only traffic happening is likely out->DMZ, if no traffic is initiated by the servers inside of DMZ, nothing would hit the second policy.

Toshi

Toshi

[aguerriero]

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. 

[johnlloyd13]

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.

[aguerriero]

the higher security level to a lower security level has a built-in ASA permit logic so an ACL in that direction wasn't necessarily needed on the ASA. 

how many directional rules were you able to remove after cleaning everything up? 

[Toshi_Esumi]

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 

[johnlloyd13]

hi,

yes, only a handful of rules are active when i monitored in the new FGT.

i don't have time to analyze 500 ACL lines as it's counter productive.

IMHO it's more efficient just to move all rules in the FGT. then use analytics to do clean up afterwards.