Cisco Support Community
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

Quick ACL question:

I have this:

access-list incoming permit tcp any host eq 3389

access-group incoming in interface outside

static (inside,outside) netmask 0 0 is up and running and accepting RDP sessions, but when I try to RDP to the x.84 address, it times out.

Am I missing something? It seems simple...


Re: Quick ACL question:

Looks correct to me. Have you tried running separate captures on both the outside and inside interfaces to see if the RDP traffic is traversing the firewall? Anything interesting in the log buffer?

Community Member

Re: Quick ACL question:


Still relatively new to PIX/ASA's.

Could you post a link on how to run a capture?

Re: Quick ACL question:

I would just do something simple like:

capture test interface inside

initiate some RDP traffic

sh capture test | grep 3389

when you're done, don't forget to do 'no capture test'

You can enable the log buffer in global config mode via:

logging buffered info

sh log | grep

no logging buffered info (when you're done"

Hope this helps.

Community Member

Re: Quick ACL question:

P# sh capture test | grep 3389

12:51:43.416604 > S 2147383931:2147383931(0) win 65535

12:51:46.342984 > S 2147383931:2147383931(0) win 65535

Wow! Very helpful stuff!

Looks like the RDP traffic is still being redirected to (it was like this previously).

And I just did:

wr mem

clear capture test

clear xl

Initiated RDP connection, then got:

P# sh capture test | grep 3389

12:55:57.439384 > S 4198845700:4198845700(0) win 65535

12:56:00.394236 > S 4198845700:4198845700(0) win 65535

12:56:06.412713 > S 4198845700:4198845700(0) win 65535

So does this mean it's getting forwarded correctly? Because I'm still able to RDP into another server on the network, then RDP into that server.

Thank you so much for the logging tip. MUCH appreciated!

Re: Quick ACL question:

Yep, looks great. You're welcome.

Community Member

Re: Quick ACL question:


So I'm still having the same problem. I do the logging tip as mentioned and it seems that 3389 traffic is getting through, yet I am not getting any connection. It keeps timing out.

I tried changing the LAN address to another server and the same thing happens. Both of these LAN servers *definitely* work. I am able to RDP into them via our other PIX (this current PIX is on the secondary line, different ISP) from the outside.

So the server is accepting 3389, the PIX appears to be passing traffic.

What else could it be? Are the above log lines indeed passing traffic?

Re: Quick ACL question:

At this point, I'm really not sure what it could be. So the RDP traffic is leaving the inside interface destined for the server, but you're not receiving a reply. I'd say it appears to be something server-side related. Does the server have any host based restrictions? Does it only accept RDP connections from a list of authorized hosts?

At this point, I'd probably put Windump on the server and validate that the RDP traffic was arriving.


Re: Quick ACL question:


Is the server on the same subnet as the ASA? Are the reply packets deinitely being routed back in the right direction?

Check the routing table on the server and any hops in between.


Community Member

Re: Quick ACL question:

Thanks for all the replies.

This is a Windows Server 2008, so I wasn't sure about installing Windump on this as I couldn't find much about support. Didn't want to hose the machine.

While the routing table is ok, this was definitely the write direction.

So we have two PIX firewalls. I was setting up this RDP access through the PIX2 just in case PIX1 went down. When RDP traffic was initiated through PIX2, the server was apparently responding out of it's default gateway (of course) which was PIX1.

I changed the default gateway on the server to PIX2 and RDP connected fine.


CreatePlease to create content