RDP Packet loss via SSL-VPN in UTM9 / SG230

Question

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

BAlfson · Accepted Answer

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