IPSEC ACLs - CRYPTO vs. Interface

[pdvcisco]

Hi,

Where an IOS device is connected to a PIX 6.3, with a site-to-site IPSec VPN, with sysopt connection permit-ipsec

Thinking it would be more simple to apply the ACLs required, I created the crypto ACL for the complete subnet with the thought I would create interface ACLs for nailing down specific hosts inside the subnet.  I now see I would need to disable the sysopt connection permit-ipsec for the interface ACLs to apply.

1. Is it more common for crypto ACLs to be more host specific vs. subnet specific, and be the ONLY ACL needed (with the sysopt enabled)? I have a real swiss cheese of hosts at each side of the vpn that need access and I didn't want to maintain such a complicated MIRRORED ACL.

2. Or is it more common for both - crypto ACLs (allow for a more simple ACL) then apply interface ACLs?

3. I see the issue with doing both interface & crypto ACLs, there is more traffic that may get sent THEN denied at the remote interface, if not blocked on the local side.  If interface ACLs are to be used, what is the best practive here?

4. I see the interface ACLs do work when the sysopt connection permit-ipsec is enabled but only on outbound traffic. Is that because the traffic hasn't hit the crypto ACL yet?

Any pointers in the right direction would be appreciated.

Thanks,

Dan Foxley

[Jon Marshall · Accepted solution]

Dan

A lot depends on whether VPN device is also acting as a firewall. If it isnt ie. once the traffic has been decrypted it is then passed onto the firewall then having sysopt connection permit-ipsec enabled is a logical choice.

In answer to your specific questions, speaking from my personal experience  -

1) crypto acls tend to be more subnet based than host based but it does depend on your specific requirements.

2) Yes, generally the crypto acl is more general, the interface acl is where you tie it down.

3) Not sure i follow. If you want to limit what traffic from within the subnet is sent down the tunnel then you would an interface acl but on a different interface ie. the interface nearer to the source of the traffic.

4) It's all to do with the order of processing ie. which is done first. Not actually used an acl outbound on the same interface as vpn termination but i suspect you are right.

Note that you don't need to apply the acl on the actual interface that the VPN terminates, at least with v7.x code and onwards. You can terminate the VPN on the outside interface and then use an outbound acl on the interface that the decrypted traffic is sent out. Yes it means it has to go throught the firewall but it can make management of your acls easier.

Jon

[Gustavo Medina · Accepted solution]

Hello Dan,

1- Yes, it's more common to see a VPN tunnel from subnet to subnet, that doesn't mean that you will rarely see tunnels from hosts to hosts though as they are kindda common too.

2-In your case since you have a PIX 6.3 the only way to restrict the VPN traffic with specific ports for example would be to disable the "sysopt connection permit-ipsec" and filter the traffic on the interface ACL.

3-Correct, for instance if you want to restrict the traffic just at the PIX site and you have the crypto ACL from subnet to subnet, the hosts behind the Router that should not have access to the hosts behind the PIX will start sending traffic, this traffic will get encrypted on the Router as you don't have any rule there saying this is not allowed but when those packets get to the PIX if you have the sysopt command disabled interface ACL rules will apply and the traffic will then get dropped.

4- By default, the security appliance allows VPN traffic to terminate on a  security appliance interface; you do not need to allow IKE or ESP (or  other types of VPN packets) in an interface access list. By default, you  also do not need an interface access list for local IP addresses of  decrypted VPN packets. Because the VPN tunnel was terminated  successfully using VPN security mechanisms, this feature simplifies  configuration and maximizes the security appliance performance without  any security risks.

You can require an interface access list to apply to the local IP addresses by entering the no sysopt connection permit-ipsec command. The access list  applies to the local IP address, and not to the original client IP  address used before the VPN packet was decrypted.

The best practice is to use VPN-FILTERS unfortunately this cannot be done in 6.3 code.

A vpn-filter is applied to post-decrypted traffic after it exits a tunnel and pre-encrypted traffic before it enters a tunnel.  An ACL that is used for a vpn-filter should NOT also be used for an interface access-group.

When a vpn-filter is applied to a group-policy that governs a LAN to LAN VPN connection, the ACL should be configured with the remote network in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.  Caution should be exercised when constructing the ACLs for use with the vpn-filter feature.  The ACLs are constructed with the post-decrypted traffic in mind, however, they are also applied to the traffic in the opposite direction.  For this pre-encrypted traffic that is destined for the tunnel, the ACLs are constructed with the src_ip and dest_ip positions swapped.

For example:

Let's use a vpn-filter with a LAN to LAN VPN connection.

Assume that the remote network is 10.0.0.0/24 and the local network is 192.168.1.0/24.

The following ACE will allow remote network to telnet to the local network:

access-list vpnfilt-l2l permit tcp 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0 eq 23

The following ACE will allow the local network to telnet to the remote network:

access-list vpnfilt-l2l permit tcp 10.0.0.0 255.255.255.0 eq 23 192.168.1.0 255.255.255.0

Note:

The ACE access-list vpnfilt-l2l permit tcp 10.0.0.0 255.255.255.0 192.168.1.0 255.255.255.0 eq 23 will allow the local network to initiate a connection to the remote network on any TCP port if it uses a source port of 23.

The ACE access-list vpnfilt-l2l permit tcp 10.0.0.0 255.255.255.0 eq 23 192.168.1.0 255.255.255.0  will allow the remote network to initiate a connection to the local network on any TCP port if it uses a source port of 23.

Another option is to use crypto ACLs to filter the traffic on the Router:

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_crypto_ac_clrtxt_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1061725

Regards,

[pdvcisco]

Gustavo,

Thanks, that clarifies it for me.

Under the assumption I'd like to filter traffic on the router.  Is there a preference of which of the two below I choose to implement on the router?

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_crypto_ac_clrtxt_ps10591_TSD_Products_Configuration_Guide_Chapter.html#wp1056387

New IPSec ACL Configuration Without Crypto Access ACLs: Example

New IPSec ACL Configuration with Crypto Access ACLs: Example

[Gustavo Medina]

I'm glad we could help!

I was refering to: New IPSec ACL Configuration with Crypto Access ACLs: Example

Regards,

[pdvcisco]

Gustavo,

Giving this a go...

In setting this up can you point me to what the difference in these ACLs are? This is from the example:

access-list 151 permit tcp 10.1.2.0 0.0.0.255 eq telnet 10.1.1.0 0.0.0.255

access-list 151 permit tcp 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255 eq telnet

Thanks,

Dan

[Jon Marshall · Accepted solution]

Dan

access-list 151 permit tcp 10.1.2.0 0.0.0.255 eq telnet 10.1.1.0 0.0.0.255

means permit tcp packets with a source IP of 10.1.2.x and a source port of 23 (telnet) to
any device on the 10.1.1.x network on any port 

access-list 151 permit tcp 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255 eq telnet

means permit tcp packets with any source port to any device on the 10.1.1.x network with
a desitnation port of 23 (telnet)

so basically - 

the first allows return telnet traffic from 10.1.2.x to 10.1.1.x
the second allows traffic from 10.1.2.x to telnet servers on the 10.1.1.x network

Jon

[pdvcisco]

Doh!..thanks.