Conrad Sallian's community posts

Hi Steven,

The new Server version 2.7.9.0 is available for download.  If you are updating from 2.7.8.0 you may still need to restore permissions in your server book. If you have a simple permissions structure, i.e. one account that has full access to the entire book, just do the following:

1. Update to 2.7.9.0 "as is", i.e. just run the installer and complete the installation.

2. In the server address book manager expand Address Books, right click on your address book and select Edit address book.

2. Click Security.

3. In the security window enable Replace all child object permission entires with inheritable permission entries.... This will grant the account (principal) in the list permissions to all objects in this address book and restore permissions for the entries where they were deleted due to the bug. Therefore, when you sign in on the Viewer your "lost" entries should re-appear in Viewer address book.

If you have more granular access levels, i.e. other accounts with access to only some folders you will need to do the same procedure but on the respective folder level.

Let us know if you need any assistance.

Hi Steven,

We have just managed to reproduce the issue and confirmed that it's a bug on the server. This is how you can reproduce it: add a new connection to your synced address book in Viewer and then edit it, e.g. change its name. The connection will disappear from the Viewer book but will remain in the server book.

We will be fixing this bug and updating the server later today. The server version will be incremented too for you to be able to distinguish it from the current one.

Sorry for any inconvenience.

P.S. Viewer 6.10.8 and Host 6.10.8 are not affected by this bug, it's only the server that needs fixing.

Hi Steven,

The permissions are more gradual per folder. However the admin account I was using does have permission to everything. I can share the two address books with you if that helps.

Is it the same account with which you signed in on the server in Viewer? So this account has top-level access to the book and all its subfolders and connections.

BTW... I upgraded the RU Server back to 2.7.8 and so far I have not lost the same connection entries from the address books that was a problem before.

Did you also update Viewer to 6.10.8?

Hi Steven,

I try to keep the client and host versions in sync, but its not easy because the client will prompt for an update regardless of the host versions on the backed.

This can be disabled in Viewer Options -> Update. Besides, the update is never mandatory, the program just notifies you that a new version is available but it's always up to you whether to update or not.

In this case the client got updated first, then the RU server. The connection that got deleted was an older version (6.10.5) of the host software.

The Host version shouldn't be affecting the sync mechanism in any way. An address book record is just a record, its contents doesn't really affect how the sync mechanism works. We tried the same update order but didn't notice any issues.

See the attached screenshots images of the windiff of the files. The left side is the 2.7.6 version of the address book. The right side is the same address book after the 2.7.8 update. It appears the 2.7.8 update made some changes to the address book that may have caused the account I was using to lose access to the connection entry.

Yes, this is interesting. Could you tell me how exactly you set permissions for that book? Did you enable full access to the entire address book at the top level or was it more granular (folder- or even connection-based)? The more details the better - this will help us better reproduce the problem if it's somehow related to permissions.

Looking forward to your reply.

Hello Steven,

We have just quickly tested a scenario where we updated Viewer, then (without doing a sign in on the server) updated server, then signed in on the server and got the address book synced normally. There were no issues.

Now we are testing different scenarios, e.g. updating server first, Viewer second, and with different sign in states. That is why we asked in which sequence you updated the modules. Perhaps, the order was different in your scenario and we could thus try to reproduce it.

Looking forward to your reply.

Hello Alan,

Thank you for the clarification. Still, this requires a centralized system with our service at the center, and this is exactly what we moved away from (due to abuses of the system and antivirus software being angry at us about that as a consequence).

However, we may look closer at this idea when we start implementing an online account.

Hello Alan,

Thank you for purchasing a license!

and having some trouble with the file transfer portion of the app

Sorry for that, we will be re-writing the File Transfer module some time soon.

While setting up the MSI Installer, I had an idea about the email notification portion that I wanted to share. Paid users could have an online account that links to their installer that allows them to configure some of the extra options such as the authentication and email notifications of a new ID being generated. Then the application rather than sending the notifications through SMTP could relay that info to RemoteUtilities (or other repeater?) where the info could then be emailed to the user.

Implementing an online account is indeed in our plans for the future. However, making the installer send emails via our company-hosted script would be a step back to the mechanism which we have abandoned in favor of the "SMTP method".

The difference is that if the host gets decompiled, there is a chance of disclosure of where the emails are being sent, and maybe passwords as well. As it is I created a new gmail account, set it to forward to my normal account and then deletes it, wrote a script that auto flushes the trash every minute on that account so there is no record of it.

If you mean Host access passwords, they are not disclosed. When you choose "Automatically generate Host password" the password is encrypted with a public key on the Host side. In order to decrypt it one needs the private key which only resides on the Viewer side, initially in the Viewer where you actually built the installer although you can also copy the key to another Viewer.

If you mean the SMTP password though, it's indeed can be extracted from the installer but that's "by design". There is simply no other way to simultaneously protect the SMTP password and use it on the same Host. We explicitly warn the user about this:



Also, we do suggest that the user avoid entering their primary email account credentials and instead use a "disposable" email account for that single purpose of receiving Host notifications. Even if someone gets access to those emails they won't be able to connect to Hosts because of the above mentioned reasons - they won't be able to find out the password because it is never sent plain in an email. Besides, there is also two-factor authentication which can be enabled for added security.

Let us know if you have any questions. Thanks.

Hi Jorge,

That is good news. Thank you for the update. We'll be looking forward to a confirmation from other participants in this thread.

Hello Jorge,

Yes, but you can not ask them why they were totally blocked? ... so that it does not happen again

If only they would even respond to our messages. They never bothered to answer to our direct twitter messages, and their technical support is only available after you log in as their customer.  We called them on the phone and asked for a contact person with whom we could figure out how to resolve the issue but the call was forwarded to an automated voice response system and was never answered by technical support.

Why should we care about WatchGuard customers more than WatchGuard does? We are eager to help you - you can see that we respond almost immediately. But there is little we can do if some third party "security" company decides to block our software all of a sudden. We could ask for a reasons for such blocking if other firewall manufacturers did as well, but this is obviously not the case.

Hello Jorge,

Thank you for your message.

Did you try contacting the firewall manufacturer?