Cisco ASA inside hosts unreachable over RDP when gateway set to ASA inside interface

[cliveschneider]

I have an ASA (configuration attached) with an  inside network (192.168.255.0/24) that I can access over VPN. I have configured the ASA NAT and Access Rules to allow internet access to inside hosts.

The inside hosts have static IP. Whenever I change a Windows host to use the ASA inside intreface as the network gateway (for internet access), I can no longer RDP onto that host, regardless of whether I am on the inside or VPN network.

However, I can hit the web server (port 80) on one of hosts successfully. RDP "listens on TCP port 3389^[1] and UDP port 3389" according to Wikipedia. Im not sure what NAT or Access Rule would be preventing RDP but allowing HTTP?

[Andre Neethling]

I had a similar problem previously. It's strange behavior, but it is the ASA that's the problem.

You may need the Permit traffic intra interface as some have suggested for "hairpinning traffic". However the other issue is that the ASA tries to maintain state entries for all the connections, even for hosts communicating on the INSIDE network. 

The ASA routes all traffic through the firewall, even the traffic between hosts on the same inside network. This happens when you use the ASA as a client default gateway.

What you need is a TCP state bypass rule for the traffic between inside hosts. You will have to match the traffic with an ACL and then apply TCP state bypass to the traffic.

See the link below, and read it properly before you deploy the ASA as your default gateway for clients.

http://www.packetu.com/2011/10/17/the-woes-of-using-an-asa-as-a-default-gateway/

HTH :-)

[rodrigog]

Hello Clive

Lets go with the next test

Connect 192.168.255.10 in Ethernet 0/6 and 192.168.255.100 in Ethernet 0/7 of the ASA itself

Then set up the ASA as the Default gateway.

Please provide the output of ipconfig of each PC

Then try pinging 192.168.255.100 from .10 and viceversa 

Provide the output of arp -a of each PC

After this try RDP from the local and then from the VPN network 

Let me know of the results 

Regards,

Rodrigo

[cliveschneider]

Hi Dennis,

Apologies for the delayed response.

Only one NIC and only one IP address.

I disconnected the server from the network and connected straight to it with a laptop over ethernet and could RDP onto it no problems. So, I think this confirms it is the behaviour of the ASA that is preventing the connection.

[Peter Koltl]

@Andre

All that you say is right as long as you talk about traffic destined beyond the connected subnet. All traffic sent to the local subnet should not touch the default gateway, the sender PC looks up the dest MAC by means of ARP and sends the packet in a L2 frame directly to the recipient.

[Andre Neethling]

Hi Peter. This is the expected behavior. But it doesn't always do that. Read the link I posted.

http://www.packetu.com/2011/10/17/the-woes-of-using-an-asa-as-a-default-gateway/

[Peter Koltl]

@Andre

I had already read that article and it does not explain how and why a host would send a packet to the ASA as a first hop if the host's routing table contains a connected route. You did not explain it either. 

The only exception I know about is a post-8.3 ASA identity NAT rule without the no-proxy-arp keyword. Such an ASA does send proxy ARPs for every ARP request. But Clive's ASA does not have any route or NAT rule that would result in proxy ARP. Anyway, if the ASA hijacked traffic with proxy ARP, the logs would show that packets are denied src:inside dst:inside. @Clive, do you see such logs?

[Andre Neethling]

Good day Peter. Please see excerpt from the article mentioned where the writer explains how the ASA is trying to create STATE entries for the traffic on the LAN. Traffic that does not go through the ASA.

Try using the TCP protocol to reach something at 100.1.1.0/24.  If you look at this in Wireshark, you’ll probably see something like SYN, SYN-ACK, ACK, RST or SYN, SYN-ACK, ACK, ACT (Retrans), ACK (Retrans).  What is going on?  The ASA is actually trying to create a session for the TCP connection.  It is actually inspecting the TCP traffic.  Since the router delivers the second part of the three-way handshake directly to the host, the ASA never sees the “SYN-ACK”.  Therefore, the ASA doesn’t believe the three-way handshake has occurred and does not allow the third packet.  Well that just sucks.  The ASA is trying to sessionize traffic that doesn’t even go through the appliance.

I had the same issue as the original post. I could only resolve it by creating a STATE BYPASS rule for traffic on the local INSIDE network.

[Peter Koltl]

I'm afraid we both think we could not talk more clearly. (-: Still, these are two parallel ways of thoughts with no common point.

Provoking question 1: do you know the details of layer2 and selecting the first hop dst L2 MAC address?

Provoking question 2:

Why

does

the

host

send

SYN

to

ASA

instead

of

sending

directly

to

the

destination

host

if

they

are 

in

the

same

subnet?