3560 RDP acl not working

IP Routing is enabled, and when I remove access lists 112 & 113 RDP works, but does not when they are in place.  What am I missing?

interface Vlan2
 ip address 172.16.0.1 255.255.255.0
 ip access-group 102 in
 ip access-group 112 out
!
interface Vlan3
 ip address 172.17.0.1 255.255.255.0
 ip access-group 103 in
 ip access-group 113 out

access-list 102 permit ip any any log
access-list 103 permit ip any any log
access-list 112 permit tcp any host 172.16.0.2 eq 3389 log
access-list 113 permit tcp any host 172.17.0.2 eq 3389 log
!
B1izzardAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

FideliusCommented:
Hello,

You need to switch directions on ACLs.
102 and 103 should be OUT direction and 112 and 113 should be IN direction.

Regards!
0
FrabbleCommented:
The ACLs shown will effectively block all traffic between the two networks, so if you're trying RDP between the two it will fail.

Generally, there is no stateful inspection with ACLs so you have to allow for returning traffic.

Using the above and ignoring IP addresses, RDP from VLAN 2 to VLAN 3 will have a client dynamic source port (>1023) and server destination port 3389.
For Vlan2, ACL 102 will allow this in and for Vlan3, ACL 113 will allow this out.
The return traffic will have server source port 3389 and client destination port whatever was used.
For Vlan3, ACL 103 will allow this in and for Vlan2, ACL 112 will block it because all you are allowing out is to port 3389 which is unlikely to be the client source port.

For the above, ACL 112 also has to allow return traffic from the Vlan3 RDP server and ACL 113 also has to allow return traffic from the Vlan2 server:
access-list 112 permit tcp any host 172.16.0.2 eq 3389 log
access-list 112 permit tcp host 172.17.0.2 eq 3389 any log

access-list 113 permit tcp any host 172.17.0.2 eq 3389 log
access-list 113 permit tcp host 172.16.0.2 eq 3389 any log


I assume you're just testing with the above. Normally control is done at the source so ACLs are usually applied for incoming traffic.
For commonly used ACLs and the use of "etablished" for TCP connections, check out:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080100548.shtml






0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
B1izzardAuthor Commented:
>> Normally control is done at the source so ACLs are usually applied for incoming traffic.
So are you implying it's not normal to have an 'ip access-group out', but rather just an 'ip access-group in' to block traffic on all interfaces?  

I personally would prefer to always have an 'ip access-group out' on all interfaces just to make sure you don't have unexpected traffic coming in due to a missed ACL.  I'm I going about this the wrong way?  
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

FideliusCommented:
No, it is not the wrong way, but it is far mor complicated. As Frabble said, ACLs are not statefull, so you will have to define all returning traffic also. It is more error prone approach. Best practice is to use only IN ACLs.

Regards!
0
FrabbleCommented:
I'm not implying outgoing ACLs are not normal, it depends on the situation and why ACLs are being applied in the first place.

You're having to allow all incoming traffic which means it's processed and routed before possibly being denied and dropped, so device resources are being wasted. If an ACL is applied for incoming at the source, denied traffic is dropped, end of story, so is more efficient.
Similarly, anywhere could spoof their address for one that your outgoing list allows and a connection attempt will get through allowing a SYN denial of service attack for example. An incoming ACL can block this again, at the source.
If you have several interfaces, administration will be high. Access from one may involve having to change all the other ACLs instead of just the one. Similarly, you won't be able to inspect the configuration of an interface to see what is allowed for devices on that network, all the other interfaces will need to be looked at. It's easier to miss an ACL in these circumstances.

Ultimately it will be whatever you feel comfortable with to achieve what is required, but if you look at the examples provided by Cisco for access control, almost all are incoming ACLs. Generally they're easier to manage and allow the use of best practice.
0
B1izzardAuthor Commented:
Thanks.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Routers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.