Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ACL for IPSEC tunnels

i have a CISCO ASA 5520, trying to lock down the tunnels to one direction using an ACL. It doesnt seem to work. Is this the preferred way to limit traffic?

ASA 5520

ASDM: 6.3(4)53

ASA 8.2(3)

  • Firewalling
1 ACCEPTED SOLUTION

Accepted Solutions
New Member

ACL for IPSEC tunnels

It has to do with the fact that the VPN FIlter ACL is applied bi-directionally.  Which means the ONE access-list you have applied as the VPN-Filter is governing traffic going from the LOCAL network to the REMOTE network, as well as the REMOTE network to the LOCAL network. 

This is why the ACL isn't configured using a standard source and destination, but those portions of the ACL represent the Local or Remote networks/hosts.

ex: access-list ID# permit <REMOTE ip/port> <LOCAL ip/port>

For example, consider an ACL as follows (using your local/remote networks)

access-list filter permit ip host 192.168.20.20 host 192.168.10.10

This ACL would allow the remote host of 192.168.20.20 to access the local host of 192.168.10.10.  BUT, since this is also governing traffic in the opposite direction, it is also allowing the local host of 192.168.10.10 to access the remote host of 192.168.20.20.   One ACL grants two directions of traffic.

In the case of TCP, the same applies:

access-list tunnel_lockdown permit tcp 192.168.20.0 255.255.255.0 eq 3389 192.168.10.0 255.255.255.0

This access-list matches any traffic where the remote network matches 192.168.20.0/24 TCP port 3389 and the local network matches 192.168.10.0/24 TCP port anything.

So, when your hosts initiates an RDP connection to a remote host, the source port is randomly genereated and the destination port is 3389.  This is expected and what you want. 

However, if the remote host were to initiate a web (for instance) request to your local network.  The source port would be a randomly generated number between 1025-65536 and the destination port would be 80.  There is a chance that the randomly generated source port would end up being 3389, in which case that traffic would match your VPN filter ACL and be allowed through.

For more reading, see here:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml#bidf

Hope this helps, and I'm glad you were able to get the traffic through as you wanted. Please rate the post(s) if you found my input valuable.

13 REPLIES

ACL for IPSEC tunnels

What doesn't seem to work with the ACL?

New Member

ACL for IPSEC tunnels

Easiest way is to set the option in the crypto map.  See below:

asa(config)# crypto map VPNMAP 555 set connection-type ?

configure mode commands/options:

  answer-only     Answer only

  bidirectional   Bidirectional

  originate-only  Originate only

Default is "bidirectional", where either peer can initiate the VPN tunnel. If you want only one peer/endpoint of the tunnel initiating the VPN tunnel, use one of the other options.

If you want to use an ACL to filter specific type of traffic coming through the VPN, then the best option is to use a VPN Filter (applied through a Group-Policy).

New Member

ACL for IPSEC tunnels

thanks for you reply. I would prefer to use an ACL. i have setup a group policy and assigned it to the tunnel. But it seems to block traffic both ways.

New Member

ACL for IPSEC tunnels

The vpn-filter ACL is constructed different.  Instead of what we are used to with ACLs:

access-list ID# permit

The VPN filter ACL looks like this:

access-list ID# permit <REMOTE ip/port> <LOCAL ip/port>

For example, if I wanted to only allow a local host (192.168.0.25) to access a remote host (10.10.10.99) over port 80 (www), I would have to use the following:

access-list FILTER permit tcp host 10.10.10.99 eq 80 host 192.168.0.25

Then I would apply the ACL FILTER to a group-policy

group-policy VPN-GP internal

group-policy VPN-GP attributes

  vpn-filter value FILTER

New Member

ACL for IPSEC tunnels


OK i dont understand the diffeence here, so heres what i want to do:

i have a local network: 192.168.10.0/24

remote network: 192.168.20.0/24

i want 192.168.10.0/24 to access the entire network of the remote site( 192.168.20.0/24). But i dont want the remote site to access anything from the local network (192.168.10.0/24)

so i create a group policy (tunnel_lockdown) then create a ACL (tunnel_lockdown) and add the following 2 ACE's:

"access-list tunnel_lockdown extended permit ip 192.168.20.0 255.255.255.0 192.168.10.0 255.255.255.0"

Then i assign this group policy to the tunnel.

New Member

ACL for IPSEC tunnels

The VPN-Filter ACL works differently because it has to "filter" traffic going in two directions, it is a bi-directional ACL.  Whereas regular ACL's are only applied in one direction (in or out a particular interface), so you get better granularity in using the distinction with the source and the destination.

Given that, what you are asking isn't really possible.  Even in the example I provided:

access-list FILTER permit tcp host 10.10.10.99 eq 80 host 192.168.0.25

You are allowing the local host (192.168.0.25) to access the remote host (10.10.10.99) on the remote host's port 80 (www).  But since the ACL is applied bidirectionally, you are also incidentally allowing the remote host (10.10.10.99) on source port 80 from accessing any port on the local host (192.168.0.25).

(granted, the remote host wouldn't pick a source port of 80 since it is less than 1024, but I wanted to use it as an example)

This "reverse" is unavoidable since you have one ACL being applied bidirectionally.  This is why you want to only build Site-Site VPN tunnels with other entities which you trust

You really have two options as far as I can tell, both are not ideal, but might work for what you want.

(1) Use VPN filter, allowing everything when the remote network is using ports 1-1023.  If standard TCP processing is followed, this should effectively make it so only your local segment can access the remote segment.

access-list tunnel_lockdown permit tcp 192.168.20.0 255.255.255.0 range 1 1023 192.168.10.0 255.255.255.0

(2) Disable sysopt connection permit-vpn and do your filtering on your inbound & outbound interface ACL.

no sysopt connection permit-vpn

This sysopt command will allow IPSec traffic to bypass interface ACLs.  It is enabled by default.  If you disable it, VPN traffic must match entries on your interface ACL's or it will be dropped.  Keep in mind, that this applies to the entire device, so any other VPNs you have configured will also have to have the appropriate holes punched through the interface VPNs.

New Member

ACL for IPSEC tunnels

Thanks, since i have 6 tunnels and doing different things on each. i like your first option. So i change the IP's to match what i need:

access-list tunnel_lockdown permit tcp 192.168.20.0 255.255.255.0 range 1 1023 192.168.10.0 255.255.255.0

Now all traffic is blocked both ways.

New Member

ACL for IPSEC tunnels

I'd have to take a look at your running-config to go any further.  How are you testing that traffic is blocked both ways?  Not using ICMP or anything, are you?  Because, the ACL only allows tcp at this time...

New Member

ACL for IPSEC tunnels

trying to rdp to a windows server on the remote network. If i trace a packet going this way it suceeds but i cant pass traffic such as a RDP session. I have a very long config that i would have to mask, is there a certain section that would assist?

1039
Views
15
Helpful
13
Replies
This widget could not be displayed.