RDP via internal routes

[David Schau]

Trying to finish what should have been an easy implementation, except for RDP.  The setup is ASA as a firewall for internet traffic only with routes pointing back to a MPLS router (provider managed).  For example: ASA is 172.16.1.1/24 routes pointing to 172.16.1.2 for internal subnets (10.0.0.0/8, 172.16.0.0/16) can't change gateway to be MPLS as they (Qwest) won't support that routing.  After testing we were OK with everthing so far other than RDP to internal servers.  When I start the RDP I see via wireshark the remote get the SYN and reply with a SYN ACK = 1, the initiating PC sent the SYN sent then gets a SYN ACK = 816362720 which complains of a lost segment.  SO the RDP session doesn't happen.  If I change the intiator gateway to the MPLS 172.16.1.2 RDP works fine but then Internet traffic doesn't use the local ASA

Pings, SNMP, HTTP and other apps seem OK.  Bug with RDP?  Any solutions someone can offer?

[Kureli Sankar]

From the sound of it, it looks like there is some routing issue. If http works between the same two hosts then RDC should work as well. Unless there is some route-map changing the next hop for tcp 3389 and not for http.

What is the purpose of this line in the config?

static (inside,inside) 172.16.1.0 172.16.1.0 netmask 255.255.255.0

If you need to U-Turn then you need to have "same security permit intra interface" command. I don't see that in the config.

What is the topology look like?

If you can add a simple (no need for visio or pdf or jpg) text based toplogy that would help.

What is the source IP (client IP)?

Which interface does the source live off of?

What is the RDC server IP?

Which interface does that live off of?

Make sure the text based topology answers the above questions.

example:

RDC server---Router---(IN)ASA(OUT)---Internet---Client PC

-KS

[David Schau]

I must have inadvertently removed the line for same security permit intra interface I know it's in the running config.

Testing this I had..  PC 172.16.1.31 to ASA 172.16.1.1 over VLAN1 route for 10.0.0.0/8 via 172.16.1.2 (for lab) L3 switch with 172.16.1.2 and 10.248.0.1 on VLAN2 remote PC was 10.240.0.5.  Pings work fine so routing isn't the issue, in production other apps were fine as far as I noticed.  Only problem seems to be RDP so far.  Seems the ASA is corrupting the TCP setup as I explained in the original post.  No internet involveed here internal routing only but need to use the ASA as the gateway as I explained.

[Kureli Sankar]

Never mind. same-security-traffic permit intra-interface line is there.  I probably didn't look right.

Anyway, when there is asymmetry in routing, icmp will work because of its nature.  If you add icmp inspection, then pings will fail as well.

Captures are your best bet. I'd get wiresharp capture on the PC, server and on the ASA. What do you see in the syslogs when RDC fails?

server(10.240.0.5)---Router(.2)------(.1)/IN)ASA(OUT)

                                                    |

                                      PC-172.16.1.31

route inside 10.0.0.0 255.0.0.0 172.16.1.2 1

So PC can't get to the server?

cap capin int inside match tcp hos 172.16.1.31 ho 10.240.0.5 eq 3389

sh cap capin det

-KS

[David Schau]

I can try to gather more information later if that will help.  I looked at the syslog but didn't notice anything I thought was a cause for the failure as far as I know.  I didn't capture on the ASA yet but what I did see was the originator sent a SYN to the server at the server end it was recieved and the server sent a SYN ACK with ACK=1 when that gets back to the originator the packet showed ACK=816362720.

This is approximately what I saw when I was on site, I staged this in my lab because the location is a long drive away so I want to be I have this figured out before going back.

[Kureli Sankar]

You mentioned the server was on the outside (vlan 2) but according to the route the server and the pc are both on the inside. Pls. clarify that.

If both of them are on the inside then the PC is talking to the server through the ASA and the server will directly repond to the PC and not through the ASA.

You may have to add routes to the inside network pointing to the ASA (splitting the /24 network to 2 1/28) on the router or simply change the GW the PCs are pointing to.

-KS

[David Schau]

I came to the realization as you pointed out.  The return traffic from the server goes directly back to the access PC not through the ASA on response.  What I did in my lab was to replace the ASA with a 2600 I had available doing the same routing function as I had attempted with the ASA.  This worked for the same RDP session, I did notice in a packet capure on a span port one significant difference.  When I used the router the access PC get an ICMP redirect message, the ASA does not send a redirect.  I tried a few changes but I have not found a setting to enable the redirect from the ASA when it relays the traffic.  Is there a setting to turn on the ICMP redirects from an ASA?

I did figure out one workaround, by setting persistent routes in the PC this RDP works because then the RDP trafic goes directly to the other device but I don't feel this will be acceptable in the long term.  If there is a way to enable the redirects I would like to try and test that.

I am attaching the wireshark captures from a span for the PC side showing this if anyone is interested in that.

[Kureli Sankar]

Firewall is a security device so, it doesn't send icmp redirects like the routers do. This is the reason for the seq num mis-match. Your best bet is what I had suggested in my previous post.

Which is to break down the inside network and add two routes on the router pointing to the ASA so, the responses will be forced to come to the ASA and back.

On the inside router:

ip route 172.16.1.0 255.255.255.128 172.16.1.1

ip route 172.16.1.128 255.255.255.128 172.16.1.1

-KS

[David Schau]

That won't work because the router is not managed by us, it is a provder supplied router and they have told me they won't add the internal routing.  I can try one more time to see if they will allow this but that may not be possible.  The two subnet solution would not work due to this.  The easest solution would have been to use the internal MPLS router but as I said they were not open to the changes I requested.

Unfotunately this is seems in my opinion to be something that will make it impossible for us to use the ASA as a solution for this customer.  This missing functionality is something I was not aware of and is going to cost us credibilty with the customer for future opportunities.

So to be completely clear there is no option to enable this in the ASA?

[Kureli Sankar]

You can try tcp state bypass on the ASA. That might help. I haven't tested it but, this will treat tcp packets as udp packets and won't do any normalization or inspection.

http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/s1.html#wp1428242

hostname(config)# access-list tcp_bypass extended permit tcp 172.16.1.0 255.255.255.0 any

hostname(config)# class-map tcp_bypass
hostname(config-cmap)# description "TCP traffic that bypasses stateful firewall"
hostname(config-cmap)# match access-list tcp_bypass

hostname(config-cmap)# policy-map tcp_bypass_policy
hostname(config-pmap)# class tcp_bypass
hostname(config-pmap-c)# set connection advanced-options tcp-state-bypass

hostname(config-pmap-c)# service-policy tcp_bypass_policy inside

-KS

[David Schau]

It's worth trying the TCP bypass.  I'll see when I can get a chance to test that.

[Kureli Sankar]

Any positive update? Did TCP state bypass work for you?

-KS

[David Schau]

I ended up pushing back on the MPLS vendor to allow their router to do the routing needed.  That seems to work fine now for all the applications so far, I have another site to test at and then we will be done with the POC.

[Kureli Sankar · Accepted solution]

Good decision. That is the correct way to solve the problem.

-KS