09-28-2015 08:39 PM - edited 03-05-2019 02:24 AM
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?
10-07-2015 02:39 AM
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 :-)
10-11-2015 10:25 PM
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
10-05-2015 09:53 PM
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.
10-07-2015 02:15 PM
@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.
10-07-2015 10:37 PM
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/
10-08-2015 12:05 AM
@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?
10-08-2015 12:17 AM
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.
10-08-2015 01:24 PM
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?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide