Access-List traffic control

[IT_-_Department]

I have an ASA pair configured to replace a router that hosts a collection of IPSec Tunnels.  Tunnels appear to work.  I am lab'ing some additional controls that I would like to implement.  On the Production Router that i plan to replace with the ASA's the current Tunnels are all wide open (all traffic allowed to pass).  I was hoping to lock things down a little without having to reconfigure all of the Tunnels.  My though was that an ACL on the Inside Interface blocking selected traffic Out (so into the LAN) should not impact the stability of the Tunnels but allow me to restrict some traffic from entering the LAN.  One port that I was attempting to block is RDP 3389.  When this ACL is applied to the inside interface it does not block Port 3389 at all.  What am I missing?  Is it that the trffic is being allowed because it is coming through one of my 'open' Tunnels? 

Shouldn't IPSec Tunnel traffic be processed by the Inside Interface ACL just like all other traffic? 

ACL looks like this:

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 3389

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 135

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 137

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 138

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 139

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 445

access-list 145 deny   tcp 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 389

access-list 145 permit ip any any

ip access-group 145 out interface Internal

This work great on a 2821 Router, but not so much on the ASA.

Thoughts?

[Julio Carvajal]

Hello Eric,

If you apply this ACL

ip access-group 145 out interface Internal it will block traffic from 192.168.30.0 0.0.0.255 10.187.10.0 0.0.0.255 eq 3389.

Is the other side of the tunnel  192.168.30.0 0.0.0.255??

Regards

[IT_-_Department]

Hi J,

Yes, this is the functioning ACL on the Router which has 30+ Tunnels.  192.168.30.0/24 is the remote LAN on one of them.  It does function in barring any traffic from that subnet from reaching the internal.  What I am attempting is to make the same thing work on the ASA with a broad application:

access-list 145 deny   tcp any 10.187.10.0 0.0.0.255 eq 3389

But when applied to the internal interface it does not restrict traffic on 33898 (or any other configured port).

Is the ACL for the cryptoamap over riding the interface ACL?

Thanx

[Julio Carvajal]

Hello Eric,

Actually it should restrict the traffic going out the internal interface,

If you do show access-list 145 do you see any hit-counts,

Regards

[IT_-_Department]

Hey,

Precisely what I would think and why I am here....

On the Production Router, Yes, there are hit counts on the various lines of the ACL, and the Denied Services do not work. On the ASA there are no hit counts on any of the lines, and the Denied Services are not blocked and DO work....

So it would  appear that the Traffic is bypassing the ACL entirely. 

I double checked and there is an  "access-group 145 out interface Internal" so it should be applying the ACL to the "interesting traffic"  coming out the Internal interface, I would think....

Regards

[Julio Carvajal · Accepted solution]

Hello Eric,

Wait a second, so it does work on an IOS router  That is the expected behavior.

On an ASA it will not. Why?? Because of the sysopt connection permit-vpn ( Bypass all ACL's if traffic comes from a crypto acl)

I though we were talking about a router all time,

Regards,

Julio

Remember to rate all of the helpful posts

[IT_-_Department]

Sorry, thought that I had spelled that out more clearly in the initial posting.

Yeah, I have a stand alone 2821 that is hosting the Tunnels, and want to move to the HA ASA Pair.

I feared that it was an ASA IOS thing bypassing the interface ACL.  That would be the only explanation that makes sense.  The concept is sound and does work fine on Router IOS. 

Thank  you for confirming my fear.  :-(

[Julio Carvajal · Accepted solution]

Hello Eric,

But you can change that behavior,

Do show run all sysopt

And then type a No infront of the sysopt permit vpn....

Regards,

[jamer]

you can control traffic entering the asa from a distant vpn site by filtering via the outside acl or via and acl applied in group policy for the vpn connection. the sysopt mentioned in this post will control whcih method wroks best.


Sent from Cisco Technical Support iPad App

[IT_-_Department]

Thank you both for your input.

Jamer:  I am aware that I could lock each Tunnel down individually with the respective cryptomap ACL, but that is a logistical nightmare in this situation, hense the effort to do this with an Interface ACL.

J:  You get the Prise.  It would appear with initial testing that the no sysopt connection permit-vpn seems to fix the bypassing of the interface ACL by the Tunnel Traffic. 

Thanx for your help!

[IT_-_Department]

It would appear that I marked this as "Answered" and rewarded a "Correct Answer" a wee bit quickly.  The Problem is not solved and has just reversed!  Where the CryptoMap ACL was over riding the Interface ACL, now the CryptoMap ACL is rendered useless.  No Traffic comes through the Tunnels at all, even though the Interface ACL should allow all traffic other than the 5-6 ports that we are trying to block... 

I cannot "UnAnswer" this question, so I am going to start over with an entirely new posting and see where that goes.

J:  You are welcomed, if not encouraged to continue to offer any insights that you may have!

[Julio Carvajal]

Already answered the other post

Please check it and update us