Aaron,
Were there any updates made to the operating system? Is Windows firewall enabled on this device? Has any routing changes been made (on the firewall or elsewhere on the network) between the source and destination? What is different about this RDP server versus the others that are working - # of NICs, location in the network, the port that it is plugged into, etc? What has changed on the server/network since before it worked and now that it is not working?
Once you have answered these questions, here are a few steps that we (TAC Firewall) often start with:
1.) Turn on logging on the Firewall, preferably at the debugging level, increasing the buffer-size sufficiently to allow you to see any syslog messages created on the firewall.
logging enable
logging buffered debugging
logging buffer-size 1024000
2.) Enable packet captures on the ingress and egress of the firewall for the traffic in question:
For ASA 8.0+, the syntax for this would be:
capture capin interface match tcp host host buffer 512000
capture capin interface match tcp host host buffer 512000
For other firewall platforms, and for how to clear/remove/download the captures, consider the following link:
https://supportforums.cisco.com/docs/DOC-1222
3.) Attempt the RDP connection through the firewall that is not working and then immediately do a 'show log | inc '
4.) Download the packet captures (in *.pcap format) and compare the inside and outside packet captures using Wireshark or other packet capture utility that supports libpcap format.
5.) If you notice that a particular packet is seen on the inside but not the outside packet captures, consider doing the following:
a.) Clear the ASP (Accelerated Security Path) drop counters:
clear asp drop
b.) capture all ASP dropped packets:
capture capasp type asp-drop all buffer 1024000
c.) Quickly run the failed session again.
d.) Immediately look at the ASP counters:
show asp drop
e.) If you notice a particular counter that has increased during the timespan, you can do a 'show capture capasp | inc ' to see if the client was the cause of that counter increasing.
You can also adjust the 'asp-drop all' keywords to be more specific if you see more than one drop counter increase.
You may also benefit from repeating steps 1-4 for a WORKING RDP session as a comparative study. From the syslogs and the packet captures, this will assist in determining whether or not the firewall is at fault and how the firewall may be affecting the packets and/or packet flow.
Hope that helps,
Kevin
