Forum Discussion

SpencerWebb_265's avatar
SpencerWebb_265
Icon for Nimbostratus rankNimbostratus
May 19, 2017

Native RDP sessions not connecting (13.0 HF2)

Hi there,

 

we have BigIP LTM/APM configured and working. We have load balanced services, VPN and many other services working without issue.

 

We recently upgraded to 13 and added HF2. We are currently testing the native RDP client integration (not gateway or remote access) and we're currently failing miserably.

 

So far I've noticed the following

 

  • I am making a successful connection to the BigIP on 443 from the RDP Client but it disconnects shortly after with a message about can't find the computer.
  • RDP Requests seemingly originate from the Self IP of the BigIP not the required SNAT address.
  • Requests are dropped by the client, and windows filtering platform shows blocked connection events in the security log.
  • The activex/java clients work and connect, however the source IP is still the external self ip of the bigIP.

So I guess I have 2 issues

 

  1. The connections appear to originate from the SelfIP of the BigIP not the designated SNAT Pool
  2. The RDP conncetion makes a connection to the BigIP but then windows is blocking it for some reason.

Steps I've taken so far

 

Relating to 1 Tried different SNAT Pools Changed the various settings relating to SNAT (Auto Map, SNAT, None) all give the same results Searches returned results about a bug that existed in BigIP 12 that sounded similar, however this is not mentioned in the 13 notes as either being fixed or a known issue.

 

Relating to 2 Turned off local firewall Turned off require Network Level Authentication in Remote Connection Settings Searches didn't turn up much of any use

 

Any advice on either issue would be great.

 

Cheers Spence

 

9 Replies

  • Here is the F5 KB

     

    599567 : APM assumes snat automap, does not use snat pool Component: Local Traffic Manager

     

    Symptoms: With a virtual configured to use a snat pool is also associated with APM (for example when configured as a RDP gateway), the snat pool setting is not honored. Also snat configuration of "None" does not work. It always works as if it is configured with Automap

     

    Conditions: Snat pool configured, APM configured (one example is deploying Horizon View iApp for ApM).

     

    Impact: The VLAN Self IP address is used instead of the snat pool addresses.

     

  • I'm actually investigating a similar issue (also v13 HF2, also native RDP resource). Actually in my case (on an F5 VE), I narrowed it down to the native RDP resource not working when there are multiple tmm instances active. Check in tmsh. show /sys tmm-info. If I limit the number of CPUs to one, it does effectively work. When I increase the CPUs to 2, the RDP resource will stop working. The thing where it's different is that, in my case the backend server (3389) is never contacted whenever it won't work. I verified with tcpdump. There's not a single SYN that gets sent. Could it be that you actually have the same issue using the native RDP resource and that your "connection refused" messages in Windows only occur using the activeX RDP resource?

     

  • Hi,

     

    I have the same issue only when I enable SSO on native RDP.

     

    I tried to configure only one vCPU on my VE with SSO, but still not work.

     

    • BZM's avatar
      BZM
      Icon for Nimbostratus rankNimbostratus

      Seeing this same issue in 13.1. Just curious if a resolution was ever found?

       

      Thank you, Ethan

       

    • JWhitesPro_1928's avatar
      JWhitesPro_1928
      Icon for Cirrostratus rankCirrostratus

      I think the 13.1 or 13.1.0.2 release notes have a workaround listed for disabling some kind of hardware thing but I haven't tried it (or maybe I did in the past but it didn't work for me).

       

  • I have been working on this as well. I have a single IP in a SNAT pool for the Virtual Server. I want all internal connections from this VS to use the source address to be allowed through a specific firewall. The IP is in traffic-group1. Making repeated native RDP connections use any one of the IP's in traffic-group1, including the one I am using in the SNAT pool. I need to have the source IP be reliable for the resources used in the VS, RDP, network access..etc

     

    • Donamato_01_150's avatar
      Donamato_01_150
      Icon for Nimbostratus rankNimbostratus

      I've got the same issue on 13.1.1.2 Build 0.0.4 Point Release 2 ! anyone got a fix for this yet ??