Solved: 5505 VPN and ACL Question

Ed Willson · ‎01-05-2014

I'm setting up a site-to-site VPN to replace a private MPLS connection at a branch we're going to sell soon (so way cheaper to ditch the fiber and use Comcast).

I have a tunnel that is seeming to work fine, but I have a couple technical points that I'm having trouble with mentally.

What's troubling me is that I didn't need to configure and ACLs for ouside or inside inbound. The VPN terminates on the outside interface at each location, and all ACLs are applied to interfaces inbound.

Can you guys tell me if this anology is correct?

The ASA is like a house with three doors(inside, outside, DMZ), each door has a key (or acl inbound). Once you are inside the house you can leave through any door you wish (because my acls are applied inbound only). The tunnel really terminates inside the house, so traffic is free to leave at will as long as it was allowed in.

Thanks,

Ed

Jouni Forss · ‎01-06-2014

Hi,

Your situation is the result of very basic settings on the ASA I would presume.

I am a bit confused as to whether you have ACLs actually configured at the moment. You first state that you didnt need to configure them at all and then state that ACLs are applied inbound on both "inside" and "outside".

The inbound ACLs will control the traffic that is coming from behind those interfaces towards that interface. (traffic that is about to leave from that network towards some network behind another ASA interface)

If I were to presume that you have "inside" and "outside" interface both configured WITHOUT interface ACLs then the "security-level" value of the interface decides to which direction the traffic/connection initiation is allowed.

You would probably have "security-level 100" on the "inside" interface and "security-level 0" on the "outside" interface which would mean that all connections are allowed towards "outside" networks from networks behind "inside".

Hosts behind "outside" interface would naturally not be able to initiate connections to your internal network because of the "security-level" but that would not be the only problem. Naturally if there is no Static NAT or Static PAT translation to provide the translation for the hosted internal server the connections wouldnt even pass the firewall with an ACL configured.

Also with regards the VPN there is one special thing that people might not notice with the ASA firewalls. The default setting of an ASA firewall is allow any traffic coming through a VPN connection to bypass the interface ACL of the interface which terminates the VPN connection. So in your case the "outside" interface. This is why the traffic wont get matched to the interface ACL

The default setting doesnt show up in the CLI format configuration of the ASA

The actual command is

sysopt connection permit-vpn

You can view it with the command

show run all sysopt

If you want all incoming traffic from VPN to be matched to your inbound "outside" interface ACL you would have to enter

no sysopt connection permit-vpn

You would naturally have the option to configure a VPN Filter ACL on the VPN connection to control the traffic. I personally like changing the setting I mentioned.

Hope this helps and clarifies the situation

- Jouni

View solution in original post

Jon Marshall · ‎01-06-2014

Ed

It depends. If you have "sysopt connection permit-vpn" enabled on your firewall then this tells the firewall to bypass any access lists configured for VPN traffic. So in this case the acl on your outside interface applied inbound will not be checked.

If "sysopt connection permit-vpn" is disabled then the traffic, after being decrypted will be checked again the outside acl, assuming the VPN terminates on the outside interface and the acl is applied inbound.

With version 8.4 onwards "sysopt connection permit-vpn" is enabled by default. For earlier versions you can check the ASA command references to see if it is on by default. I believe it is so that is why you did not need to modify your acl on the outside interface for VPN traffic. See this link for full details -

http://www.cisco.com/en/US/docs/security/asa/command-reference/s21.html#wp1567918

Jon

View solution in original post

Jouni Forss · ‎01-06-2014

With regards to your analogy, it does fit the ASAs logic in some way

Once you are inside the house you can leave through any door you wish

This will only be true if we are talking about a situation where the users is actually locate behind the most secure interface of the ASA which could be "inside" with the "security-level 100". This would mean it could form connections towards any other interface of the ASA usually.

Naturally there are situation where this might not be through. There might be other configurations like ACLs and NAT configuration that could still stop the traffic. Also if the source and destination interface "security-level" was equal the traffic might be stopped without an additional command "same-security-traffic permit inter-interface"

If we were talking about connections forming through the firewall then once the connection is allowed to form through the firewall then the return traffic for that connection would naturally be allowed through the firewall back to the client that initiated the connection but this is basic statefull firewall operation.

And considering the last part mentioning the VPN I refer to the first reply I posted. The VPN terminates on the "outside" interface and since the default setting lets VPN traffic bypass interface ACLs then the traffic flows freely.

- Jouni

View solution in original post

Jouni Forss · ‎01-06-2014