cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1394
Views
10
Helpful
10
Replies

ACL config for site to site tunnels on ASA

mjsully
Level 1
Level 1

I need some clarification on access-list for vpn traffic on an ASA. Let me explain my situation. First off, I will not be using the "sysopt connection

permit-ipsec" on the firewall, so if my understanding is correct, I need interface based access-lists to allow the traffic in addition to my VPN interesting traffic access-lists.

So let's say I have an ASA with 2 interfaces in use, inside and outside. I have an inside and outside access-list applied to both interfaces controlling traffic. The crypto map is applied to the outside, and I have two site to site tunnels that are needed on the ASA.

My first tunnel requires that my inside subnet 192.168.100.0/24 be able to talk to the remote subnet across vpn, 172.16.1.0/24. So here is my crypto map acl for this tunnel. The inside local subnet will always initiate to the remote end.

access-list tunnelA permit ip 192.168.100.0 255.255.255.0 172.16.1.0 255.255.255.0

My second tunnel requires that the remote subnet 10.255.255.0/24 always initiate connections back to my local subnet 192.168.100.0/24, so here is my crypto map acl for this tunnel.

access-list tunnelB permit ip 192.168.100.0 255.255.255.0 10.255.255.0 255.255.255.0

I think I have the above config correct, but here is where I'm a little confused about not using the sysopt permit ipsec.

Seeing how I have acl's applied to both interfaces, I assume for tunnel A I need to basically apply the same acl as I did for the crypto map acl:

access-list inside_out permit ip 192.168.100.0 255.255.255.0 172.16.1.0 255.255.255.0

If I am correct on that, what about tunnel B, where the remote subnet initiates in this case? do I need to put my acl on the outside interface like this?

access-list outside_in permit ip 10.255.255.0 255.255.255.0 192.168.100.0 255.255.255.0

basically I need to know how to apply my interface based acl's, and is it dependent on which side of the tunnel initiates vs which receives?

10 Replies 10

Jon Marshall
Hall of Fame
Hall of Fame

You are correct in that with "no sysopt connection permit-vpn" the acl on the outside interface comes into play. Or more precisely if the interface that the VPN terminates on has an acl this acl will be bypassed.

So your acl's are correct. For tunnelA if you have an access-list on your inside interface you will need to add

access-list inside_out permit ip 192.168.100.0 255.255.255.0 172.16.1.0 255.255.255.0

Note that the above is nothing to do with sysopt connection permit-vpn setting at all, it is just that you have an outbound access-list already applied.

and for tunnelB you will need as you say on the acl on the outside interface

access-list outside_in permit ip 10.255.255.0 255.255.255.0 192.168.100.0 255.255.255.0

The subnets are flipped around from the crypto map access-list for this tunnel which is exactly what you have done.

Note that usually the reason for having "no sysopt connection permit-vpn" is so that the acl on the interface that VPN terminates on can then filter the decrypted traffic.

So you use "permit ip" in your crypto map acl and then you narrow down the traffic using tcp/udp ports on your interface acl.

Jon

Good explanation, thanks. So based on what you are saying, as long as I am NOT using the "sysopt connection permit-vpn", then an ACL defining the remote vpn traffic IS necessary on the interface that my crypto map is applied, in this case the outside?

My situation is actually preparing to move a large number (over 100) of VPN tunnels from a VPN concentrator to the ASA. So if I am not using sysopt, then it is necessary that I identify all of the tunnels in which traffic is initiated from the remote side? Correct?

"So based on what you are saying, as long as I am NOT using the "sysopt connection permit-vpn", then an ACL defining the remote vpn traffic IS necessary on the interface that my crypto map is applied, in this case the outside?"

Correct

"My situation is actually preparing to move a large number (over 100) of VPN tunnels from a VPN concentrator to the ASA. So if I am not using sysopt, then it is necessary that I identify all of the tunnels in which traffic is initiated from the remote side? Correct?"

Correct again :-).

Bear in mind that you can use outbound access-lists as well so this could help eg.

lets say that for 80 of your tunnels you don't really need to filter the traffic but you do for 20. Easiest way would be to

1) allow "sysopt connection permit-vpn"

2) Create an outbound access-list for the inside interface that then filters the traffic for the 20 tunnels you need to filter traffic for.

This may or may not be of use to you.

Edit - on rereading my original post i can see how you may have got confused ie.

"You are correct in that with "no sysopt connection permit-vpn" the acl on the outside interface comes into play. Or more precisely if the interface that the VPN terminates on has an acl this acl will be bypassed"

This should have said with "sysopt connection permit-vpn" enabled the acl would be bypassed. Apologies for that.

Jon

ok, just to clarify, you said:

"Create an outbound access-list for the inside interface that then filters the traffic for the 20 tunnels you need to filter traffic for."

I'm assuming you are speaking of if I want to filter outgoing traffic from my local LAN? If I wanted to filter 20 out of the 100 tunnels, and those tunnels were inbound, then I'd just move the filter to the outside interface?

No, the point i was trying to make was this.

You have 100 tunnels. If you do a "no sysopt connection permit-vpn" on the ASA then you have to add the permitted traffic for each of the 100 tunnels to an acl on the outside interface.

But say you really don't care about filtering 80 of the tunnels. A quicker way to configure would then be to

1) configure "sysopt connection permit-vpn" on your ASA. This means an acl on the outside interface is bypassed so you don't need to have an acl with the traffic for 100 VPN tunnels.

2) But you also have 20 VPN tunnels that you want to filter. If you filtered them on the outside interface then you have to configure "no sysopt connection permit-vpn" and then you are back to the original issue. Even though you don't care about filtering the other 80 tunnels you still have to add their traffic to the outside acl or it will get dropped. So ...

you write an acl allowing only the traffic you want for the 20 VPN tunnels. You then apply this in the outbound direction on the inside interface. So traffic for these tunnels gets decrypted on the outside interface, bypasses the outside interface acl because of "sysopt connection permit-vpn" but then hits an acl on the inside interface. Remember outbound means traffic coming from the ASA to the inside network. Here is where you filter the 20 tunnels traffic.

Note that you would need the following sort of acl

192.168.10.0/24 is one of the 20 remote subnets you want to filter , 172.16.5.0/24 is your inside LAN

access-list vpntraffic permit tcp 192.168.10.0 255.255.255.0 172.16.5.0 255.255.255.0 eq 80

+ add lines for any other ports

access-list vpntraffic deny ip 192.168.10.0 any

etc.. for each of the 20 VPN tunnels

access-list vpntraffic permit ip any any

this last line needed for all other non 20 VPN tunnel traffic.

access-group vpntraffic out interface inside

As i say this may or may not be of worth to you.

If you don't want to filter any traffic just use "sysopt connection permit-vpn".

If you want to filter all traffic just use "no sysopt connection permit-vpn" and use acl on outside interface.

The above solution was only if you didn't care about the majority and just need to filter a few. You could still do this with an outside acl and "permit ip" for the ones you didn't care about and "permit tcp/udp" for the ones you did.

Sorry if i confused the issue. A while back i had to setup approx 100 VPN tunnels on a Pix running 6.3 and they didn't have the ability to apply access-lists outbound and it was a pain !

Hope all this makes sense.

Jon

Thanks, Jon. I had forgotten about version 7.x ability to have an ACL on an interface for each direction, that may be a good idea. I do have one last question, though. You said " If you do a "no sysopt connection permit-vpn" on the ASA then you have to add the permitted traffic for each of the 100 tunnels to an acl on the outside interface."

Now isn't that true for only the remote tunnels that initiate traffic? If 80 of my tunnels are always initiated from the inside, woudn't I just need the remaining 20 allowed with an outside acl? This is assuming I don't have the sysopt connection permit-ipsec in place? Thanks again

"Now isn't that true for only the remote tunnels that initiate traffic?"

Yes that's correct as the ASA is stateful it will allow the return traffic back in.

Jon

Jon,

I'm pretty sure that once you do "sysopt conn permit-vpn/ipsec" traffic will bypass ALL interface acl's, including outbound on the inside interface, not just the outside interface. I have tested this and although you will get hits on the acl, the traffic will be allowed.

Adam

That i didn't know. I was under the impression it only applied to the interface that the VPN traffic terminated on and once it moved through the firewall other interface acl's would be applied. So the ASA must keep a record of VPN traffic even when decrypted to know it can bypass any ACL.

Matt, apologies but this obviously changes some of what we have discussed. Clearly using an outbound access-list on the inside interface would not have any effect if Adam's information is correct and from experience Adam is usually right.

Edit - think i'll rephrase that :-) I have never known Adam to be wrong on firewalling issues.

Jon

excellent info. Thanks to you Jon as well as Adam for helping me understand this setup.

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:

Review Cisco Networking products for a $25 gift card