Solved: ACL for IPSEC tunnels

octcadmin · ‎12-05-2011

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)

eddie.harmoush · ‎12-05-2011

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.

View solution in original post

JohnTylerPearce · ‎12-05-2011

What doesn't seem to work with the ACL?

eddie.harmoush · ‎12-05-2011

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).

octcadmin · ‎12-05-2011

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.

eddie.harmoush · ‎12-05-2011

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

octcadmin · ‎12-05-2011

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.

eddie.harmoush · ‎12-05-2011

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.

octcadmin · ‎12-05-2011

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.

eddie.harmoush · ‎12-05-2011

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...

octcadmin · ‎12-05-2011

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?

eddie.harmoush · ‎12-05-2011

There is your problem right there, you are using RDP (TCP port 3389). Our ACL was constructed in a way so that only ports 1-1023 would be allowed through. To enable RDP (or any other port above 1023), you would have to add an ACL entry similar to the following:

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

Keep in mind, however, that due to the reverse allowance which happens when using a VPN filter (explained in my earlier posts), you run the risk that the remote network will be able to access your network through any port, so long as they use a source port of 3389. In the natural, there is a 1 in 64512 chance that a TCP connection will match that and happen to be let through).

Again, this is a side effect of one ACL being applied bidirectionally, and is entirely unavoidable.

octcadmin · ‎12-05-2011

Thank you that works. could you explain or point me in a direction that explains the risks above. How could the remote network access the local network with these ACL's in place?

eddie.harmoush · ‎12-05-2011