How to Secure Access to your WebDirect Solution Through a DMZ Setup

A common deployment request is to expose a WebDirect solution to the world while keeping the FileMaker Server itself securely behind a firewall, not directly accessible to the outside world. A setup that looks like the graphic below would put a WebDirect worker machine in a demilitarized zone (DMZ) to make it available while protecting the actual FileMaker Server.

Graphic showing a WebDirect worker machine in a DMZ setup
WebDirect worker machine in a DMZ

Unfortunately, this setup is very hard to make work properly and reliably. It requires careful fiddling with the required ports in the 16000 range to let the WebDirect worker machine in the DMZ communicate properly with its main server. Part of the issue here is that the load balancing baked into WebDirect requires all requests to be made to the main server that then forwards it to the worker.

FileMaker 19.6 introduces a new feature that helps solve this problem. The feature is somewhat hidden in the new ability to load-balance WebDirect with the use of Nginx Plus or Nginx Open Source.

WebDirect & Ngnix Plus

Nginx Plus is a commercial product that builds on top of Nginx Open Source and adds features such as high availability and active health checks.

Because Nginx Plus has different capabilities, there are some differences in how Nginx Plus vs. Nginx Open Source assigns a session to a WebDirect worker machine in a load-balancing scenario with multiple WebDirect worker machines. Reach out to us for a conversation about those differences.

Note:

For the purpose of this blog post, we are not concerned about load balancing, we just want to achieve secure access to WebDirect with a single WebDirect worker machine.

To achieve that, the free Nginx Open Source CAN be used to great effect. Here’s how.

Instead of exposing the WebDirect worker in the DMZ, all you need is an Nginx server that is exposed to the world.

You do need a WebDirect worker machine still, but it can now live inside your network behind your firewall.

Graphic showing a Nginx server exposed to the world rather than the WebDirect worker machine
Nginx server exposed to the world instead of the WebDirect worker machine

Looking at the schematic, you may be wondering: why not just open the firewall port on your network to allow WebDirect access directly? Why put an Nginx server in front of that?

Multi-tier Protection

The answer is multi-tier protection. Your network can now be set up to allow only incoming traffic from the Nginx server. Your network does not need to allow the world in just to reach your WebDirect solution. This is better protection than putting your WebDirect worker in the publicly available DMZ.

The instruction on how to set this all up are contained in this Engineering Blog: Scaling up FileMaker Server with load balancing and Docker containers on Linux. There is a lot of information packed into that article, most of which you will not need just to achieve a DMZ setup.

The main focus of the article is on achieving load balancing, which involves both a DMZ component and the load balancing mechanism. The DMZ server receives all requests and then decides which worker machine to assign the new session to.

The article breaks down into the following sections:

  1. Using physical or virtual servers
    • Using Nginx Plus as the load balancer
    • Using Nginx Open Source as the load balancer
  2. Using Docker images instead of physical or VM servers
    • Using Nginx Plus as the load balancer
    • Using Nginx Open Source as the load balancer

For this walkthrough, though, we are not interested in the load-balancing component; we will just focus on the DMZ part.

Unless you are already using FileMaker Server on Docker, #1 is the section for you. And unless you already have a subscription to Nginx Plus, or you do need the extra load balancing features and are willing to pay for Nginx Plus to get them, then 1b is the scenario for you, and it is the path we took for this walkthrough.

The Engineering Blog article assumes that your FileMaker Server and Worker will be using Ubuntu. They don’t need to be; they can be Ubuntu, macOS or Windows or mixed. Keep in mind though that one of the utilities mentioned below that will generate an Nginx configuration file, is only available in the Tools folder on a Ubuntu FileMaker Server.  If your FileMaker Server is Windows or macOS you will need to manually create that config file based on a Linux example.

  1. Install your main FileMaker Server as per normal, including an SSL certificate.  Ours is main01.ets.fm.
  2. After installation, leave the Web Publishing engine disabled (do not enable the web publishing engine or WebDirect)
  3. Stop FileMaker Server completely.
  4. Using your favorite text editor, modify the jwpc_prefs.xml file: locate the entry for mwperouting and change its value to no.
Changing value of mwperouting to no in the jwpc_prefs.xml file
Change the value of mwperouting to no

This effectively disables the native FileMaker Server WebDirect load balancing.

  1. Start the FileMaker Server again.
  2. Install your worker machine as per normal, including an SSL certificate, but do not add it to the main machine as a worker yet. Our worker is named worker01.ets.fm.
  3. Just like you did on the main machine, stop FileMaker Server completely and modify the mwperouting setting in the jwpc_prefs.xml file.
  4. Then start FileMaker Server again.

Assuming you also have your internal DNS entries set up to point those fully qualified DNS names (the names on the SSL certs) to the static IP addresses of your two servers, you can now assign the worker to the main server using their DNS names. In our experience, installing the SSL certificate and setting up DNS right away avoids a lot of hassle down the road.

  1. From the worker machine, add it to the main server. The easiest way to do this is from the command line:
fmsadmin wpe add main01.ets.fm worker01.ets.fm
  1. When successful, the admin console on the main server will look like the image below. With its own web publishing turned off and one active worker machine:
Admin console on the main server showing Web Publishing turned off
Admin console on the main server shows Web Publishing turned off
  1. On your main FileMaker Server machine, in the Tools folder with an NginxLB subfolder, there is a shell script named nginxLB.sh that will generate the required Nginx configuration file
nginxLB.sh shell script generates the required Nginx config file
The required Nginx configuration file is generated by the nginxLB.sh shell script
  1. Navigate to that folder and run
sudo ./nginxLB.sh
  1. When the script runs successfully, it will create a new file named fms_LB_HTTPS.user.conf in that same folder.
  2. Copy that file to a place where you can get it easily. You will need it on your Nginx server machine.

The next step is to set up that Nginx server. This is the server you will put in the DMZ, and it only requires Nginx; it does not need any FileMaker Server component.

  1. On a fresh installation of Ubuntu Server 20 or 22 LTS that we named dmz01.ets.fm:
sudo apt update && sudo apt upgrade -y
sudo apt install nginx
  1. Then stop nginx because it automatically starts a web server on port 80 that will conflict with the custom configuration that you will ask it to use.
sudo systemctl stop nginx
  1. Create a folder within your home folder:
mkdir lb

(which, in our case, will be /home/ubuntu/lb, your exact path may vary depending on your Ubuntu installation)

  1. and copy that freshly created nginx config file to it.
  2. Your nginx server will need an SSL certificate, and Nginx requires two files for that:
    • The certificate, including all intermediate certificates bundled into one file
    • The private key that matches the certificate (in FileMaker-speak: the serverKey.pem file)

If you have your certificate as an individual file and you have a separate intermediate bundle file, you can combine them easily with one command:

cat your_cert.crt your_bundle.crt > combined.pem
  1. Copy the combined bundle and the private key into that new folder.
  2. Use your preferred text editor to modify the nginx config file to match the location and name of your SSL files (lines 25 and 26). Note that I also enabled access and error logging on lines 12 and 14.
Screenshot of the Nginx config file with lines 12 and 25-26 highlighted
Modify the Nginx config file for location and name and enabling access and error logging
  1. And further down, change the two indicated lines (lines 151 and 153) to match what you see there since we are not using Nginx Plus but Nginx Open Source.
Screenshot of Lines 151 ad 153 highlighted in the Nginx config file
Lines 151 and 153 in the Nginx config file
  1. The blog calls for starting nginx and pointing it to the custom config file using the following command, but we won’t do that because on the next reboot, nginx would just go back to using its default config file instead of the custom one and your DMZ setup would break.
sudo nginx -c /home/ubuntu/lb/fms_LB_HTTPS.user.conf

(-c tells nginx to use a non-default configuration file)

  1. Find out where the default nginx config file is by running this command:
sudo nginx -t
Photo of running the the sudo nginx -t command to find the where the default nginx config file is
Running command to find where the default nginx config file is located
  1. Using your favorite text editor, replace the contents of the default config file with the following:

include /home/ubuntu/lb/fms_LB_HTTPS.user.conf;

Photo of replacing the contents of the default config file with content provided in the post
Replacing contents of the default config file
  1. Run this command again to make sure that nginx is ok with the configuration:
sudo nginx -t
  1. Start nginx
sudo systemctl start nginx

In your browser, you can now use your DMZ server to log into WebDirect:

Photo of using the DMZ server to log into WebDirect
Logging into WebDirect using your DMZ server

In our setup, both main01.ets.fm and worker01.ets.fm are behind a stateful firewall that only accepts incoming traffic from dmz01.ets.fm. Our FileMaker deployment is isolated from the world, but WebDirect is publicly accessible.

If you inspect the Nginx configuration, you’ll note that it also allows traffic on the admin console. If you do not want that, you can use the new Admin Console setting in 19.6 to restrict access to only certain IP addresses. Or you can remove the reverse proxy rule for the admin console altogether from the Nginx configuration.

Next Steps in WebDirect

WebDirect continues to evolve and can take your FileMaker application to the next step. If you have any questions about how to get started or your existing solution’s performance, our team can help. Contact us to get started.

2 thoughts on “How to Secure Access to your WebDirect Solution Through a DMZ Setup”

  1. Very nice breakdown of what could be (is!) a complex setup!

    Do you know if this configuration would also support using MS OAuth to log into the databases? I my attempts to use a worker in a DMZ we will still had to open up access to the main server for OAuth to work – which subverts the DMZ!

    1. It can definitely be made to work. The basis for it is in this blog post: https://www.soliantconsulting.com/blog/filemaker-custom-oauth-login-webdirect/
      We will soon have a “Part 2” that describes how to kick off this process from a different web site. It still requires some HTML/JS to be deployed on the main FMS machine but since the communication is from a known source you can whitelist access so that your FMS is only available from whatever known source you have. It’s a couple of extra hoops but I don’t see why it wouldn’t work.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top