02-05-2025 06:30 AM
Hello Together
I have FMC/FTD and when I create a VPN via Policy Based (crypto Map) and use "Protected Networks" -> "Subnet / IP Address" everything works fine. VPN -> Azure, VPN -> other Companys and our Branch Offices, no Problem.
When I use instead "Protected Networks" -> "Access List (Extended)" No chance to get a connection. Tunnel comes up, but connection is not possible.
Does anyone have a recommendation how to use ACL List or maybe a Link to a Document? Cisco recommend to use "Access List (Extended)" Or what could be wrong. Settings are identical with "Subnet / IP Address" and "Access List"
Regards
Ralph
02-05-2025 09:32 AM - edited 02-05-2025 09:44 AM
Find this document for you might it will put you in right direction and will answer the question you have
https://www.ateam-oracle.com/post/policy-based-vpn-on-cisco-ftd
https://docs.defenseorchestrator.com/cdfmc/t-configuration-example-for-policy-based-routing.html
The difference between "Access List (Extended)" and "Subnet / IP Address" is that in Access List Extended the IPS rules are matched (example allow/deny/trust/monitor) where as in the Subnet/IP address they are exempt from the matching of any IPS just like completely by-pass them.
02-10-2025 01:16 AM
Ok, thanks for the Link, Now some things are clear. But I thought the IPS by-pass option was this in "Advanced -> Tunnel -> Access Control for VPN Traffic". Hope the Photo will show it
02-10-2025 01:31 AM - edited 02-10-2025 01:51 AM
This by-pass is for more protocol port/s specific compare of IPS. This by-pass is inherited from ASA code. So the by-pass check (permit or deny) based on Network layer and transport layer only. Compare the IPS check layer 7 inspection. Hope this helps.
02-10-2025 03:52 AM
This option is just to allow the VPN traffic to bypass the outside interface access list. If you happen to disable it you will have to explicitly allow the VPN traffic on the outside interface access list. The equivalent of this on the ASA is the "sysopt permit-vpn" command which is applied by default.
Why would you need to use the access lists instead of the subnets? I'm not a 100% sure about why using the access lists as the protected networks didn't work for you, but looking at the following link I understand that using the access lists should be done on both sides which doesn't seem to be the case here. Also, could you please share how you created that access list for review?
"You must configure all nodes in a topology with either crypto ACL or a protected network. You cannot configure a topology with crypto ACL on one node and protected network on another."
02-10-2025 05:59 AM
Hello Aref,
we had a discussion with TAC and an external Company about this and the recommendation was to use "Extended access list" because of better handling the Ports,Networks etc. This is a good advice in the Phrase "You must configure ...." So we had tunnels to Azure, External Companys and on Branch Offices. Protected Networks works for me but it looks like a little bit "unsecure".
Here is a basic "Extended Access List" Ports follow when I get a connection over this
02-10-2025 06:03 AM
oh sorry forget somethings
02-10-2025 06:19 AM
I tend to disagree on this :). The crypto ACLs wouldn't be intended to filter the VPN traffic. My recommendation would be configuring the tunnels with the subnets as you've already done and then apply VPN-Filter to restrict what traffic you want to allow on the tunnel. The VPN-Filter uses extended access lists, so you can narrow down the accesses as you wish. If I remember correctly when you create the VPN-Filter ACL you put the remote subnet in the source and the local subnet in the destination, kinda you flip them around. Another thing to keep in mind with the VPN-Filter is that when you add a deny statement while the tunnel is up it will immediately take effect, however, when you permit something while the tunnel is up it won't, so in that case you need to reset the tunnel before the newly added permit entries take effect.
"The VPN filter provides more security and filters site-to-site VPN data using an extended access list. The extended access list object selected for the VPN filter lets you filter pre-encrypted traffic before entering the VPN tunnel and decrypted traffic that exits a VPN tunnel. The sysopt permit-vpn option, when enabled, would bypass the access control policy rules for the traffic coming from the VPN tunnel. When the sysopt permit-vpn option is enabled, the VPN filter helps in identifying and filtering the site-to-site VPN traffic."
02-10-2025 06:33 AM
@Aref Alsouqi @That’s a good observation and spot on I agree with your findings compared to what TAC had suggested to OP.
02-11-2025 01:29 AM
by the way, maybe TAC recommendation was for the specific situation. Don´t know. @Aref Alsouqi VPN-Filter, do you mean the Prefilter Settings in Policy? Because I was astonished that I don´t have any Rule (for Protected Networks) and traffic pass from both sides seems without control. And many thanks for your help, I appreciated absolutley
02-11-2025 02:23 AM
you can double check with TAC if your case is close you still have grace period of 14 days to reopen it again and work with your TAC engineer.
coming back to you question, VPN filters use extended ACLs to control traffic entering and exiting VPN tunnels on Cisco ASA/FTDs. Configure ACLs with remote subnets as source and local as destination (as describe/mentioned by @Aref Alsouqi ) Deny rules take effect immediately, but permit rules require a tunnel reset. Remember the implicit deny and use/tick mark in FTD/FMC tunnel settings "sysopt connection permit-vpn".
Prefilter policies serve as the initial layer of access control in Cisco FTDs, enabling rapid/fast traffic filtering or allowance at Layer 3/Layer 4 without performing deep packet inspection. This approach is particularly efficient for managing specific types of traffic, such as ICMP or Telnet etc, before subjecting it to more resource-intensive access control processes. In your case No you need to look at the tunnel settings.
02-11-2025 02:37 AM
Hi Ralph. No VPN-Filter is not part of the platform settings, it is instead part of the site to site VPN configuration. As per the link I shared above it is part of the advanced settings of the tunnel you configure. What version of FMC are you running? if your running version doesn't support VPN-Filter via the UI, then you can still apply the VPN-Filter via FlexConfig.
Alternatively, you can disable the bypass access control option (the one in the screenshot you shared) and then configure explicitly the traffic that should be allowed over the tunnel. In that case the security rules would need to be applied to your outside interface in inbound direction and if you want you can apply also some rules on the inside interface still in inbound direction.
02-11-2025 04:36 AM
We have FMC/FTD Version 7.4.2 Build 172. But do I configure the Traffic in the Policy -> Access Control Rule? I am not a great Fan of FlexConfig
02-11-2025 05:37 AM
Here this is how is see it. Happy to be correct by my other peer/s. who also have extensive knowledge on the firewalling. I think your best bet is use the Extended Access-list as employing the Extended access-list you are in more control and with having inspection of IPS (Layer-7) traffic. this will give you more control and more visibility once you create the rule with port filtering.
02-11-2025 06:56 AM
That makes two of us that aren't fan of FlexConfig, but luckly in this case you don't need FlexConfig as your FMC should already support the VPN-Filter on the UI.
No it's not the normal access control policy. If you open up the site to site VPN settings and you click on node A pencil and then you scroll down to the very end you will see a hidden section called "Advanced Settings". Open up that section and you will see the VPN-Filter. From there you click on the plus sign to add the VPN-Filter access list.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide