Upgrading
Notes on upgrading Defguard and its components
Last updated
Was this helpful?
Notes on upgrading Defguard and its components
Last updated
Was this helpful?
Before doing any updates please remember to backup your database.
If you used the LDAP integration previously, it will be off by default after upgrading. You will have to manually enable it in the settings in the LDAP tab:
In Core 1.1.4, we've made email addresses case insensitive, as this is a standard for many major providers. Because the emails were case sensitive up to this point, you may end up with users with the same email addresses from core's point of view.
All email addresses must be unique case-insensitively, meaning that a user with an address address@email.com
can't coexist with another user with an address ADDRESS@email.com
. Before upgrading, make sure you don't have any users with the same email addresses given the above. If you do, please change those addresses or remove the users altogether. Remember to check it case-insensitively. If you have users with duplicate email addresses, the migrations will fail and you won't be able to upgrade.
You can use the following SQL query to locate users with duplicate emails in the database:
There is a new setting:
ENV Variable: DEFGUARD_PROXY_URL
command line argument --url
/etc/defguard/proxy.toml: url =
Which should be set to the same value as in core DEFGUARD_ENROLLMENT_URL
When upgrading core to 1.0.0 (even to a 1.0.0 pre-release) make sure that your users have unique email addresses as we've introduced a constraint requiring email addresses to be unique among users.
If you have duplicate emails in your database, the migrations during the upgrade process will simply fail.
You will need to change a duplicate email address before the upgrade by hand via the Defguard dashboard or by accessing the database.
To enable this on an already configured desktop client one must perform one time instance update, which will generate necessary tokens on the client to perform from now on automatic updates. In details:
Any client that is configured from scratch has this done automatically and no actions needed to be done.
In this release, we have hardened the security architecture, and since the Proxy component is open for HTTP commands and is frequently communicating with Core we have reversed the communication and now Core is connecting to Proxy (Proxy is a gRPC server and Core is the client).
This way if Core is in a secure network segment (like Intranet) and Proxy in a DMZ segment (where Internet traffic is allowed) you don't need to open on your firewall rules for Proxy from DMZ to connect to Intranet (no packet for New Connections from DMZ->Intranet).
This change requires a few changes if you are upgrading:
Remove DEFGUARD_PROXY_UPSTREAM_GRPC_URL
variable - since Proxy does not connect to defguard Core any more.
Proxy is now the server to which defguard Core connects, so you may want to:
Optional: configure non-default Proxy gRPC port with DEFGUARD_PROXY_GRPC_PORT -
default value is 50051
If you have a Proxy in a different network segment - eg. have a custom installation (not with one-line install/docker compose all on one server) - you may also consider exposing the gRPC port and reverse-proxy (nginx/treafik/...) the port with SSL/TLS.
Also adjust your firewall config to open new Docker port mapping etc. Make sure Proxy gRPC server can be reached from Core.
Add DEFGUARD_PROXY_URL
variable to point to your Proxy gRPC server endpoint, for example http://proxy:50051
when using Docker Compose - or any gRPC URL you have configured with your reverse proxy.
(Optional) If using SSL configure DEFGUARD_PROXY_GRPC_CA
Update Core & Proxy images/binaries and restart services.
You should see in the logs that Proxy is awaiting a gRPC connection - example docker logs:
Core should be attempting to establish a gRPC connection with Proxy (and retrying every 10s if unable to successfully connect), like this:
After defguard connects successfully to proxy, you should see in proxy logs:
With this release we have added Multi-Factor Authentication to the desktop client. Unfortunately desktop client database has change significantly as well as business logic (for example endpoints to proxy for MFA handshake). We have not stored them previously in the database - thus they cannot be recovered/updated automatically.
That unfortunately means you have to remove all your instances before upgrading (or just remove any desktop client configuration files, including the database) and start the enrollment (adding new instance) again after upgrading - just by adding a new device (you can remove the old one).
From 1.0.0 we have introduced , and one of them is .
The admin must generate a new token for the client - (token can be sent over email or shared in any other secret way).
The user must perform the .
(Optional) If you want to use SSL with Proxy gRPC server without revers-proxy (nginx/etc) configure DEFGUARD_PROXY_GRPC_CERT
and DEFGUARD_PROXY_GRPC_KEY
following the .