Automatically prioritize VPN adapter – Barracuda

Recently I had an interesting issue to resolve. We are deploying a new website with a soft launch within the company. We needed anyone on the office network to redirect our old website to the new website using DNS. The problem was that users that were working remotely would still see the old website when they are on VPN. When our users are using VPN, their DNS is being controlled by the network they are using instead of the VPN adapter. That caused them to always view the old website instead of the new website.

So… What did we need to do? We need to change the settings in the VPN adapter to use the DNS from the VPN adapter instead of the NIC adapter. Great! That’s easy, we can just open the Barracuda VPN Client and change the setting “Automatically prioritize VPN adapter” to “Yes”. Well, our end users are not local administrators on their workstations, which means that we would have to remote into every workstation and complete the change. We needed to run a script to change that setting.

What I ended up doing was running RegistryChangesView and captured a snapshot of the current registry. I then made the change on the Barracuda VPN Client. I then took another snapshot of the registry and saw that there was a registry key that was modified. I went to that registry key and changed it. The setting was also changed on the VPN client.

Now we need to find a way to create a script to change the setting and deploy it to all the workstations. This is where we use PowerShell to execute the modification of the registry key. The key was located in the following location:

The script I ended up using was and deploying with SCCM was:

SCCM deploys the PowerShell script and it modifies the setting in Barracuda VPN client. Running this script we were able to change the setting for all workstations without any action required from the end users. Now when users that are using VPN navigate to our current website, it will forward them to the new website through our internal DNS.

VPN – Virtual Private Network
DNS – Domain Name System
NIC – Domain Name System
SCCM – System Center Configuration Manager

http:// vs https://

When I was working on this website, I noticed that some of the links on my site were not using HTTPS and were set to use HTTP. An average user wouldn’t know the difference, but I’ll try to explain why this affects you just as much as it does the web host.

HTTP & HTTPS: What do they do, and how are they different?

HTTP stand for HyperText Transport Protocol. It’s a protocol that allows information to be passed back and forth between the web server and the clients. The important piece of this protocol is the “S”. You might have guessed it, it stand for secure.

If you visit a website or a webpage, you will notice that they usually begin with “http://”. This means that the website is sending information back and forth to your device browser through an unsecured language. In other words, it’s possible for someone to “eavesdrop” on the information being sent between the website and your web browser. This is one of the main reasons why if you are making a purchase or entering any password, you should make sure that the website you are visiting is using https://.

Site using http:// on Google Chrome would show 
Site using https:// on Google Chrome would show

I’ll try to explain it in a different way so its’s easier to understand. Lets say you are registering to a website and you are required to create a user name and password. If the website you are on is using http://, when you enter in the username and password and click submit, the information sent back to the website is not secure. Thus if someone or a device has unauthorized access it could potentially see the information being sent from your browser to the website. In other words they would see that you created a password “abc123”. Now if the website is using https://, they would see “c4B2sA4Vfsh6Deb” instead of your password. This means that the information that is sent between the website and your browser is secure.

Google has released an article recently stating that with the release of Chrome v68, Chrome will mark all HTTP sites and “not secure”.

Forcing HTTPS

If you are using a free SSL service such as Let’sEncrypt, you can generate an SSL certificate with them and install it on your website. Another thing you want to do is to force any links pointing to http:// to force it to use https://. One you can do this is by modifying your .htaccess file.

# Redirect HTTP to HTTPS
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

If you have any sub-domains, this will not force the redirects for them. You can generate a wildcard certificate or use CloudFlare and enforce https:// to be used for your website.

I’ll create a separate and more detailed post on how to access and edit the .htaccess file along with setting up CloudFlare for your website.