Direct Access Multisite Issues RRS feed

  • Question

  • Okay here is one for you.

    We have two direct access appliances - Both have been configured seperately to ensure that they are functioning correctly (Network etc).

    I have then removed the configuration for Direct Access and reconfigured, we are operating in multisite.

    Clients will connect to the first Site fine DA1 and when I select the second site DA2 the clients will not connect completely.

    I can see the client in the remote access connections but but there is no user tunnel or infrastructure tunnel created.

    The client has an active IP-HTTPS interface, but no connection to any resources.

    The configuration was completed via the Remote Access GUI on the server.

    Since then I have reconfirmed that both appliances work by removing the configuration and setting them up one in turn and testing as singular devices.

    Da1 - setup and tested on own - worked

    Da1 - Configuration removed and gpo updated on all respective machines

    Da2 - setup and tested on own worked

    da2 - Configuration removed and gpo updated on all respective machines

    Then the current configuration is

    Da1 Setup first and multisite enabled with da1 as only entry point - working fine

    Da2 - configured as second entry point using wizzard - configuration fine  - all showing green for both servers, but clients cannot connect to da2 just show in remote connections with no authentication and an active IP-HTTPS adapter.

    Any pointers would be appreciated.

    Thursday, March 22, 2018 10:44 AM

All replies

  • It sounds like IP-HTTPS is connecting, but the IPsec tunnels are failing to establish, and the classic case of IPsec not establishing is usually related to certificates. I would start by making sure that you have a valid machine cert on both DA servers that chains up to the same root CA (from the same template - whatever template you are using on your DA clients as well).

    One other off-the-wall thought - make sure both of your DA servers are appropriately located inside Active Directory Sites. I recently had a MultiSite setup case where we had sort of a similar behavior, that the second site was having trouble working within the MultiSite config, and it turned out to be that the subnet where the second site was located did not have a Site defined at all inside AD. Once we fixed that and restarted the DA servers in that second site (they were running NLB array in each site), everything fixed itself. The reason this comes to mind is that they were having similar symptoms - IP-HTTPS would connect and you could even see the machine name inside the Remote Access console, but DA wasn't working on the machines. It was only working for those connected to the primary site.

    Thursday, March 22, 2018 1:10 PM
  • Thanks Jordan,

    In answer to the sites - we have an active/active data center onsite.

    The appliances internally are on the same subnet but externally they are linked through different internet providers.

    we needed multisite in this situation to provide data center resilience.

    Thursday, March 22, 2018 1:38 PM
  • Sorry, I meant inside AD Sites & Services - but if they are on the same internal subnet and one is working, then I assume that internal subnet is already a proper member of a Site inside AD.

    I would still check into certificates and make sure those look good, and I assume you have done the best practices of not using self-signed certs for IP-HTTPS, and moving NLS off to its own server/website (no longer co-hosted on one of the DA servers), those kinds of things?

    I can't say that I have ever tried (or heard of anyone trying) to setup up a MultiSite environment with both boxes on the same internal subnet, so maybe there is some kind of unknown issue there. If you are ever interested, there is an alternative way of doing DirectAccess across two different sites, more of a "Primary Site / Failover Site" way through a solution called Failover Client for DirectAccess (FC4DA). Disclaimer: I do work for IVO Networks who developed this solution, but please don't take this the wrong way - I'm not on the sales side of things. I was actually one of the primary drivers of building this solution because I bump into people all the time who don't really want the "connect wherever you want to" way that MultiSite works, but rather customers that want to have a primary site where their users connect all the time, unless something happens to that site and only in that case to go ahead and cut over to the failover site. So that is exactly how the Failover Client piece behaves. It's a client-side utility that knows about both sites, and swings over only in the event that it's needed.

    A side-benefit to doing FC4DA (since it's a client-side tool) is that your sites do NOT have to be configured in MultiSite. You set them up independently, different names, different GPOs, different everything - so they are completely independent sites which it sounds like works well in your environment.

    Feel free to contact me directly if you want any more info on that topic -

    Thursday, March 22, 2018 2:05 PM
  • One of the effective methods is this command: netsh interface httpstunnel show interfaces

    It will show you the error code, I managed couple of times to find the reason via this way.

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    Sunday, March 25, 2018 6:21 PM
  • Turns out there is an issue if you are trying to do multisite with the servers on the same internal subnet it is going to cause you an issue.

    Changed the subnet of the second of the server. Multisite then hey presto works fine.


    Monday, March 26, 2018 10:06 AM
  • Change the subnet of your second server, Just to avoid these type of errors, I have moved my WordPress to Cloudways managed WordPress multisite hosting ( and never faced any issue, It's quite easier to manage it on their platform.
    Thursday, February 7, 2019 7:37 AM