ASA 8.4 TCP Reset-I with RDP Server 5.2 (Server 2003) only.

[hometownfc]

I decided to migrate to ASA 8.4(5) from 7 and everything went very well with the exception of this one issue.  All ACL and NAT for our various remote desktop servers work perfectly as long as the servers are running an RDP server version greater than 5.2.  For instance, Server 2008 machines (or Win 7 Pro desktops) work perfectly as configured; however, Server 2003 machines (or WinXP Pro desktops) will not.  I'm using manual, static NAT for the object to avoid automatic NAT issues.

The client computer displays the non-vista warning message, "The indentity of the remote computer cannot be verified...", but then fails to properly connect stopping at the "Configuring remote session..." status message.  The ASA log shows that it built the TCP, then it displays a teardown with reason TCP Reset-I.

I can use a working ACL and NAT (using default TCP 3389 for instance) with a Server 2008 at IP 192.168.15.10 and move a Server 2003 machine to that same IP without touching any configuration at the firewall and it fails.  Move the Server 2008 machine back to that IP and it works perfectly (both set at Port 3389 of course).

Here is the relevant info from the config that I am using for this:

------------------------------------------

object network RDPServer

host 192.168.15.10

object service RDP

service tcp source eq 3389

access-list out2in line 1 extended permit tcp any object 192.168.15.10 eq 3389

nat (inside,outside) 1 source static RDPServer interface service RDP RDP

------------------------------------------

The above works pefect as long as a server 2008 machine is at the IP, but fails with a server 2003 machine at the IP.

[Jouni Forss]

Hi,

Only thing that log message says to me is that the server is sending a TCP RST for the connection.

So seems the server forms the connection with the remote host but simply resets the TCP connection.

I'm not sure if theres much to be done on the firewall side.

You could always take a capture on the firewall of both the successfull and the unseccusfull connection and see if they give any additional information on the situation.

Personally I configure Port Forward / Static PAT in the following way.

object network SERVER-RDP

host 192.168.15.10

nat (inside,outside) static interface service tcp 3389 3389

access-list OUTSIDE-IN permit tcp any object SERVER-RDP eq 3389

No other NAT rule should really override this unless you make the NAT rules too wide. (Interfaces or networks defined as "any" in the NAT statements)

Sadly I have little knowledge of the IT side which would help troubleshoot the actual server side of this problem.

- Jouni

[hometownfc]

Hi Jouni:

Thanks for your help.  I've tried several different RDP 5.2 machines (WinXP Pro, Server 2003, etc.) and they all fail for some reason while various newer versions of RDP work fine.  I tried changing my config to your method since anything is worth a shot at this point and received a "Deny tcp src by access-group "out2in" [0x0, 0x0]" in the log.

----------------------------------------------------------------------------

There is one wide NAT now that you mention it:

object network obj_any

nat (inside,outside) dynamic interface

----------------------------------------------------------------------------

And on the access list:

access-group inside_access_in in interface inside

access-group out2in in interface outside

access-list inside_access_in extended permit ip any any log disable

----------------------------------------------------------------------------

Thanks again.

[Jouni Forss]

Hi,

I personally configure the Default PAT rules for Internet / outbound traffic in the following way

object-group network DEFAULT-PAT-SOURCE

network-object 10.10.10.0 255.255.255.0

network-object 10.10.20.0 255.255.255.0

network-object 10.10.30.0 255.255.255.0

nat (any,outside) after-auto source dynamic DEFAULT-PAT-SOURCE interface

This is the one rule where I actually use "any" as the source interface for the PAT configuration. The reason is that I can create a single PAT rule that handles all the networks behind the firewall.

The "object-group" defines all the source networks that will be applied to the NAT configuration.

And the "after-auto" is the most important part here as it defines the PAT rule so that its moved to the last section (Section 3) of the NAT rules on the firewall. So Manual/Twice NAT is gone through first then Object Network NAT and finally the NAT configurations of Section 3 (which could also be called Manual/Twice NAT I guess, I'm not quite comfortable with the new naming conventions yet )

- Jouni