Exclusion from IPSec tunnel
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 05:55 AM - edited 02-21-2020 06:35 AM
hi,
We have IPSec tunnel on ASAs between our two sites over the internet. I want to exclude communication between two hosts from being encrypted in IPSec. I thought if I add a "deny" statement on top of interesting traffic ACL it would work fine. But, it is till using the tunnel and I do not see ACL hits on the deny ACL.
Is there anything wrong with this approach?
- Labels:
-
NGFW Firewalls
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 07:02 AM
The crypto acl is used to build the L2L vpn. If you want to filter communication you have 2 choices.
Solution 1:
- the command sysopt connection permit-vpn is enabled on your ASA and allowing communication between the 2 sites over VPN without being filtered by ASA ACLs. You can deactivate that feature and you will need to build the rules to allow the traffic you want (by default if no rules, there is a deny).
Solution 2:
Create and acl vpn-filter. Here a sample of the config. Let's assume your site A has the host 1.1.1.1 and site B has the host 2.2.2.2. Network site A is 1.1.1.0/24 and site B is 2.2.2.0/24. You want everyone should communicate with each others except the the 2 hosts mentioned before.
Sample config on ASA site A. (On site B it will be the same, just invert the acl host directions). The vpn-filter acl is filtering inbound only, the outbound will be done automatically.
access-list L2L-FILTER extended deny ip host 2.2.2.2 host 1.1.1.1
access-list L2L-FILTER extended permit ip any any
!
group-policy CRYPTO-L2L internal
group-policy CRYPTO-L2L attributes
vpn-filter value L2L-FILTER
!
tunnel-group {Your Remote Public IP} general-attributes
default-group-policy CRYPTO-L2L
Hope that helps.
Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 07:03 AM
There were 2 bugs in the ASA code that caused this to fail in earlier 8.2 releases:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCud32111/?referring_site=bugquickviewredir
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuc97552/?referring_site=bugquickviewredir
That being said, if you are using an ASA, try running the packet tracer between the 2 hosts to see if this traffic is being matched by crypto map or not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 12:33 PM
I do not have "sysopt connection permit-vpn" enabled, and still can't get it to work.
The ASA code I am running is the latest 9.7.1.8.
I ran a packet tracer but it did not show me anything related to IPSec tunnel.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 01:01 PM - edited 10-26-2017 01:04 PM
Hi,
I run into this issue a lot and to fix it I usually reload my ASA. When it comes back, I find that the deny statement takes effect. Worth a shot in my opinion.
Add the deny statement in your crypto ACL as line 1. Write mem. Reload. Test.
In my experience you can't trust an ASA to treat VPN configurations made via the CLI properly, and that frustrates me because I hate GUI. So when my ASA starts behaving illogically and I can't find anything wrong, first thing I do now is reload it and that fixes it 80% of the time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 02:57 PM
Just to make sure, can you run a packet-tracer paste all steps you see you validate that everything is fine?
Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-26-2017 05:05 PM
packet-tracer input <Inside-interface> tcp host <inside-ip> <src port> <outside-ip><dst port> detailed
