SFR Redirect

[Steven Williams]

I have inherited an Edge ASA with SFR sourcefire and I am trying to make sense of the "redirect" ACL within the ACL. 

I have a feeling its like WCCP was when that was the cool thing to do, where you actually "permit" what networks you want to redirect to the wccp endpoint. Is it the same for SFR redirect?

Also if I am tunneling my Anyconnect VPN traffic, how do I filter that traffic? Same method? redirect that subnet to SFR and build policy for it?

[Abheesh Kumar]

Hi, 

Traffic redirection to SFR via service policy only not through wccp.

Create an ACL for which traffic you need to filter via SFR module and map to the service policy. You can filter anyconnect traffic also via the redirection ACL. below link will help you for filter Anyconnect VPN traffic via SFR module

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/211294-Configure-ASA-with-FirePOWER-Services-Ac.pdf

HTH

Abheesh

[David Castro F.]

Hello Steven,

How I would recommend you to do it is to first off:

1. Make the SFR only monitor and logg traffic, so you can create on access policies rules for the different zones to only monitor and the IPS policy uncheck the "would drop" check, so It can also provide you with feedback if it would drop traffic for some reason.

2. Regarding the redirect, as stated before it is configured through MPF feature:

access-list redirect.....

class-map SFR-Redirect

 match access-list redirect

policy-map SFR

 class map SFR-redirect

And then you can apply it under the global service policy,

Now with regards the AnyConnect, you dont need to allow it to go there inmediately, on the ACL dont add it, and after you get the requirement make sure to add it, and the traffic will be inspected but of course add rules to make that happen as you stated before.

Keep us posted,

Please rate all helpful answers, and mark as correct the answer that answered this,

Thanks,

David Castro,

[Steven Williams]

There are already policies in place and I am trying to wrap my head around them. 

What is mandatory vs default?

What are the different actions, I mean get allow and and block, but I see some rules that are "trust" but they are the same networks for source and destination so what does that mean? Why would there be a rule from the same source networks to the same destination networks, they shouldn't cross a firewall at all being the same layer 2 domain.

[David Castro F. · Accepted solution]

Hello Steven,

Let me answer all of your questions, 

What is mandatory vs default?

These are 2 categories created, but they worked the same, now what they do is to organize your rules properly, for example:

Mandatory:

- Company policies: restrict the access to porn/sport/social media and so on.

Default:

- This is most likely where all of the rest rules are created, for example access from a VLAN to another VLAN and if you want to inspect that with IPS and also inspect files through file inspection with AMP.

What are the different actions, I mean get allow and and block, but I see some rules that are "trust" but they are the same networks for source and destination so what does that mean?

Allow is basically allowing the traffic in the rule to be inspected by IPS, normalization, AMP, NAS and so on.

Block this would just block the traffic inmediately with no further inspection and so on.

Trust this rule would bypass inspection of any sort and will just allow the traffic inmediately.

Why would there be a rule from the same source networks to the same destination networks, they shouldn't cross a firewall at all being the same layer 2 domain.

You are right, if you have devices within the same L2 domain it wont go the FW, unless you have 2 DCs and you have an extended VLAN, but in this scenario that wont work.

Keep me posted,

Please rate all helpful posts, and mark as correct if this answered your question,

Thanks,

David Castro,

[Steven Williams]

Seems the last engineer set this up so the same source and destination networks were setup with a trust because the ASA was the gateway for those networks, but I am not sure you should group the networks together? Not sure about that though.

The mandatory and default makes sense now, but I assume most default rules are a deny any any as a clean up rule.

[David Castro F.]

Hello Steven,

I hope you are doing great, thanks for marking the answer as answered.

Seems the last engineer set this up so the same source and destination networks were setup with a trust because the ASA was the gateway for those networks, but I am not sure you should group the networks together?

- If this a SFR module, not all traffic is mandatory to get into the SFR module, you can bypass that by adding denies at first lines of the ACL of the redirect, why I am telling this because when you set up an access control as trust there is not inspection at all, so it is unnecessary that the traffic get to the SFR module. Now the access control rules are the same as the ACLs, you allow or deny what you need to deny, if you are doing monitoring for all the zones then grouping is fine, but if you want only 2 hosts to talk to each other then do it individually per rule and not grouping them.

but I assume most default rules are a deny any any as a clean up rule.

At the end of the rule there is a drop down with some options whether a deny as a clean up rule or to pass the traffic through an IPS policy:

This example is blocking all of the traffic as a clean up rule.

Keep me posted Steven,

Please dont forget to rate all of the helpful posts!

Regards,

David Castro,

[Steven Williams]

I think I am getting confused. There is the SFR redirect ACL that sits in the ASA OS, this is what tells the ASA to push that traffic to the SFR. Then there is the SFR software itself that has its own ACLs which I will NOT see in the ASA CLI. So the engineer setup a rule in the SFR software that says NetworkA and NetworkB has access to NetworkA and NetworksB and the action is "trust"

[David Castro F.]

Hello Steven,

Your comment below:

There is the SFR redirect ACL that sits in the ASA OS, this is what tells the ASA to push that traffic to the SFR.

- Yes, The ACL has a permit action allowing the traffic to be redirected from the ASA to the SFR module, now if you want to bypass the SFR module you could add ACL entries at the beggining stating that traffic from network A to network B is denied and the other way around, this is stating that the traffic wont go through the SFR for further inspection.

access-list SFR extended line 1 deny ip obj-networkA obj-networkB

access-list SFR extended line 2 deny ip obj-networkB obj-networkA

Below I will explain why I am explaining the above information.

Then there is the SFR software itself that has its own ACLs which I will NOT see in the ASA CLI. So the engineer setup a rule in the SFR software that says NetworkA and NetworkB has access to NetworkA and NetworksB and the action is "trust"

The SFR has NGFW Rules which is referred as Access control policies, and the rule you explain above is grouped and it is fine. Now what is not fine for me is that is "trusting", this means that the traffic is not being inspected at all, and just bypassing inspection. Thats why I recommended the above, if you are not supposed to inspect the traffic from network A to Network B and viceberza, then proceed to bypass the traffic from the ASA with the denies, so you dont get your traffic going through the SFR module unnecesarily and provoking possible throughput issues in the future. Now it is not a requirement to trust the traffic and take advantage of the SFR module, then you would want to change the action from trust to allow and add IPS inspection to it.

Let me know if you have any other questions on this,

Thanks,

David Castro, 

[Steven Williams]

Now I see what you are saying. If the intent is NOT inspect traffic with the SFR don't send it there in the first place, just unnecessary traffic going through the SFR, now if I wanted to see what what was going between those networks I could send it to the SFR but "monitor" it.

So like vlans on trunks, if the vlan doesn't live on the other side of the trunk , prune it from the trunk because it will just be dropped on the other end anyway.

I hope I understand now.

[David Castro F.]

Hey Steven,

Exactly, this trust is most likely used with the FTD (Firepower Threat Defense) where this is the firewall and there is not ASA, so you can bypass the inspection for certain flows that you think that dont require. Monitor is fine for at least 15 days, set up a some reports so you can see the data and start creating some rules, to limit some traffic, and with IPS there are "Firepower recommendations" which it applies IPS policies with the devices that the FMC with the network discovery policy has discovered.

I hope this was helpful Steven, keep me posted man!

Please rate all helpful posts!

David Castro,

[Steven Williams]

We have not moved to FTD as of yet, but it is coming as our Core 5585-x is EOL/EOS. I assume FTD will be very similar to how Palo Alto works since it will be all GUI. But time will tell.

[David Castro F.]

It actually works alike, it has some limitations, but many new features, and also with 6.3... coming with instances similar to contexts.

Hopefully the migration will be smooth.

[Steven Williams]

I just don't think its going to be a great transition of change for us PIX/ASA CLI guys. I mean I can insert 50 lines of code in seconds and maybe 25 of those being object groups, now we are talking about taking my current rules and moving them to a point and click method. I am not sure Cisco thought that through and I think focused on the appeasing the "the general network admin" who doesn't want to learn CLI because he thinks its programming.