cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9755
Views
18
Helpful
7
Replies

ASA site to site VPN deny access for 1 host

lplancherel
Level 1
Level 1

Hello,

Here is my setup. I have a running site to site VPN working from our office to a contractor company, the crypto map acl is configured to allow all the subnet on both side like:

access-list Outside_cryptomap_3 line 1 extended permit ip 10.50.1.0 255.255.255.0 192.168.160.0 255.255.240.0

the VPN is working fine, but now I want to deny the access to a specific host in our subnet (10.50.1.50) from the whole contractor subnet, how can I do that ? If I do firewall rules on the inside or ouside interface it has no effect.

Thank for your help !

1 Accepted Solution

Accepted Solutions

Just for the sake of completion, there are actually 2 ways you can achieve this.

As you have noted; unless you disable the sysopt connection permit-vpn setting, ALL traffic which matches the crypto ACL for that peer is allowed over the VPN by default.

So, one way to address that is indeed to disable this, which will then use the ACLs.

The alternative method is with VPN filters. Say 10.50.1.10 is the host which you want to ensure can't be reached, it might look something like this:

access-list VPN-FILTER extended deny ip 192.168.160.0 255.255.240.0 host 10.50.1.10
access-list VPN-FILTER extended permit ip any any

group-policy CRYPTOMAP-3-POLICY internal
group-policy CRYPTOMAP-3-POLICY attributes
 vpn-filter value VPN-FILTER

tunnel-group X.X.X.X general-attributes
 default-group-policy CRYPTOMAP-3-POLICY

This is best used when wanting to filter traffic FROM the remote side TO you. You can do the other way around but it gets messy. Often I have seen VPN filters to filter inbound traffic, but then using the local interface ACL to restrict access to the other side.

Probably not really much use now that you have fixed it, but it's always nice to know these things I think :)

View solution in original post

7 Replies 7

lplancherel
Level 1
Level 1

I might have found the answer, please correct me if I'm wrong. Here is what I think I must do (in asdm):

- under site-ti-site VPN -> Group Policies edit the existing policy used by my VPN

- Uncheck "Inherit" for filter and click manage

- Under the Extended ACL tab click Add ACL and name it

- choose this new ACL then click add ACE

- create the ACE with source the contractor network and dest the IP of the server I want to block and deny the traffic

- Finally choose the new ACL for the group policy filter

Am I correct ?

Thanks !

answering to myself again :-) 

I found this post which provide good information about VPN traffic filtering, apparently the procedure I described above is correct as I dont have no sysopt connection permit-vpn configured..

https://supportforums.cisco.com/discussion/11769001/vpn-filter-v-interface-acls-asa-5525

Hi,

Yes you are correct and we need to disable the sysopt connection permit-vpn command so that we can access-list in the group-policy takes affect.

More info :

http://www.cisco.com/c/en/us/support/docs/security/pix-500-series-security-appliances/99103-pix-asa-vpn-filter.html

Regards,

Aditya

Please rate helpful posts and mark correct answers.

Just for the sake of completion, there are actually 2 ways you can achieve this.

As you have noted; unless you disable the sysopt connection permit-vpn setting, ALL traffic which matches the crypto ACL for that peer is allowed over the VPN by default.

So, one way to address that is indeed to disable this, which will then use the ACLs.

The alternative method is with VPN filters. Say 10.50.1.10 is the host which you want to ensure can't be reached, it might look something like this:

access-list VPN-FILTER extended deny ip 192.168.160.0 255.255.240.0 host 10.50.1.10
access-list VPN-FILTER extended permit ip any any

group-policy CRYPTOMAP-3-POLICY internal
group-policy CRYPTOMAP-3-POLICY attributes
 vpn-filter value VPN-FILTER

tunnel-group X.X.X.X general-attributes
 default-group-policy CRYPTOMAP-3-POLICY

This is best used when wanting to filter traffic FROM the remote side TO you. You can do the other way around but it gets messy. Often I have seen VPN filters to filter inbound traffic, but then using the local interface ACL to restrict access to the other side.

Probably not really much use now that you have fixed it, but it's always nice to know these things I think :)

AFAIK VPN filters are bidirectional, i. e. they block the traffic regardless of which side initiates the connection

You are quite right in that VPN filters do work both ways, but in my experience they can become very messy when doing this, for example you end up with lots of rules like this:

FW1
---

access-list VPN-FILTER extended permit tcp host 10.10.10.10 host 192.168.10.10 eq ssh
access-list VPN-FILTER extended permit tcp host 10.10.10.10 eq ssh host 192.168.10.10

FW2
---

access-list VPN-FILTER extended permit tcp host 192.168.10.10 eq ssh host 10.10.10.10
access-list VPN-FILTER extended permit tcp host 192.168.10.10 host 10.10.10.10 eq ssh

The unusual thing with VPN filters when compared to a regular interface ACL is that you have one access list that is actually applying to traffic in both ways at the same time, hence why you need rules like the above. Technically speaking when you have a VPN filter you're applying it to all interfaces in all directions at the same time as you can control access to any resource behind your firewall for a given tunnel.

The ACLs are still stateful, so it's not like it's there to permit the return flow, it's just that it is trying to filter both ways in this case. So in this example allowing SSH from one side to the other, in both directions.

So in summary...they can become very confusing so I try to keep them to a minimum and typically only use them for filtering remote connections inbound, unless I really have to do both ways.

VPN filter ACLs have this structure:

access-list VPN-FILTER extended permit tcp host remote host local eq ssh

Of course this single line will not allow SSH from Local LAN to remote server (unless the client initiates it with a source port of 22 which is unlikely)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: