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

HTML RDP to a host behind a SSLVPN Connection

Hello together,

 

I have two UTMs connect via SSLVPN to each other. Local network is 192.168.10.0/24 and remote network is 192.168.160.0/24. Communication over Tunnel works fine. I can connect from 192.168.10.2 over RDP to 192.168.160.191. Now I want to establish a rdp-connection over my local UTMs HTML5-Portal to the same server in the remote network. This doesn't work at all. After selecting "connect" a new tab opens and I have a black screen telling me "Starting new Session", after a while the message "Unable to connect to host" comes up.

Here is an extract of the HTML5-Live-Log during 2 or 3 connection attempts to remote servers 192.168.160.191 and 192.168.113.81:

(I replaced the hostname of both servers in the log file by filling in the corresponding IPs)

2016:12:15-12:00:42 utm-1 screenmgr[43696]: Session[12]: Service has stopped with an error: 4
2016:12:15-12:00:42 utm-1 screenmgr[43696]: Client 11: session stopped: 4
2016:12:15-12:47:55 utm-1 screenmgr[43696]: Client 9: disconnected: Connection timed out
2016:12:15-13:00:42 utm-1 screenmgr[43696]: Client 11: disconnected: Connection timed out
2016:12:15-13:47:55 utm-1 screenmgr[43696]: Client 9: disconnected: Connection timed out
2016:12:15-14:00:42 utm-1 screenmgr[43696]: Client 11: disconnected: Connection timed out
2016:12:15-14:35:34 utm-1 screenmgr[43696]: Client 12: authenticated: user='admin'
2016:12:15-14:35:34 utm-1 screenmgr[43696]: Client 12: start screen requested: REF_CliCon192.168.113.81
2016:12:15-14:37:41 utm-1 screenmgr[43696]: VNCRDesktop[REF_CliConVideoserve]: Unable to connect to host
2016:12:15-14:37:41 utm-1 screenmgr[43696]: Session[13]: Service has stopped with an error: 4
2016:12:15-14:37:41 utm-1 screenmgr[43696]: Client 12: session stopped: 4
2016:12:15-14:41:05 utm-1 screenmgr[43696]: Client 12: disconnected: Broken pipe
2016:12:15-14:41:08 utm-1 screenmgr[43696]: Client 13: authenticated: user='admin'
2016:12:15-14:41:08 utm-1 screenmgr[43696]: Client 13: start screen requested: REF_CliCon192.168.160.191
 
Anyone an idea what is wrong or doesn't this work at all?
I have no dropped packets in packetfilter.log!
Kind Reagrds
Marco


This thread was automatically locked due to age.
Parents
  • Hi, Marco, and welcome to the UTM Community!

    An interesting issue that I'll guess is related to routing in the remote UTM.  If my guess is on-target, there are two different approaches I would try:

    1. In the remote UTM, create a NAT rule like 'SNAT : Any -> RDP -> {remote servers} : from Internal (Address)'
    2. Instead of accessing the HTML5 VPN in the local UTM, access it via a login to the User Portal on the remote UTM.

    That second one is probably to be preferred, but I'm curious if the first one will work.  Please share your results.

    Cheers - Bob

  • Hi Bob,

     

    thanks for your reply. First of all I have to say that accessing the machine over HTML5 portal of remote utm works well as expected. I already tried this bevor opening this post. Problem is, that access to the userportal from external Interfaces is forbidden by the customers security policy. So this isn't an option...

    SNAT, like described in your reply, doesn't work.

    I agree in your opinion that this is a routing issue on either one of the two boxes. But where and why? I tried tcpdump on all eth- and tun-interfaces on local UTM to figure out over which interface the traffic is processed, but I cannot find it. Another curious thing is the box's behaviour when trying to trace from webadmin support-tools-traceroute to the server on the other side of SSLVPN-tunnel. The trace goes to the internet instead of going to the tunnel!

    I have no idea where to look any further...

     

    Kind Regards

    Marco

Reply
  • Hi Bob,

     

    thanks for your reply. First of all I have to say that accessing the machine over HTML5 portal of remote utm works well as expected. I already tried this bevor opening this post. Problem is, that access to the userportal from external Interfaces is forbidden by the customers security policy. So this isn't an option...

    SNAT, like described in your reply, doesn't work.

    I agree in your opinion that this is a routing issue on either one of the two boxes. But where and why? I tried tcpdump on all eth- and tun-interfaces on local UTM to figure out over which interface the traffic is processed, but I cannot find it. Another curious thing is the box's behaviour when trying to trace from webadmin support-tools-traceroute to the server on the other side of SSLVPN-tunnel. The trace goes to the internet instead of going to the tunnel!

    I have no idea where to look any further...

     

    Kind Regards

    Marco

Children
  • Are there any overlapping subnets in either location?  If not, this sounds like a DNS problem now.

    In any case, the only thing I like the HTML5 VPN for is to give an external consultant access to an internal device.  For everything else, I prefer to use SSL VPN Remote Access.  HTML5 Remote Access is just too resource-intensive for general use.

    Cheers - Bob