FirePower pre-filter for Anti-Spoofing IP

[DavidWhite6761]

I am trying to establish a base policy on a FirePOWER deployment.

I want to introduce ANTI-Spoofing of RFC1918 addresses and all other reserved IP addresses to block anything at the Firewall with such addresses in the source.

I understand that reverse path detection can be used, but I only use a subset of RFC1918 address space internally, and don't want to introduce routes to subnets that don't exist (unless I have to).

I have created prefilter rules on the FTD to drop RFC1918 sources and all other Reserved sources, this seems to be working and logging traffic as I expected.

In a new deployment we have created a site to site VPN that has some RFC1918 addresses on the remote location, and any traffic initiated by the far end is hitting the pre-filter and being dropped.

I did not expect the pre-filter to apply to traffic that came over a tunnel.

Can anybody help with a mechanism to deploy anti-spoofing, log any such traffic on FMC, but not intercept such traffic that comes over a VPN.

[Rahul Govindan]

One way is to exempt traffic is to create a rule above the exempt rule for the RC1918 rule. But, have you tried to check the bypass access control policy under the VPN topology:

[DavidWhite6761]

Hi thanks for your response.

I did look at this option, but the text states that it would bypass the policy which is not what I need.

In effect I want to pass the pre-filter, but apply the policy to restrict specific services etc.

I have not experimented with this, and just took the text at face value!

Happy to look if you think my specific policy rules for this remote end would still be applied.

:-)

[Rahul Govindan]

In that case, the only option I see is to add a Pre-filter rule to Analyze traffic sourced from VPN subnets. This should then pass it into ACP, where you can apply application/service policies. The option that I provided bypasses the inbound rules altogether, which was the default behavior for ASA's. Only now, it is no longer default on the FTD. 

[Marvin Rhoads · Accepted solution]

Prefilter analysis occurs AFTER VPN decrypt so that's why you saw the packets being dropped.

Source: https://www.cisco.com/c/dam/en/us/td/docs/security/firepower/Self-Help/NGFW_Policy_Order_of_Operations.pdf

Generally it would be easier to filter upstream and furthermore your ISP will not normally route RFC 1918 addresses through their network. If you really want to do it on your FTD appliance, your prefilter policy should have a rule for the remote sites' addresses. Fastpath the traffic if you want to trust it completely or analyze it if you want it to be inspected by your Access Control Policy.

[DavidWhite6761]

Thanks for the response.

I would tend to agree about filtering up chain, but that is not an option for me at the moment.

I wanted to try out the pre-filter with RFC 1918 and all the other reserved address space before I moved on to the FULL Bogon list.

Sounds like I can use what I have, but I have to build a small hole in my pre-filter for every remote RFC1918 subnet at the remote end of a VPN.

Was hoping that somebody had a way of defining a VPN tunnel as an Interface so that it would drop inside the pre-filter in the processing order somehow.

Thanks for the info.

:-)