Thanks for the update, Sam. We'll be watching for it.

Hey Sam,

Have you finished your Whitepaper?  I have a customer who is also looking for details on the reverse proxy design with their LF Applications (Primarily Weblink)

Thanks,

Jeff Curtis

Unfortunately not. However, here are the general guidelines for reverse proxying WebLink:

Layer 4 (TCP) Reverse Proxy:

1. End-to-end TLS from client to web server is required. WebLink URLs must be configured for https/TLS.
   1. You must have the necessary TLS certificates for the above.
   2. You can either do TLS termination on the reverse proxy along with TLS to the backend, or pass-through 443 straight to the web server. You cannot do https/443 to the proxy and http/80 to the backend. 
   3. As you only want to expose the main WebLink application (/WebLink by default):
      1. Use the IIS IP Address and Domain Restrictions feature to restrict access to the /Designer (WebLink config) endpoint so it's not accessible through the proxy. Similarly restrict any other IIS application endpoints that should not be accessible through the proxy.
      2. Test that a browser request for "https://proxyurl.example.com/Designer" does not succeed and returns an HTTP 403.6 Forbidden or similar "denied" response.

Layer 7 (HTTP or "application aware") Reverse Proxy:

1. End-to-end TLS from client to web server is required. WebLink URLs must be configured for https/TLS.
   1. You must have the necessary TLS certificates for the above.
   2. You can must do TLS termination on the reverse proxy along with TLS to the backend. You cannot do https/443 to the proxy and http/80 to the backend. 
   3. As you only want to expose the main WebLink application (/WebLink by default):
      1. If available, use "path-based routing" to:
         1. Configure a routing rule for path "/WebLink*" (and/or other WebLink Virtual Directory path(s)) that sends that traffic to the backend web server.
         2. Configure a catch-all/default rule for anything not matching the "/WebLink*" pattern that has a hardcoded HTTP 301 Redirect response to "/WebLink/" (whatever destination page you prefer).
         3. Test that a browser request for "https://proxyurl.example.com/Designer" is automatically redirected to the main WebLink application URL you configured in the default rule instead.
      2. If path-based routing rules are not available, use the IIS IP Address and Domain Restrictions feature to restrict access to the /Designer (WebLink config) endpoint so it's not accessible through the proxy, as described for the Layer 4 (TCP) config above.
   4. Ensure the proxy is adding an "X-Forwarded-For" HTTP header so the backend is aware of clients' actual IP addresses instead of just the proxy's for logging and auditing purposes. Most should do this by default.

Avoid using "IIS Application Request Routing" (IIS ARR) as a reverse proxy if at all possible. It's miserable to work with. Just about any alternative will be better.

In most cases, I prefer to put Laserfiche applications that will be publicly exposed through a reverse proxy on their own server, separate from internal-facing applications. This has two main benefits:

1. It limits the security "blast radius" in the event of a misconfiguration.
2. It makes it easier to apply many types of customizations to only the public-facing apps.

If you have questions about configurations for a specific reverse proxy, feel free to ask.

Thanks Sam!!

Welcome =)

The instructions for Web Client are basically the same, except for Layer 7 you need to allow traffic to both of these endpoints (and for L4, don't block):

• /laserfiche*
• /LDPS
  • Laserfiche Document Preview Service, the in-browser Office doc viewer if you don't have the Office Online Server integration enabled

For Forms, if you have authenticated users who will access their inbox, you'd also want:

1. L7: An HTTPS listener on port 8181 for the Forms Notification Service. This connection will "upgrade" from https to "Websocket" after it's initiated, so the listener and backend must be configured to support websocket traffic if they don't already by default.
2. L4: A TLS (termination) or TCP (passthrough) listener on port 8181.

For LFDS(STS) to provide authentication for other public-facing proxied Laserfiche web apps:

1. Use a separate STS instance on a different server than the main LFDS service. It'd typically be one of the same servers hosting the proxied web apps it's providing auth for. This limits security blast radius and allows you to configure different authentication experiences for public-facing apps, such as limiting authentication options or UI customizations.
   1. Seriously, do not proxy directly to your main LFDS instance. This is playing with fire. If you absolutely must, use IIS IP Address and Domain Restrictions to limit access to the "/LFDS" Web Admin site to only internal IPs, ideally only a small management/server subnet, and explicitly block any of the proxy's internal IP addresses. Then test THOROUGHLY from the outside to make sure you can't get anywhere close to LFDS Web Admin from the public internet. But mainly just don't do it.
   2. Locking down the internal IP addresses that can access LFDS Web Admin even if you're not proxying anything is still a sound security measure.
2. L4: Don't block the /LFDSSTS app with IIS IP Address and Domain Restrictions
3. L7: Have a path-based routing rule for /LFDSSTS/*