FTD Remote Access VPN Filtering

[dm2020]

Hi All,

I'm currently deploying Cisco Secure Client Remote Access VPN on FTD and I'm trying to decide if to use the Access Control Policy for filtering VPN traffic or if to bypass the Access Control Policy (sysopt connection permit-vpn) and use traditional ACL

I was leaning towards the ACP as this will allow more granular filtering (user identity, ips etc), however I noticed the following security consideration within the AnyConnect Remote Access VPN on FTD Guide.

https://www.cisco.com/c/en/us/support/docs/network-management/remote-access/212424-anyconnect-remote-access-vpn-configurati.html

Security considerations
By default, the sysopt connection permit-vpn option is disabled. This means, that you need to allow the traffic that comes from the pool of addresses on outside interface via Access Control Policy. Although the pre-filter or access-control rule is added to allow VPN traffic only, if clear-text traffic happens to match the rule criteria, it is erroneously permitted.

There are two approaches to this problem. First, TAC recommended option, is to enable Anti-Spoofing (on ASA it was known as Unicast Reverse Path Forwarding - uRPF) for outside interface, and secondly, is to enable sysopt connection permit-vpn to bypass Snort inspection completely. The first option allows a normal inspection of the traffic that goes to and from VPN users.

Based on the above, to allow traffic from RAVPN (which is on the outside network) to my internal servers I would need to add a rule similar to the following which will allow any traffic from my RAVPN Pool on the outside network to my inside servers. Is this a valid security concern and can this be subject to spoofing? Has anyone else configured this before without any concerns or issues?

Source Zone: Outside

Source Network: RAVPN_Pool (192.168.1.0/24)

Destination Zone: Inside

Destination Network: Servers

[MHM Cisco World]

No need ACP you can use traffic filter in advanced tab of vpn profile

MHM

[Rob Ingram]

@dm2020 defining rules in the Access Control Policy is the standard/recommended method to permit traffic over the VPN, as you mentioned you can then apply L7 filters or use user authentication in the rules (if required).

The sysopt connection permit-vpn command is a global command, meaning if you enable/disable it for RAVPN it will be enabled/disabled for other VPNs.

[dm2020]

Thanks Rob,

I suppose what I'm trying to work out is the risk of using the ACP as we have to configure outside to inside rules although with the private RAVPN pool specified as the source network as opposed to a public address. Is spoofing as detailed in the above Cisco document a legitimate risk? If so, to lessen that risk, should we apply L7 filters and user auth in the rules as you say, along with anti-spoofing as per the TAC recommendation in the document?

[Rob Ingram]

@dm2020 hopefully your ISP should block RFC1918 address space, so any spoofed traffic from outside would be dropped before it hits the FTD. Certainly apply uRPF as Cisco recommend, configuring user authentication is a bonus and worthwhile anyway.

[lcaruso]

Hi Rob,

Regarding the global implications of the sysopt permit-vpn setting, in FTD v7.4.2.1 there is a checkbox under each site to site tunnel definition to enable/disable this feature. I had been under the impression this works per tunnel. Do you know if it can now be set on a tunnel by tunnel basis or is this checkbox vaporware? 

Also seeking to confirm order or operations when no sysopt permit-vpn is used for a tunnel and ACP rules are used, STS traffic initiated locally that is outbound is first submitted to the ACP, and if allowed, then passed on to the Cryptomap. If the traffic passing the ACP is also in the Cryptomap, it is encrypted and enters the tunnel. Return traffic is not stateful and must also pass ACP rules first then is passed to Cryptomap and decrypted. Traffic initiated from the far end, not being exactly the same, would require a different set of ACP rules. Is this correct?

Finally, if a given subnet in the STS ACP rules is denied while other subnets are allowed, then the traffic from that subnet would not be passed to the Cryptomap and into the tunnel even if that subnet was allowed in the Cryptomap?

The availability of vpn filters in FTD seems unnecessary when you can turn off sysopt permit-vpn on a per tunnel basis, so I guess they are used with a tunnel must use sysopt permit-vpn for some reason and then you can use ACLs to deny/permit traffic to the tunnel like an ACP rule would also do. 

Thanks to all who take time to comment. 

[Rob Ingram]

@lcaruso that command is NOT per tunnel as the GUI might suggest -  https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh30385 There is currently no work around. The sysopt permit-vpn must be enabled globally or not at all.

Return traffic is stateful and would be permitted. A new connection initiated from the remote peer needs to be permited by the ACP.

Yes, if traffic is denied by the ACP then is would not hit the crypto map to be encrypted.