How can we help you today?
Firewall Settings for MyWorkDrive Server
Contents
Overview
Administrators my wish to lock down the MyWorkDrive Server client site to be accessible from only restricted networks or not publish the site and allow access from internal LAN segments only. This would typically be used where the administrator wishes to provide access to the Web File Manager site for view and editing documents in Office 365 but restrict external access. View typical network deployment scenario diagrams here.
Firewall lockdown is possible and MyWorkDrive will function and allow Office online document editing even if restricted to company WAN IP’s or LAN segments only with the following caveats:
- OneDrive external file sharing will not function ( a publicly accessible Web File Manager URL is needed for Microsoft to copy files to OneDrive) unless the server can access https://*.live.com and https://wp-onedrive-api.wanpath.net for OneDrive external sharing.
- An internal host name must be used to reference the site for internal file sharing – for example: https://share.mycompany.local if referenced on the internal LAN only.
- Office 365 Editing must be enabled on the MyWorkDrive Server Admin Panel.
Please note Office online editing will function even if the Web File Manager client site is locked down since it is made available during Office online editing transactions on a session basis through our MyWorkDrive reverse proxy in Azure locked down to Microsoft Office online hosts only. Full details are in this article. In additional to firewall lockdown we also recommend disabling unneeded ciphers. See our Steps to lock down IIS SSL for Compliance and Security for additional information.
Outgoing firewall requirements
To function correctly the MyWorkDrive Server needs outgoing access to the following hosts and TCP ports:
- MyWorkDrive license servers at licensing.wanpath.net on SSL port 443
- Port 443 to *.live.com for OneDrive external sharing along with Office 365 URL’s and IP address ranges per Microsoft article here.
- Port 443 to login.microsoftonline.com for OIDC connections, when using Entra ID or Saml SSO with Active Directory, per Microsoft’s article, here
Server Version 5.4 and higher relay requirements:
For customers using CloudFlare Tunnels (formerly Argo Relays) with any of the following options
- Publishing your website to the internet with Cloud Web Connector (x.myworkdrive.net)
- Office Online Editing using MyWorkDrive hosted apps for Graph API connnections
- OneDrive or SharePoint Storage using MyWorkDrive hosted apps for GraphAPI connections
- Entra ID Identity with MyWorkDrive hosted app for graph API Connections
- or connections to Azure Storage using MyWorkDrive hosted apps (Graph API connections)
Those connections are relayed through Cloudflare Tunnels. Cloudflare requires TCP port 7844 outbound from your server to Cloudflare IP’s. MyWorkDrive recommends a direct internet connection – outgoing proxy services (typically web filtering) may break Office 365 online editing features and MyWorkDrive.net usage.
Beginning with version 5.3 an outgoing proxy server may be specified in the MyWorkDrive Admin Panel under settings in the format of http://hostname or IP Address and optional port number. For example http://10.10.10.10 or http://10.10.10.10:8888.
Server Version 5.3 and below relay requirements:
Relays are no longer supported on server 5.3 or lower. Upgrade to 5.4 Server or higher.
Antivirus
Warning: Antivirus software installed on the server can interfere with the ability for your MyWorkDrive to communicate with Microsoft Azure for our Office 365 and Cloud Connectors if any firewall features are enabled. Review our Antivirus article for settings and exclusions.
Troubleshooting Office 365 and Cloud Connector firewall issues
If basic troubleshooting of the cloud connector fails using this article begin additional troubleshooting by ensuring the Office 365 Editing feature and/or the cloud connectors are enabled on the MWD Server admin panel under settings. If enabled, check services.msc on your server for “Cloudflared Tunnel Agent” . It should be running.
If the service is running and has been for at least 15 minutes, next test outbound firewall access. From a command prompt, type “Netstat -b”. Note any connection for portbridge. A healthy service should show something like below with https and 7844 ports open and in and “ESTABLISHED” state.
If these are missing, check our outgoing firewall rules, remove any Antivirus software from the MWD server and ensure your MWD server has full internet connectivity. Then run netstat -b again to see if outbound connections are established.
Netstat -b healthy outbound connections Cloudflare:
[cloudflared.exe] TCP 192.168.41.111:56200 198.41.200.233:7844 ESTABLISHED
[cloudflared.exe] TCP 192.168.41.111:56201 198.41.192.107:7844 ESTABLISHED
[cloudflared.exe] TCP 192.168.41.111:56202 198.41.200.113:7844 ESTABLISHED
[cloudflared.exe] TCP 192.168.41.111:56208 52.230.222.68:https ESTABLISHED
Test communications on port 7844 outbound to Cloudflare tunnel service:
Launch powershell on the MyWorkDrive server and type the following command:
test-netconnection -computername 198.41.192.7 -port 7844 (This IP may not be available, you can check your Cloudflare log in the MyWorkDrive logs for IP addresses the connector is attempting to use)
The results should come back like below with:
TcpTestSucceded:True: ComputerName : 198.41.192.7 RemoteAddress : 198.41.192.7 RemotePort : 7844 InterfaceAlias : Lan SourceAddress : 10.10.200.20 TcpTestSucceeded : True
If TcPTestSucceded returns false a firewall or antivirus is blocking TCP port 7844 outbound from the MyWorkDrive server and needs to be investigated.
Clustering
If you have clustering enabled with clustering of configuration files on an SMB path, All MyWorkDrive servers need to be able to reach the cluster config files via SMB.
If you have clustering of Sessions and Locks enabled via database, All MyWorkDrive servers need to be able to reach the database via the appropriate ports
Microsoft Settings (typically tcp port 1433)
PostgreSQL settings (typically tcp port 5432)
DMZ / LAN Ports and connections
MyWorkDrive has no requirements about placement regarding firewalls or use in a DMZ. It is up to you where you wish to place the MyWorkDrive server and how you want to make allowances for necessary connections to network resources.
For internal connections to LAN resources (AD, LDAP, SMB, DNS, etc,) MyWorkDrive uses traditional networking ports when connecting to LAN resources using Active Directory Identity (Entra ID Identity in Version 7 and later does not require LAN resources).
All external connections to the MyWorkDrive server inbound are on 443 (or the ports you choose when publishing with Proxies/Reverse Proxies) and 7844 outbound when using the Cloud Web Connector or cloudflare tunnels with Office Online or OneDrive/SharePoint/Azure storage.
LAN Ports Required
For MyWorkDrive using Active Directory Identity
Per Microsoft
and community discussions, these ports are required for servers to communicate with Active Directory and SMB resources.
High Number Dynamic Port Range
LDAP uses a high number dynamic range and these ports must be available for devices placed outside the firewall or in the DMZ to communicate with AD and Network Resources. You cannot block these ranges and have proper function with Active Directory
Start port: 49152
End port: 65535
9389 ADWS
MyWorkDrive uses ADWS as part of the strategy to look up user group membership. Please ensure 9389 is available to the MyWorkDrive server.
Secure LDAP LDAPS 636 and 3269
MyWorkDrive doesn’t directly connect to LDAP or AD. MyWorkDrive connects through the domain joined server MyWorkDrive is installed on. Connection to LDAPS is made between the host computer and domain, so if you wish to use LDAPS, ensure it is configured on the domain and the Windows Server MyWorkDrive is installed on is properly configured.
Both 636 and 3269 are required for proper operation.
Reference
https://learn.microsoft.com/en-us/archive/technet-wiki/18254.active-directory-ldaps-636-and-msft-gc-ssl-3269-service
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-ldap-over-ssl-3rd-certification-authority
Community Discussion
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/ff0fc815-69be-4239-8a03-27cfd444d04c
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/406bdeb4-3a52-422e-84c3-bf9444fc1751
https://petri.com/enable-secure-ldap-windows-server-2008-2012-dc/
LDAP with Channel Binding Alternative
https://4sysops.com/archives/secure-domain-controllers-with-ldap-channel-binding-and-ldap-signing/
