Thread Info
  • State Verified Answer
  • Replies 5 replies
  • Subscribers 5 subscribers
  • Views 3294 views
  • Users 0 members are here
Options
Suggested

XG 18 EAP3 With Microsoft RDP Gateway and 0x3000008 (Android App)

W777

Is anyone running or have experience with XG18 WAF with Microsoft RDP Gateway in the last few month’s?  I’ve been running fairly successfully with both the Windows, Android, and iOS version of the Microsoft RDP client  app, but looks like something has broken the way the Android app works/negotiates through.


I use the static hardening hack/trick to reject /RemoteDeaktopGateway/ URL and this is about the only way the iOS app works.  It falls back to RPC over SSL as expected and works fine.  Trying to isolate the issue with the Android app by trying a few troubleshooting steps hasn’t changed the behaviour at all. Everything else is as per the KB https://community.sophos.com/kb/en-us/126103 .

At this point I’ve turned off the common threat filter with no change.

The common error in the RDP app is 0x3000008  - which happens after what appears to be a few attempts to negotiate. As shown in the log as rpcproxy.dll tries to do it’s  thing.  Obviously using OutlookAnywhere option to pass the RPC and not the RDP traffic.  Assume that is still the correct method of using RDP Gateway with XG WAF?

 


 

What is weird is the backend RDP 2016 Gateway event logs seems to indicate the start of a successful negotiation,  then it disconnects. All certificates etc are valid and configured.

 

im chasing down a few leads with Microsoft, but I thought I would check with the sophos beta community if they have had experienced any changes recently.

The Microsoft App also seems to be to smart for its own good and potentially seeing the CGNAT of a mobile carrier as “local”.  It’s going to be a bit of a finger pointing game I suspect. 

Thanks again 

Parents
  • +1

    Hi Timothy,

     

    This is potentially an incompatibility between WAF and the Android app. WAF at the moment only supports RPC_IN_DATA and RPC_OUT_DATA messages, so e.g. RDG_IN_DATA or RDG_OUT_DATA are not supported and will be blocked by WAF.

     

    You can try to create a DNAT rule and disable the WAF rule to see if that solves the issue. If it does, then it's unfortunately a compatibility problem in WAF. You can check the reverseproxy.log file on the device to see whether you can see any suspicious log messages, but since CTF is already turned off, there's probably not much you can do unfortunately.

     

    Best regards,

    Attila

     
Reply
  • +1

    Hi Timothy,

     

    This is potentially an incompatibility between WAF and the Android app. WAF at the moment only supports RPC_IN_DATA and RPC_OUT_DATA messages, so e.g. RDG_IN_DATA or RDG_OUT_DATA are not supported and will be blocked by WAF.

     

    You can try to create a DNAT rule and disable the WAF rule to see if that solves the issue. If it does, then it's unfortunately a compatibility problem in WAF. You can check the reverseproxy.log file on the device to see whether you can see any suspicious log messages, but since CTF is already turned off, there's probably not much you can do unfortunately.

     

    Best regards,

    Attila

     
Children
  • 0 in reply to AttilaKovacs

    Thanks Attila,

    I guess the frustration is it was working, even on v18 so was hoping to hear other success stories or potential solution.

    I thought maybe I changed the rule order or something silly, but as you say I've pretty much exhausted my log analysis.

    Hopefully an update to Android app might allow it to work and fall back to RPC in a way that will work again

    Was hoping to avoid DNAT as the certificate management is so much easier via Sophos.

    Thanks

  • 0 in reply to W777

    Hi Timothy,

     

    One thing we can still try is to look at a traffic dump and see whether it's something that can be easily fixed in WAF. Would it be possible for you to create traffic dumps between the app and WAF, and also between WAF and the backend server?

     

    Regards,

    Attila

     
  • +1 in reply to AttilaKovacs

    The easiest way to create a traffic dump that contains both the HTTP traffic between client and WAF and between WAF and the backend server is probably to use WAF's mod_pcap facility.

    Here's how to enable mod_pcap.

    Log into the system with ssh. Edit /usr/apache/conf/httpd.conf. If the file is read-only, you have to make the root filesystem writable first:

    mount -o remount,rw /

    Look for this section in httpd.conf:

    ## Uncomment these lines for traffic dumping in pcap format
    #LoadModule pcap_module /usr/apache/modules/mod_pcap.so
    #PcapFileName /tmp/WAF.pcap
    #PcapNetworkProtocol ip

    Uncomment these 3 lines:

    LoadModule pcap_module /usr/apache/modules/mod_pcap.so
    PcapFileName /tmp/WAF.pcap
    PcapNetworkProtocol ip

    Save the file and restart WAF:

    service -ds nosync WAF:restart

    If everything went fine the service command will respond with "200 OK".

    Please be aware that the traffic dump contains decrypted HTTP traffic with passwords and everything. It also contains the traffic for all HTTP connections that go through WAF.

    Reproduce the problem. The traffic dump is stored in /tmp/WAF.pcap. Zip this file and send it via private message to either Attila or me.

    Disable mod_pcap by commenting out the 3 lines in httpd.conf and restarting WAF. If you had to make the root filesystem writable, make it read-only again:

    mount -o remount,ro /

    We can't make any promises. But like Attila said, maybe we find something that's easy to fix or to work around.

  • 0 in reply to ewadie

    Read my mind ewadie, was about to ask if you had a recommendation on the best way to packet capture.

    Will definitely take the opportunity to do this and send through. Would love some expert insiders to see if there is a way around this little Microsoft "feature".  

    No expectations :)

    Thanks again to you both!

Unfiltered HTML