5

THIS IS NOT A DUPLICATE POST/SAME QUESTION! PLEASE READ FULLY!!

Hello All,

In a recent project, a vendor we're setting up a VPN to, proposed our crypto ACL to their service be as follows:

access-list outside_30_crypto extended permit ip any any

They suggested we use an additional ACL to limit the traffic going over this tunnel. The reason they cited was because keeping the crypo ACL open like this and then limiting it with an ACL on the interface, you would cut down on the number of SA's built. How does this cut down on the number of SA's and is this the most efficient way to design VPN's?

6

The ACL associated with a point to point VPN should always contain both source and destination information. To classify "interesting traffic", that is the traffic to be protected and then sent to a remote endpoint, Cisco devices (routers and L3 swithces and ASAs oh my) will look at both source and destination addresses. If you would like a singular host to be able to send traffic to an entire remote Class C, then your ACL would look like the following:

permit ip host 192.168.1.100 10.10.10.0 0.0.0.255

If this is not specified and you just have

permit ip any any

Then how will your router know that it is not supposed to take traffic from another local sunbnet and encrypt it. Furthermore if you are running NAT on the same device, it adds further confusion. If your external IP on this VPN device is a public IP, then it also falls within the "any" statement of that ACL.

"The reason they cited was because keeping the crypo ACL open like this and then limiting it with an ACL on the interface, you would cut down on the number of SA's built. How does this cut down on the number of SA's and is this the most efficient way to design VPN's?"

This is technically incorrect, you will only have a singular SA (security association) between the devices for each tunnel, not for each individual TCP session or traffic flow.

2
  • Hey John, TY for this clarification. What you wrote is what I had thought, but the vendor engineer seemed pretty adamant about this. Good to know I'm not crazy, and we will not be doing as he said.
    – A L
    Jan 14 '14 at 21:46
  • 1
    Actually, each "flow" (src/dst element in the ACL) does generate it's own IPSEC SA. ISAKMP will only have one SA.
    – Ricky
    Jan 14 '14 at 22:00
1

Per the following Cisco documentation:

"The permit any any statement is strongly discouraged because this causes all outbound traffic to be protected (and all protected traffic is sent to the peer specified in the corresponding crypto map entry) and requires protection for all inbound traffic. Then, all inbound packets that lack IPsec protection are silently dropped, including packets for routing protocols, the Network Time Protocol (NTP), echo, echo response, and so on. You need to be sure that you define which packets to protect. If you must use the any keyword in a permit statement, you must preface that statement with a series of deny statements to filter out any traffic (that would otherwise fall within that permit statement) that you do not want to be protected"

I believe that adding those deny statements might be what they are talking about in terms of reducing the number of SA's. It makes sense to do so if you have traffic that you don't need to be protected for the sake of efficiency.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.