DMZ

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

Web server in DMZ

Considerations

• The K2 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 K2 sites:
  • Autodiscover (optional but recommended – used to discover the best endpoint to connect to)
  • Identity (required, used for authentication)
  • K2API (optional, used by K2 mobile devices to connect to K2)
  • Runtime (required, used to access the SmartForms runtime site)
  • SP15EventService (optional depending on your requirement, used to allow SharePoint to trigger workflows in K2)
  • ViewFlow (optional, used to render the ViewFlow report)
  • K2 Workspace (Deskop) (optional, exposes the K2 Workspace (Deskop) site)
  • K2Services (Deprecated and optional, used by the old K2 mobile app v1)
  • Any other application folders used by custom apps
• The K2 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 K2 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 K2 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 K2. (Alternate domain approaches may also work if you configure the necessary trust. For these scenarios, you may need to contact K2 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 K2 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.