How to force a Wi-Fi USB adapter on a Synology DiskStation to use 5GHz ac from 2.4GHz

Useful if your SSIDs are identical for 5GHz and 2.4GHz. Having your SSIDs setup like this seems to confuse Synology DSM, and for me it would always connect to the 2.4GHz network.

I had this particular issue where my TP-Link T4U ac wifi adapter for my Synology kept dropping down to using the 2.4GHz network, which slows it down dramatically.

To fix this, here’s what I did. Your mileage may vary, and you may end up disconnecting your Synology from the network, so make sure you have another way of getting to it (such as Ethernet) before proceeding with any of this!

SSH to the DiskStation, login as admin.

sudo -s to root account (same password as admin account)

Make a copy of your existing wifi config file inside /usr/syno/etc/wifi/

For me, I did:

Edit the original file with vi. If you don’t know how to use vi, do a web searhc (it’s not hard, but not easy either).

What you need to do is remove reference to the 2.4ghz network, which you can identify from the bssid, which is the MAC address of your router’s 2.4ghz radio. Once you’re done, the file should just contain details for the bssid that’s your 5ghz network. On my router, the MAC address for the 5GHz network was one hex number higher than the 2.4GHz network.

Next, make a copy of the wpa_supplicant file in /usr/syno/etc. For me, this was called: wpa_supplicant.conf.wlan0

Now edit the file, and change the bssid (which will be the 2.4ghz bssid MAC address) to the bssid MAC address of the 5ghz network.

Reboot the Synology diskstation, and when it comes back, it should be on the 5GHz network.

Install Citrix Cloud Connector on Server Core 2016


This post will provide some quick notes on installing the Citrix Cloud Connector on Server Core 2016.

Conceptual overview

  • We’re going to take our domain-joined Server Core installation and install the Citrix Cloud Connector on to it.
  • You can’t simply run the installer from the Server Core UI, because Server Core doesn’t have all the bits required for the Connector wizard to work.
  • So to work around this we’ll get an API Access key from Citrix Cloud admin UI and use that to install the connector silently on the command line.

Pre-requisites and considerations

  • It’s assumed you have installed Server Core 2016 and joined it to the domain.
  • I believe you’ll need an API access secure client entry for each controller you’re setting up. Happy to be corrected on this, but it feels like that’s the best way to go about this.
  • The API access key is tied to the Citrix Administrator. If that Adminstrator account is later revoked access or permissions changed, the API keys will stop working. More on this here.
  • As of right now (September 2018) installing the Cloud Connector on Server Core is not supported – however, the team is aware of appetite for this, and have a workstream open to do some testing with all the components.


Create an API Access secure client entry for the connector

Go to > Identity and Access Management > API Access tab

Enter a descriptive name of your Server Core VM in the “Name your Secure Client box” and click Create Client – I typically use the VM hostname so it’s easy to track which controllers are using which credentials. If you want to add more contextual info, do so. The field isn’t tied or reliant on the VM name at all.

Store the ID and the Secret given to you in a secure place. You’ll never be given the Secret again, so I’d recommend storing it securely.

Gather required information

To install the connector from the command line you’ll need the following information:

  • Citrix Cloud Customer ID
    • You’re told this just before you make the API access credentials, when entering a secure client name.
  • API Access secure client ID
    • You’re told this when you make the API access credentials
  • API Access secure client Secret
    • You’re told this when you make the API access credentials
  • The ID of the Resource Location you’re installing the connector into.
    • This is the UUID of the Resource Location, not its friendly name. You’ll find it in the Resource Locations – click on “ID” to view it.

Download the Connector onto the Server Core VM

Log in to the Server Core VM and run the following, replacing “yourcustomeridhere” with your Customer ID

Install the connector silently

Now, from the same command line, build your silent install command, replacing yourcustomeridhere, yourclientid,  yourclientsecret, and yourresourcelocationid with the information you gathered earlier, and run it:

That’s it. You won’t get confirmation that it worked, so you’ll need to check via Citrix Cloud

Check your Resource Location to verify connectivity

Go back to the Citrix Cloud UI and check your Resource Locations to verify if the connector is being setup. It can take a few minutes to complete.

Uninstalling the Cloud Connector

Should you need to Uninstall the Cloud Connector from Server Core, you can run:

It looks like this isn’t documented (not mentioned if you use /?) but it does work.

Further reading


Base image automation – download the latest installers for common apps with PowerShell


Long overdue, and inspired by @xenappblog and @CIT_Bronson, I’m finally documenting this.

In the Citrix RTST environment, we are frequently updating our base images with the latest common apps. To help with this, I cobbled together some scripts that will grab the latest version of apps like Chrome Enterprise, Firefox, VLC, Visual Studio Code, NotePad++, and FileZilla.

PowerShell Scripts

Below is a list of super-basic PowerShell snippets that will get the latest versions of software commonly installed on base images in a Citrix XenApp-Virtual Apps and Desktops-type environment. They include the URLs used; useful if you just need the URLs for your own purposes.

The key to all of these is the URLs used – most installers have special URLs you can use to get the latest installer, but the challenge is finding them!

Some of the techniques used in these scripts may be useful to help build scripts for other apps you may need for your environment.

You’ll need to change $output or -OutFile location to match where you want the installer to be saved.

Get Latest Google Chrome Enterprise

This will get you the latest stable build of Enterprise Google Chrome:

Get Latest Firefox

Get Latest VLC

Get Latest Visual Studio Code

Get Latest NotePad++

Get Latest FileZilla

Other resources

The End-User Computer (EUC) community, including Citrix Technology Professionals (CTPs) are already sharing their techniques for getting other apps, including Adobe Reader DC, XenServer tools, and Firefox. If you’ve got something to share, let me know in the comments and I’ll get it added!

It’s not what you say, it’s how you say it.

Something came up today that made me think about the importance of framing, and how it can be used to influence/persuade to meet your desired outcomes.

It’s not what you say, it’s how you say it.

It’s very easy to forget this – I do it all the time – but delivery is important. It can mean the difference between your idea being thrown out, or openly embraced. Sometimes, it’s the difference between burning bridges and maintaining relationships and partnerships.

Take this as an example:

You’ve been approached by a company to come and work for them. This company happens to be a very close partner with your current company. You want the new job, but you don’t want to jeopardise the partnership the companies have, or the relationship.

You might start your email off like this:

$partnerCompany has approached me to work for them, and I’d really like to persue this.

It gets the message across, and it is factually correct. That’s what happened.

But that might not be as well received as:

I’ve been dealing a lot with $partnerCompany recently as part of $project and an opportunity has come up that I’d really like to persue

There’s some, subtle, deliberate differences here:

  1. The first example is framed in a way that suggests that $partnerCompany has poached you.
  2. The second example is framed in a way that suggests that from working closely with them, an opportunity has come up, and it’s your decision to leave.

Why do these subtleties matter? Because you don’t want the partner companies to end up falling out. In both examples, you’re still announcing your intention to leave, but the second example may be less damaging to the partner relationship and thus, achieves your goal of getting the new job, and not damaging the partnership. Winner.

Creating a Site to Site Routed VPN using DD-WRT and OpenVPN


I needed to setup a site-to-site VPN between my home and my parent’s home, so that we can back up our stuff offsite – mostly documents and precious digital photos.


  • I wanted it to be a proper routed VPN network, not a bridged one. By that I mean an OpenVPN tun setup, not an OpenVPN tap setup.
  • I did not want to force the client to use the OpenVPN server as the gateway: I want both homes to use their own ISP for internet traffic. This is often referred to as split-tunnelling.
  • Must run both OpenVPN client and server on same DD-WRT router: For maximum flexibility I wanted to run both an OpenVPN server and client on the same DD-WRT router/gateway.


1 x DD-WRT router at my place, acting as an openvpn server
1 x DD-WRT (technically an ASUSWRT) router at the remote location, acting as an openvpn client

Conceptual setup

Local LAN:
Remote LAN:
OpenVPN network:

  • DD-WRT router acts as OpenVPN Server.
    • LAN IP: OpenVPN IP:
  • Remote DD-WRT router acts as an OpenVPN client.
    • LAN IP: OpenVPN IP:

If your LAN/IP setup is different, you should be able to operate a Find/Replace to change all these.

Some technical details

DD-WRT version: DD-WRT v3 – DD-WRT v3.0-r33679 std (11/04/17)

DD-WRT server assigns tunnel device as tun2
DD-WRT client assigns tunnel device as tun1
DD-WRT bridges ethernet and WLAN devices into br0

Considerations and gotchas

Most guides will get you *nearly* there

Most guides I found online for setting up DD-WRT for a site to site VPN with OpenVPN got me almost there, but didn’t quite finish the job. Many were also written over a year ago, and it seems DD-WRT has changed a bit since they were written. In addition, some threads where people were having issues seemed to give up on tun (routed) and switched to using tap (bridged) which wasn’t ideal for me.

Guides I found which may be useful to you include:

  1. Happydaddy post:
  2. D0ug has an interesting setup, including kill switches.
  3. Boogalooz guide:

Note that you’ll need to register for the DD-WRT forums to see the images/attachments alluded to in the posts.

Open the frontdoor

If your DD-WRT device is also your gateway (that is, it has a modem connected to it, and it acts as your internet gateway) you’ll need to open up the port for the OpenVPN server using IPTABLES. Some guides seemed to skip this.

You don’t really need to mess around with IPTABLES with the latest builds of DD-WRT

It looks like in the past you had to do a lot of messing around with IPTABLES on DD-WRT to get OpenVPNs to work – mostly to pass traffic between the OpenVPN tun+ devices and the Bridged device (br0) on the router. Now you can just use the GUI, as it seems to autoconfigure everything for you.

OpenVPN client with PBR and OpenVPN server don’t play nice

If you have a VPN client, using Policy Based Routing (PBR) on the same DDWRT router as your OpenVPN server, you’ll hit this issue: Put the suggested script from pastebin into your Startup Script and all will be well.

Symptoms for this issue are that you can ping from the Client network to computers inside the OpenVPN server’s local network, but not all IPs respond. It’ll turn out that the IPs that don’t respond will be in the PBR list for your OpenVPN client setup.

iroutes are important

One of the most common things I found was this symptom: You can ping from the client network to computers on the server’s network. But you cannot ping from the Server network back through to the Client’s LAN network. You can ping from the server network to the OpenVPN IP on the remote network ( in my case) but not the IP on the other side of the router on the LAN interface ( in my case).

The problem is that some of the guides you’ll find strewn around the internet don’t cover adding iroutes. Without adding an iroute to the OpenVPN client, you won’t be able to ping from the Server LAN to the Client LAN.

General setup

Create server and client keys

Sorting out the keys for the server and client is covered well in this post: This part of the setup is outside the scope of this blog post.

Configure the OpenVPN server

OpenVPN server setup in the DD-WRT GUI

Here’s how my OpenVPN Server config looks [images below]

  1. I’m using WAN up, and configuring as a Server instead of Daemon.
  2. Also using Router server mode instead of Bridge.
  3. Don’t forget to enable “Allow client to client” so that the clients can talk to each other.
  4. In additional config add:

Here’s the server conf file in case it’s useful:

Example Client config ovpn file:

Putting the contents of the ca, cert and key files into the ovpn files makes it much easier to import into an OpenVPN client. In my case, the ASUSWRT openvpn client wouldn’t accept these files individually, so I had to combine them in the ovpn profile file as above.

Additional configuration to make it all work as expected

Below are all the things I had to do in addition to general setup to make things work. That is, that both sides of the VPN could contact each other as expected in a site-to-site VPN.

Open the OpenVPN Port

Administration > Commands > Firewall Script

Add the following to the Firewall Script in DD-WRT.

Startup script to fix routing with OpenVPN client and PBR

Administration > Commands > Startup Script

Go here for the overview: and use the script in the pastebin link to fix the issue. Add it to startup via Administration > Commands.

Client config to provide iroute

Administration > Commands > Startup Script

Add this to the bottom of the PBR fix script text in the Startup Script section

This is what enables you to ping from server network to client network. Without this, you’ll be able to ping from client LAN to server LAN, but not from Server LAN to Client LAN. The script ensures that on each boot of the router, it re-creates the client configuration file in the /tmp/ directory on the DD-WRT router and adds the iroute command to the config file. When the remote client connects, it’ll pick up this iroute.

There’s some really good information on why this works here: but basically, openvpn doesn’t quite behave like it should, so even though you may have all the right routes setup, it won’t work unless you’ve configured an iroute for the client.

Put this in your Startup Script, just after the PBR fix text: