Hi Timothy,

I'm glad to hear you found my Empower talk and hope you found it informative. 

In most scenarios, the recommended configuration is to add a dedicated "external" Forms server within the internal domain network and use a public-facing reverse proxy to forward HTTPS/443 traffic to that server, as shown in this example diagram from the presentation:

To configure the "external" Forms server, you follow the Standard configuration instructions in the usual "Configuring Forms 11 in a DMZ" white paper, with the significant exception that you should not modify the SecurityMode anywhere. Because the "external" Forms server is on the same domain network, it can leverage all of the built-in/automatic AD-based security and encryption mechanisms.

Why have a separate server at all? Two main reasons.

1. Limits security "blast radius"
2. Allows for external-facing customizations you may not want to apply to the Forms instance(s) your internal users go to, including but not limited to different DNS names, authentication paths, etc.

Still, there are potentially reasons to deviate from that design. Have you gone through and answered the questions in the External Access Use Cases section of the presentation? If you can provide answers to the first two sets of questions, I can provide more tailored guidance. Any "counterpoint or cautions" would generally be in context to the use case.

If you don't want to post those responses publicly for whatever reason, please send them to your Solution Provider and request they send them along to the Laserfiche Presales team with a reference to this Answers post. That'll make it to me.

I'll reproduce the questions below for reference:

External Access Use Case Objectives

What are you trying to do?

• Provide unauthenticated access to public forms and documents?
• Provide vendors an authenticated portal to handle form submissions?
• Provide students access to forms?
• Provide general access to remote employees?
  • Almost always a bad reason, figure out a VPN solution

Use this information to answer three critical questions

First question(s)

• Will users be Authenticated, Unauthenticated, or a mix?
• If Authenticated:
  • How will they authenticate?
    • Laserfiche (LFDS) users?
  • SAML users?
  • How will they be provisioned and licensed?
    • Laserfiche (LFDS) users
      • Roll your own manual or programmatic provisioning process
    • SAML users
      • Just-In-Time (JIT) / Self-Registration
    • SCIM

Second question

• Which Laserfiche components are involved?:
  • Forms / Forms Portal
  • WebLink
  • Web Client
  • Directory Server WebSTS
    • LFDSSTS = login page
    • Never directly externally expose /LFDS Web Admin itself
  • DocuSign Connector
  • API Server (new)

Third question 
(this is what you're trying to answer, and can depend on responses to the prior questions)

• Reverse Proxy or DMZ server(s) as network access method?
  • Reverse proxy can be layer 4 (TCP) or layer 7 (HTTP)
    • Preferred method in most cases, especially with Forms
      • Greatly minimizes required firewall holes
  • If pointing at same servers for internal use, requires “double-sided” DNS
    • Be aware of security considerations; often better to use a separate “external” server
  • If load balancing, enable session affinity (“sticky sessions”)
    • Client IP-based affinity usually ideal, otherwise cookie-based
• DMZ servers
  • Deceptively simple.