modifying rules migrated via Firepower Migration Tool

[atsukane]

HI all,

I've migrated a few ASAs to FMC managed FTDs using Firepower Migration Tool, using both ver2.4 and ver2.4.1

It's a handy tool so that we don't have to create objects and rules from scratch, but obviously not perfect.

1. We have outbound rules which FMT ignores, so I had to manipulate the config to make it think like inbound rules, we then have to manually swap the source/destination zones. It's time consuming but still better than creating everything from scratch.
2. With the latest version  2.4.1, it defines source and destination zones, but not always correct, many have the same source and destination. This wasn't the case with v2.4 I believe.
3.  I forgot to rearrange the 'access-list' statement on the config file used for the last migration job, so the migrated rules have inbound and outbound rules far apart and have several other rules in between. (e.g. inside_access_in,  outside_access_in, AWS_access_in, then another inside zone rule  inside_access_out)

I don't suppose we can't do anything about with 1 or 2, especially outbound rules? This would help reduce our migration job time greatly. 

And the only way to fix 3 is on FMC GUI and do cut/paste of the rules or is there any way of rearranging the rule order so that inbound/outbound of the same zone are sequenced nicely? 

Please advise.

Many thanks, 

[Rob Ingram]

Hi @atsukane from FMC version 7.0, you can copy and paste rules between policies within the ACP/prefilter.

[andrew.butterworth]

With FMT 2.4.1 I had some rules that migrated but the destination zone was only partially correct.

For example the source ASA has the following:

Interface-X, inbound ACL permit TCP 10.1.1.0/24 TCP/* -> 10.0.0.0/8 TCP/4062

This will allow TCP traffic to enter on Interface-X from sources 10.1.1.0/24 to destinations 10.0.0.0/8 with destination TCP port 4062.  The ASA will use the routing table to determine the egress interface which could be one or multiple interfaces.

The FMT reads the original ACL and modifies it to a global ACL and adds on both source and destination zones.  The zones are equivalent to the original imported interfaces - i.e. interface-X will have an equivalent interface-X zone.  With the original ASA configuration there is no destination zone, so my understanding is the FMT uses the routing table to determine this, so it becomes:

Global ACL, source-zone, destination-zone, ACL permit TCP 10.1.1.0/24 TCP/* -> 10.0.0.0/8 TCP/4062

In the routing table is a static route to 10.0.0.0/8 which covers the rest of the customers network, however there are more specific routes and directly connected interfaces in the 10.x.x.x range.

This then requires these specific rules to have the destination zone changed to either 'Any' or all potential interfaces routes for 10.x.x.x go out of.

If your ACLs are thousands of lines long then relying on the tool isn't really an option.

Is this a bug or just by design?