Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 4 subscribers
  • Views 3754 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RDP Packet loss via SSL-VPN in UTM9 / SG230

chronowerx
Hello everybody,

we are using an application based on the Microsoft RDP protocol, namely the IRDPSRAPI. The "sharer"-part of the application initiates a connection via IRDPSRAPISharingSession which is answered by the "viewer"-part of the application via IRDPSRAPIViewer. The catch: This works in the following cases:
- Both sharer and viewer are directly connected to the network (non-VPN)
- The sharer is directly connected to the network (non-VPN) and the viewer is using Sophos SSL-VPN of the UTM

but *not* if the sharer is the one using SSL-VPN, regardless of the viewer being directly connected or also using SSL-VPN. While connecting, the sharer sends several packets, including a "PUSH" packet, which is then lost in the UTM and the connection can't be established.

We have tried several versions of the UTM 9-Software (9-5xx to 9-6xx) and SSL clients, both Windows and MAC based as well as Sophos REDs.

The software vendor has analyzed the problem and concluded that the packet gets lost in the SSL stack of the UTM. Does this make sense? (How) Can this be verified? Is this a misconfiguration on our end? Regular Remote Desktop sessions work flawlessly.

Thank you in advance and regards,
Ken

Edit: Formatting fixed


This thread was automatically locked due to age.
Parents Reply Children
  • +1 in reply to chronowerx

    Getting closer, Ken.  What are 172.16.2.22 and .56?  What subnet does "VPN Pool (SSL)" contain?  What IP are the SSL VPN clients connecting to?  What port(s) does the sharer use?

    Please show the Edit of the SSL VPN Profile.  You can copy and paste an image directly here and we'll know that it can't be modified to contain malware by some hacker.  I opened your links in a sandbox just in case.  We can't know if an external site is properly protected. The only malware I've gotten in over 10 years was from an external link to a picture in this forum about six years ago.

    Let me say something in my own words to see if I understand what's not working.  When client 1, connected via VPN, shares a session to directly-connected client 2, Client 2 receives the sharing offer and initiates a viewing session of that offer.  Wireshark shows the viewing session packet arriving on the UTM but not leaving the UTM.  There is nothing in the Firewall or Intrusion Protection log indicating that the UTM blocked the packet.

    Cheers - Bob

     

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi Bob, first of all thank you for your continuous help. The good news is - I figured it out. The bad news: I could have figured it out a lot sooner by following Rule #1 in Rulz more precisely ;-) I only now checked the IPS logs, since I didn't expect it to react within an internal-defacto-internal (VPN) connection.

    Bottom line: "OS-WINDOWS Microsoft Windows Terminal server RDP over non-standard port attempt". After I disabled the IPS for two test clients, the software works flawlessly.

    Sidenote: Contrary to the images posted, the connection VPN->Internal worked but not the connection Internal->VPN. My mistake.

    The question remains: Why does regular RDP work in both directions? As I understand, RDP is using its standard port 3389 to establish a connection and to negotiate which ports are being used e. g. for image transportation, which is fine with the IDS. So if "our" application uses non-standard ports for the connection part already - which I assume happens - it is being flagged by the IDS. A design flaw? An "overreaction" of the IDS?

    Regards, Ken
  • 0 in reply to chronowerx

    "Working as intended," let's say - glad you found the problem!  Even when I "know" I won't find anything, I always do #1 in Rulz to leave no doubt.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML