Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 37 subscribers
  • Views 1224 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

Issues with RemoteApp SSO over SSLVPN

John Nickell

We are migrating from Sonicwall's NetExtender remote access program to "hopefully" Sophos Connect. There's a fair amount of back story to this question, but the primary goal of my post is to see if someone can shed some light on why we are seeing a different behavior with the IPSEC VPN connection and the SSL VPN Connection.

Internally we have a basic Windows RemoteApp setup for delivering our ERP solution to our end users.  We have SSO working while in the office, so that if a user opens the RemoteApp from their computer, the first "login" screen they are presented with is the login to the ERP product. I know that this requires delegated credentials and it's setup and working if they're in the office.  As we are currently setup, 'in the office' still requires the end users to transit across a Sophos Central managed SDWAN because both the AD servers and the RemoteApp server are hosted offsite.

Historically if these same users connect to the Sonicwall firewall (also in our hosting location) with the NetExtender program they are able to "immediately" launch the ERP product once connected and the experience is the same as when they are in the office.

As part of our migration to the hosting service we tried using their SSLVPN solution (VMWare) and the user would receive a prompt to login to the server indicating that the delegated credentials were not working. When we initially began testing the Sophos SSLVPN I had the desired success connecting to the ERP solution while remote. But recently the Sophos Connect client began prompting the user to login to the server (before the ERP login).  

This first happened while running Sophos virtual firewall running 19 GA release, and while trying to fix it on that version I added a DNS/AD access rule to the same firewall rule that granted users access to the ERP application and it seemed to work for a time. This was still during our testing phase. There was another rule already existing that granted the same access but it seemed like adding the DNS/AD server to the same rule fixed it.

A few weeks ago we 'replaced' the 19 GA firewall with an MR1 release (not an upgrade, a replace). I began noticing the issue again in our testing, but when I tried to connect to the GA firewall it too had the issue.  Since the GA release now had the issue, I assumed it was client side and all other testing has been against the MR1 firewall. 

I tried several different one-off rules that turned off Heartbeat requirements as well as granting access to the full network in a single rule but was unable to resolve the issue on the MR1 firewall. Admittedly during these test I was connecting, trying to open the ERP solution immediately, getting the prompt and deeming it a failure. (This becomes relevant later)

I next started trying to see if the same issue was present with the IPSEC VPN client (still using the same local Sophos Connect install). I have had success with the IPSec client IF I wait a few minutes (I've tested down to 5 minutes so far) after connecting before launching the ERP program. If I connect and immediately try opening the ERP program I still receive the Server logon prompt. I assume that in part this has to do with Heartbeat authentication and I'm okay if the answer is wait a few minutes for the heartbeats to finish.

I took the "delay" approach back to the SSLVPN connection and that does not seem to "fix" the issue, even if I wait 10 minutes after connecting.

My primary question is why the different experience between the SSLVPN connection and the IPSEC connection. The rules on the firewall are the same, the local client install is the same, the "location of connection" is the same.

Firewall Information: SFV4C6 (SFOS 19.0.1 MR-1-Build365) 

Clients: Windows 10

Sophos Connect Client: 2.2.75



This thread was automatically locked due to age.
Parents
  • 0

    To resolve this issue, you need to enable "File and Printer Sharing for Microsoft Networks" and "Remote Administration", and lastly, you need to ensure that there are no network issues.

    Steps to enable "File and Printer Sharing for Microsoft Networks":
    Select Start --> Settings --> Network Connections.
    Right-click on Network Connection and select Properties.
    In the connection properties dialog, select the General tab.
    Select the "File and Printer Sharing for Microsoft Networks" and click OK.
    If you do not find this option, click Install button.
    In the network component type, select Service and click Add.
    Select File and Printer Sharing for Microsoft Networks and click OK.
    Click Close to exit the properties dialog

    Steps to enable Remote Administration in client machine's Firewall:
    Click Start --> Run
    Type gpedit.msc and click OK
    Expand Computer Configuration --> Administrative Templates --> Network --> Network Connections --> Windows Firewall --> Domain Profile.
    Right-click Windows Firewall: Allow remote administration exception, and then click Properties.
    Click Enabled, and then click OK.

    Make Remote Computer Reachable:
    Check whether the system is up and running when the scan is performed.
    Ensure that the DNS record for this computer is up-to-date in the DNS Server.

    Regards,

    Rachel Gomez

  • 0 in reply to Rachel Gomez

    File and Print Sharing is enabled on all my interfaces. 

    The computer(s) involved are accessible via ping. 

    The mentioned option for Allow Remote Administration is not available when I open the local Group policy, but I fail to see how this would apply for the following reasons:

      I don't believe the computer is not "on the Domain profile" when using the Sophos Connect client because it's starting up remotely.
      If I connect using IPSEC the issue does not present itself. If I use SSLVPN the issue does.
      The existing setup works for a different provider's SSLVPN connection but not the Sophos SSLVPN connection.

Reply
  • 0 in reply to Rachel Gomez

    File and Print Sharing is enabled on all my interfaces. 

    The computer(s) involved are accessible via ping. 

    The mentioned option for Allow Remote Administration is not available when I open the local Group policy, but I fail to see how this would apply for the following reasons:

      I don't believe the computer is not "on the Domain profile" when using the Sophos Connect client because it's starting up remotely.
      If I connect using IPSEC the issue does not present itself. If I use SSLVPN the issue does.
      The existing setup works for a different provider's SSLVPN connection but not the Sophos SSLVPN connection.

Children
Unfiltered HTML