DMZ

One way to expose your product servers to internet users is to use a DMZ to host limited functionality in a secured section of your network. Typically, you host only the necessary sites on a web server in the DMZ, which in turn connects to your internal server.

Web server in DMZ

Considerations

• The product URL DNS entry should be the same for both internal and external users (you can configure different IPs for internal and external DNS)
• On the external Firewall, open the SSL web port (TCP 443) and expose the following virtual folders in the sites:
  • Autodiscover (optional but recommended – used to discover the best endpoint to connect to)
  • Identity (required, used for authentication)
  • API (optional, used by mobile devices to connect to the product)
  • Runtime (required, used to access the SmartForms runtime site)
  • SP15EventService (optional depending on your requirement, used to allow SharePoint to trigger workflows in the product)
  • ViewFlow (optional, used to render the ViewFlow report)
  • Workspace(Desktop) (optional, exposes the Workspace(Desktop) site)
  • Services (Deprecated and optional, used by the old Nintex K2 mobile app v1)
  • Any other application folders used by custom apps
• The Server and user segment must be able to reach the following public URLs using SSL (TCP 443) for external integration and authentication. This is also needed for the server to upload and access SharePoint documents and lists:
  • https://trust.k2.com
  • https://login.windows.net
  • https://login.microsoftonline.com
  • {Your SharePoint Online URL}
• The following ports must be open between the DMZ web servers:
  • TCP Port 5252 and 5555, used for Workflow and SmartObject/Management calls
  • Active Directory domain ports need to be open from DMZ to Internal (for more information see the article Active Directory and Active Directory Domain Services Port Requirements)
• If you are running Designer in the DMZ, you must open TCP port 1433 to allow SQL Server traffic for SmartObject calls.
• The easiest authentication approach is where the DMZ web servers are joined to the same domain as the product. (Alternate domain approaches may also work if you configure the necessary trust. For these scenarios, you may need to contact Nintex to help you plan out your deployment).
• If you are using a separate domain for the DMZ web servers, the account running the runtime app pool on the DMZ web servers should be an account defined in the internal domain (in other words, the domain where the server resides). In addition, you must configure the DMZ domain to trust the internal domain for authentication to succeed. The internal domain does not have to trust the DMZ domain.