Windows 10 NIC Teaming and PowerShell

In recent months (as of this post), Microsoft decided to apparently cripple the UI panels for Teaming, VLANS, and a few other options in the Network Interface properties tab section. On update 1903 of Windows 10 Pro, this was very much so the case – no UI, but only PowerShell commands.

Assumptions:

  • You have already created a LACP/LAGG on the Switch/Router/Whatever the NIC on the machine is connecting to.
  • The NIC Team Ethernet ports are active to the switch.
  • Your switch and ethernet NIC supports IEEE 802.3ad Dynamic Link Aggregation, AKA LACP.

The Tutorial…

Here’s a step by step to getting Teams (Teaming) functional on Windows 10 Pro using an Intel based NIC… with PowerShell.

  1. Remove any and all teams that exist on your machine – consider this a clean install of a team.
    • You will need to go to the Device Manager on the machine and remove the team, then remove the adapter drivers.
    • Ensure you’ve UNINSTALLED the drivers, not just a simple remove from the Device Manager.
  2. Download the Intel v24 (or whatever version it’s on now) from the Intel website: https://downloadcenter.intel.com/download/25016
  3. Install the proper-bit variant version for your machine… chances are, it’s x64.
  4. Once installed, let Windows 10 re-detect the Intel NIC’s.
  5. Once re-detected, we’re going to PowerShell.
  6. Right click your start menu and click “PowerShell (Admin)” or WinKey + R, Type in “powershell” without the quotes, OK.
    1. PowerShell HAS TO BE RUN as Administrator – otherwise, this goes south, quick.
  7. Let’s get an idea of what Interfaces you’ve got running. Type: Get-IntelNetAdapter and press enter.
    • Note the interface NAMES that you wish to create a team of.
  8. Once we know the adapters to create a team of, we’ll be inputting the following command: New-IntelNetTeam -TeamMemberNames "Intel(R) Ethernet Server Adapter I350-T2 #2","Intel(R) Ethernet Server Adapter I350-T2" -TeamMode IEEE802_3adDynamicLinkAggregation -TeamName "Team01"
    • For me, I have a dual-port i350-T2 ethernet adapter – it gets the job done, and makes this process easy.
    • Team01 can be named whatever you wish it to be, but for simplicity sake, keep the name basic.
  9. When creating a team, it took about two minutes for this process to complete on my machine. It may appear frozen, but it’s working its magic.
  10. Once completed, the console will report back that the Primary and Secondary adapter was “NotSet”, let’s fix that…
  11. Type in: Set-IntelNetTeam -TeamName "Team01" -PrimaryAdapterName "Intel(R) Ethernet Server Adapter I350-T2 #2" -SecondaryAdapterName "Intel(R) Ethernet Server Adapter I350-T2" – You’ll need to replace the adapter name to whatever your adapters names are.
  12. This should take about 30 seconds tops.
  13. Once completed, the NIC should attempt to auto-negotiate a DHCP address using the primary NIC cards MAC address.
  14. Confirm the changes applied, type in Get-IntelNetAdapter once more to see if TEAM: was applied as a prefix to the desired NIC’s to be Teamed.

Here’s a screenshot of the three commands used as listed above…

The creation and set process.
The final check.

UniFi Guest Network with pfSense

A starter’s guide to getting UniFi’s guest network functional with a pfSense installation.

pfSense in its own regard is an amazing piece of software that works just about on any combination of hardware… only just that its WiFi support (as of June 2019) is rather limited. Which is where Ubiquiti’s UniFi software and line of hardware come into the mix.

This article assumes that you…

  1. Have full admin rights to both pfSense and UniFi GUI panels. Amazingly, no need for a terminal window!
  2. Know your way around both pfSense and UniFi’s control panels.
  3. Dedicated running UniFi machine/instance for the UniFi controller. I run my UniFi on its own dedicated VM. The CloudKey should also function for this.
    • This is required for the hotspot manager!
  4. Have a decent understanding of the hotspot manager (if you so desire to use that vs normal guest ‘connect’ button auth)
  5. Understand how VLAN’s function.
  6. Know what IP range and subnet size you’ll be allocating for the Guest network.

General Notes

  • Using UniFi version 5.10.x series.
  • Using pfSense version 2.4.x series.
  • Majority of UniFi hardware (Switch/AP’s) running firmware 4.x (4.0.42.10433 at time of writing)
  • Guest VLAN is ID 48.
  • Guest IP Range is 10.48.1.1/24.
  • Main network is 192.168.20.1/22.

Let’s get UniFi setup first before touching pfSense…

  1. Login to the UniFi controller. Your URL to access it will be different from mine.
  2. Go to the global settings page. (That’s the cog wheel at the bottom left)
  3. Click “Guest Control”.
  4. Set the following settings…
    • Guest Policies
      • Guest Portal: Checked (Enabled)
      • Authentication: No Auth (HINT: The guest still has to click the “Connect” button in the walled garden)
      • Expiration: 24 hours.
      • Landing Page: Redirect to the original URL.
      • Redirection: Should be all unchecked (all buttons should be disabled regardless)
    • Portal Customization
      • Template Engine: Angular JS
      • Override Default Templates: Unchecked (No)
      • Title: This is what your guests will see on desktop/laptop machines. Name it aptly. Mine is simple: CWireless Guest Portal.
      • Welcome Text: Checked (Enabled).
        • Click “Edit”.
        • Your text can only be plain text. It’s parsed as is. This is what my guests see…
      • Terms of Service: Unchecked (No).
        • Unless your company or whatever requires a waste of bandwidth legal book to be attached, no need for this to be enabled.
      • Text Position: Above Boxes
      • Languages: en / English (Default).
      • Portal Customization…
        • Custom Logo: Unchecked.
        • Background Image: checked – if you want to use a neat background that doesn’t make people question your sanity.
        • Colors: Set these to your needs.
        • Box Opacity: If your image used isn’t too jarring, set the opacity to something sane between 40 to 100%. (Or disable it at 0%.)
      • Access Control
        • Pre-Authorization Access: None – leave empty.
        • Post-Authorization Restrictions: Your actual LAN subnets. For me, it is 192.168.20.0/22.
  5. Apply Changes.
    • First part completed!

UniFi “Networks” section

This part is quite straightforward.

Go to Settings -> Network -> Click “Create New Network”. Assuming you’ve already have a “Corporate” (your main LAN) network setup.

At this point, you should see a new page show up with a bunch of input boxes for variables. It may look menacing, but it’s quite straight forward.

From the top down, here’s the values that I have set….

  • Name: Guest Net
  • Purpose: Guest
  • Interface: LAN (useless in our case since we don’t use UniFi’s security firewall hardware!)
  • VLAN: 48
  • Gateway/Subnet: 10.48.1.1/24
  • Domain Name: This can be an addon to your main networks domain name or something unique. In my case: guest.home.lan
  • IGMP Snooping: Unchecked.
  • DHCP Mode: None (pfSense does this leg work!)
  • DHCP Guarding: Unchecked.
    • If you’re a business or something of the sorts, check this and slap in your DHCP server(s) to the list.
  • UPNP LAN: Unchecked (useless without USG)
  • Configure IPv6: None (This isn’t quite fleshed-out on UniFi in some setups)

Poke ‘Save’. You should now see something like this on your Web GUI:

UniFi “User Groups” section

What fun is a guest network without slowing down those blazing fast internets to good ol’ ADSL speeds?!

Go to Settings -> User Groups -> Click “Create New User Group”.

Name it “Guest” (or something that lets you know said user group is for the guest network).

Check both Bandwidth Limits. Set both speeds in terms of Kbps or Mbps. For me, I cap each guest to 5Mbps down, and 512Kbps up.

UniFi “Wireless Networks” section

Go to Settings -> Wireless Networks -> Select your WLAN group (I don’t use the “Default” here – as pictured below) -> Click “Create New Wireless Network”.

At the Create New Wireless Network page, name the broadcasted wireless network (end-users will see this on their devices).

Ensure the Enabled box is checked/ticked.

Security needs to be Open.

Check the Guest Policy box. An “Alert” info box should appear.

Click the Advanced Options section.

Ensure the following settings are set…

  • Ensure “Block LAN to WLAN Multicast and Broadcast Data” is checked – it should be checked, as you enabled Guest Policy above. 🙂
  • Excepted Devices: Leave Blank
    • Unless you’ve a compelling reason that a range of MAC’s should be broadcasting/multicasting.
  • VLAN: Set to 48
    • Or any number for that matter between 2 and 4096 – you’ll need to know this VLAN ID number for later.
  • Hide SSID: Unchecked.
  • User Group: Guest.
  • UAPSD: Unchecked.
  • Scheduled: Unchecked, unless you’re pedantic when this SSID should be “active” to be connected to and used.
  • Multicast Enhancement: Unchecked.
  • High Performance Devices (Beta): Leave unchecked.
    • Have had mixed results with that enabled on the guest SSID.

Additional Advanced Settings

802.11 Rate And Beacon:
DTIM Mode: Use Default Values.
Leave everything else as is.

MAC Filter:
Leave its sole option unchecked.

RADIUS MAC Authentication:
Enabled: No/Unchecked.
Leave the rest as is.

Click Save.

UniFi should begin auto-provisioning your UniFi AP devices due to the new AP addition. This could take anywhere between 15 seconds to one minute.

Check UniFi devices list.

If you’re not using the “Default” wireless profile via the “WLAN Group” dropdown from the previous section above, you can likely skip this step. However, it’s always safe to double check!

At the top of the devices list (not your clients list), click the “Filter By” button, set it to APs. You should now see your AP’s only, and nothing else!

Select the top left checkbox to select all devices to edit.

Click the top left checkbox. Click “Edit Selected” below.

Ensure your management VLAN is your primary LAN VLAN, not the Guest VLAN (don’t want a random smart person figuring messing with things now! 😉 )

Your dropdown should look similar to the image above. Select LAN if you’re unsure, click Queue Changes, then Apply Changes.

Your AP’s should begin to auto-provision/reprovision the changes.

To PfSense We Go!

Login to your pfSense web GUI – I don’t know what your port or IP to your pfSense box is!

Creating the VLAN on pfSense

Head over to the Interface Assignments landing page. (Interfaces -> Assignments from the menu)

Click VLANs tab, and then click on ‘Add’.

Ensure you’re creating a VLAN on the LAN interface, or the interface within your network that will be tagged for Guest/ VLAN 48.

  • Parent Device: LAN
  • VLAN Tag: 48
  • VLAN Priority: Leave Blank. If you use a traffic shaper on pfSense (not UniFi), you can set a priority and then control that in the shaper.
  • Description: Name it your guest wifi networks name for ease of remembering what it is for. Mine is “CWireless Guest”.

Save and apply configuration – if that little box shows up.

Applying the VLAN on pfSense.

Go to “Interface Assignments” within the Interfaces section.

At the bottom, where it says “Available Network Ports”, find the VLAN you made for the Guest wifi network. Click Add. Once the page reloads, click the new interface created. Generally, it shows up as OPT#. Where # is a value.

Edit and Apply the VLAN

For me, I have a habit of naming my interfaces in the form of 0000_Name, where 0000 is an ID of sorts. With the Guest network, I went with 0048_Guests. 0048 being VLAN 48. Easier to sort by IMHO.

In the Interface editor, we’ll need to input the following details…

  • Enable: Checked
  • Description: 0048_Guests
  • IPv4 Configuration Type: Static IPv4
  • IPv6 Configuration Type: None
  • MAC Address: Leave blank.
  • MTU: Blank
  • MSS: Blank
  • Speed and Duplex: Leave at Default.

Static IPv4 Configuration

  • IPv4 Address: 10.48.1.1
  • IPv4 Subnet: 24
  • IPv4 Upstream GW: None

Reserved Networks

  • Block private networks: Unchecked. You can check it if you’d like, but firewall rules can be set later.
  • Block bogon networks: Unchecked.

Save!

Firewall Rules

Go to Firewall -> Rules -> “0048_Guests”

We’ll be adding a few firewall rules here. One to permit traffic from Guests to the internets, one to block anything to LAN nets excluding the Guest UniFi portal.

It is very much so worth noting that this is a failsafe (or if someone somehow manages to bypass things) if you fail to configure the post-auth guest restrictions via the UniFi controller.

Your firewall rules should look something similar (or exact) to the rules below (screenshot below).

  • First Rule:
    • Action: Allow
    • Disabled: Unchecked.
    • Interface: Guests
    • Address Family: IPv4
    • Protocol: Any
    • Source: Any
    • Destination: Single Host or Alias, 192.168.20.200
      • NOTICE: 192.168.20.200 is the Unifi instance. Your UniFi’s control panel IP will likely be different, so know it. Make sure it’s static (be it via DHCP Static or Machine static) as well!
    • Log: Checked (Optional)
  • Second Rule:
    • Action: Block.
    • Disabled: Unchecked.
    • Interface: Guests.
    • Address Family: IPv4+6.
    • Protocol: Any.
    • Source: Unchecked, Any, blank.
    • Destination: Unchecked, LAN net (my lan network is named 0001_LAN), blank.
    • Log: Checked (Optional).
  • Third Rule:
    • Action: Block.
    • Disabled: Unchecked.
    • Interface: Guests.
    • Address Family: IPv4+6.
    • Protocol: Any.
    • Source: Unchecked, Any, blank.
    • Destination: Unchecked, This firewall (self), blank.
    • Log: Checked. (Optional)
  • Fourth Rule: (To the internets!)
    • Action: Pass
    • Disabled: Unchecked.
    • Interface: 0048_Guests
    • Address Family: IPv4
    • Protocol: Any (if you really want to limit what can be sent to the internet, set this to TCP/UDP.)
    • Source: any
    • Destination: any (had issues with getting it to accept DHCP and DNS otherwise.)
    • Log: Checked. (Optional)
  • Once all three are added, Apply!
  • NOTE: Do ensure they’re in the given order as above, or seen in the screenshot below.

pfSense DNS and DHCP settings

DHCP Server/Service

Head to Services -> DHCP Server -> 0048_Guests to configure the DHCP server.

  1. Enable the DHCP server.
  2. BOOTP: Unchecked
  3. Deny Unknown: Unchecked.
  4. Ignore Denied: Unchecked
  5. Ignore Client Identifiers: Unchecked

Your Subnet, Subnet Mask, Available Range all should be populated with some acceptable values that your DHCP Pool can utilize.

Set the range: Front: 10.48.1.2 , To: 10.48.1.250

We don’t use Pools here, unless you need to specify additional segments of a range. In our case, we’re using a /24 (254 client-usable), so there isn’t much of a use or need in this regard.

Servers: Leave all six fields blank.

Other Options: All blank except for the following…

  • Domain Name: “guest.lan” (without the quotes). This can be anything you want, but easier to tag a basic domain to the guest clients rather letting them run amok with random domains.
  • Time format change: Checked.
  • Statistics Graphs: Checked.

Additional BOOTP/DHCP Options (COMPLETELY OPTIONAL!!)

This section can be left blank, unless you wish to tell mobile devices that your AP is metered (bandwidth limited (overall speed issues)). In which case, if you want to further limit devices (Primarily Android based) from eating bandwidth up, set the following…

  • Option:
    • Number: 43
    • Type: Text
    • Value: ANDROID_METERED

Save.

DNS Server (unbound)

Go to Services -> DNS Resolver -> “General Settings” Tab.

Network Interfaces: Hold CTRL down while selecting the 0048_Guests interface.

Save.

Go to the “Access Lists” tab.

Add the guest IP range to a new ACL for the Guest IP range. LAN is “Allow Snoop”, while guests is just “Allow”.

This is what my Access Lists looks like…

Once you’ve applied the DNS Resolver, it’s time for the final tests…

Connecting to your Guest WiFi Network

Load up your mobile device. Disconnect your device from your main network if it isn’t already. Connect to the Guest network.

Now, wait for the device to notice “hey, i’m in a walled garden!!”. At that point, it’ll ask you (the guest) to sign into the network. You’ll have a notification like this on Android…

Poke, Tap, smash, or whatever floats your boat that little popup to get into the UniFi guest portal.

Whatever you’ve customized your portal to be, the guest (you in this instance) will need to click the “Connect” button. As shown below…

After poking said button, the UniFi portal should remove you from the walled garden and let you browse the internet… at whatever snail speeds you’ve set.

At this point, if your mobile device does the following, you’re in good shape…

  1. Can connect to the guest WiFi Network SSID.
  2. Can obtain an IPv4 DHCP Address on the Guest Network VLAN.
  3. Device cannot communicate with anything outside of the /32 (its own IP address). (UniFi and pf Rules)
  4. Can connect and auth via the UniFi guest-auth portal.
  5. Able to connect to websites once authed/connected fully.

Ryobi Garage Door Camera and Blue Iris

For the “smart-home” person in me, having a remote garage door with addons was sort of a no-brainer. However, I saw that the Ryobi garage door opener (GD200/GD201 series) had an addon module for a security camera. The security camera model is known as GDM610.

At first, i was excited because well, another camera! But on second thought, the Ryobi Android store app is absolute trash when it comes to accessing the video feed. So that’s where blue Iris came in.

Setbacks & Other Issues

  • Currently, there is absolutely no way to “remote in” to this camera to manage it. It’s legitimately “what you get, is what you get.”
  • RSTP is supported on the default 554 port.
  • OnVif is on a really awkward port, 8001.
  • WiFi is to be desired for when it comes to signal quality vs stable video connection. A lot of skipped video or a hung-up connection requiring a reconnect.
  • Blue Iris v5 will throw a fit when searching for details of the camera due to the wonkyness of the settings.
  • Have not found a way to feed audio from the camera module to Blue Iris. (BI “see’s it”, but doesn’t know how to path it properly)
  • Camera has a seriously bad habit of throwing “Error 400, Bad Request” at Blue Iris. Not sure what triggers this, but seems to be relating to when the IR-cut kicks on and off.
  • On the final product, you can’t disable the extremely annoying date and time stamp at the top right.
    • Customer Support was clueless on it, and appeared to not even know this RTSP mode was event possible. They contacted the manufacturers of the camera, and got a response a week later stating that the time stamp was “baked into the firmware of the device” -ugh.

Assumptions

  • Blue Iris v4 or v5 is installed.
  • The Ryobi camera module has been configured and connected to your WiFi network.
  • The WiFi camera has been assigned a static IP address on your LAN.
  • You have blocked the camera from “phoning home” on the internet.
    • NOTE: This will effectively block the camera from being accessed/used on the useless Ryobi Garage Door app.
    • This camera LOVES to phone home to some IP addresses, two in the states, one to an AWS or Microsoft data center, and a fourth possibly to a server in china(figures, right?).
  • No SD Card is in the SD Card slot on the module.
    • If you don’t like a blue-flasher rave at night, put tape over the annoying led. Another options is to open the device up and remove the led power connectors to inside the module – this will obviously void your warranty.

Blue Iris

Adding the camera on Blue Iris is vastly straight forward. Just that, you may need to fiddle with the network settings of it on the BI camera panel afterwards.

So, add a new camera…

Next, the camera configuration panel. Know your Ryobi cameras’ IP address!! (Hence the need for the IP to be static)

Input the IP address in the first field. It should look something like this. Where 192.168.22.226 is the IP that you set on your side of the internet!

Click the “Find/Inspect” button on the top right of that dialog box.

You should see something like this show up under the “Inspecting…” UI box.

Opening 192.168.22.226 port 80...
HTTP Get / request...
Redirected to 192.168.22.226:8001
OK
ONVIF GetSystemDateAndTime
HTTP 12005
Opening 192.168.22.226 port 8999...
ONVIF GetSystemDateAndTime
HTTP 12029
Checking for common cameras...
Foscam FI86xx/98xx compatible?
Foscam FI89xx compatible?
Foscam FI9821 V2 compatible?
Foscam FI9821 media port compatible?
RTSP port open?
RTSP port detected!
Done

For the record, I’ve gone through every camera on the list under Make and Model. Nothing is recognized to an exact model with this camera except the Generic/onvif + RTSP make and model mode.

Your window should look something like this now…

Don’t Press OK just yet, because some of those values aren’t right.

  • Set the Discovery/ONVIF port to 8001.
  • Set “Receive Buffer” to 0.5.
  • Set “Camera” to 2.
    • Seems to force a more steady quality. Not sure why.
    • 0 and 1 were always pixelated or simply low, stuttery quality.
    • 0 1 and 2 are all valid options, all output the same bitrate – around 25 to 40 kBps.
  • Remove the forward slash / on the Video Path field.
  • Set Audio format to RTSP.
    • Granted, this does nothing currently.
  • Username and password seem to be happy at admin:admin.
    • I do not know if that is even asked-for or accepted at auth time!

Your configuration should now look something like this…

“New Camera”

The main gut of configuration to the RTSP Ryobi camera…

Video Tab

Go to the “Video” tab if you’re not there already.

Within the “Image Format” section, set the max rate to 15 FPS.

The camera seems to have severe issues pushing anything more than 15 FPS at any given time. The WiFi signal is excellent according to the UniFi control panel, sitting at a constant -45 dBm. TX/RX respectively is 65Mbps and 72Mbps.

As a matter of fact, the camera simply doesn’t do any more than 15 FPS!

Everything else for now can remain as is on the Video tab.

Watchdog Tab

Since the camera loves to be problematic for no reason whatsoever, we need to configure the watchdog panel. Set it up to be something like the following image. As always, adjust to how you need it to be.

Once set, press OK and let’s see if the camera is active. It takes a couple moments for the camera to show up on the Blue Iris application, but it should indeed work with the above config!

Common Oddities Observed & FAQ

#1: The camera randomly turns off the IR-leds and IR-cut at the dead of night.
Answer: The camera could be internally restarting, overheated internally somehow, or isn’t getting enough power.

#2: I’m getting No Signal a lot on Blue Iris.
Answer: Bluntly put: The camera is terrible. Even with an absolutely perfect signal over wifi, this happens… a lot. Hence the need for Watchdog to be active.

#3: I’m getting “400 Bad Request” errors.
Answer:
Don’t use paths (forward slashes) in audio or video path fields. Port 8001 seems to have a lot of wacky redirecting going on.

#4: The audio is making popping or snapping sounds!!
Answer:
Audio format under Camera Settings -> Video -> Network IP ‘Configure’ button, Audio section at the bottom, is not set to RTSP.

Better yet, just disable audio processing for this camera. Have not figured a way to make audio route over Blue Iris yet! Go to the Audio tab on the Camera settings UI, uncheck the “Enable Audio Channel”.

#5: What IP’s do i need to block on the firewall so that it can’t talk to the Internets?
Answer:
13.90.28.146, 13.90.27.154, 52.239.158.74

#6: Should i just block it from accessing anything outside the lan?
Answer:
If you don’t want to play whack-a-mole with IP nulling, then yes – block it from accessing the WWW, but permit it access to the router and the LAN.

Blue Iris & nginx reverse proxy

Blue Iris… for the uninitialized is a CCTV viewing, recording, nearly-do-everything-CCTV application for analog, IP/digital, and usb based cameras. It sports a trendy web UI for viewing of the cameras added to the Blue Iris application. In this blog, will lay out the process to ensure nginx and BI plays (mostly) nice with Blue Iris web server.

This article assumes the following…

  • You have a wildcard based SSL certificate created and in-use/active for the reverse proxy access domain name.
  • You are configuring this as a sub-domain (e.g.; SomeSubDomain.potatoforinter.net) and not as a file path (e.g.; potatoforinter.net/blueiris/) to a domain.
  • You’re running Blue Iris version 5 or newer.
  • nginx is running 1.17.x or newer.
  • nginx will internally route (user doesn’t see this happen!) the HTTPS request (be it lan or wan) to a HTTP request within the lan to the Blue Iris server.
  • The Blue Iris install does not use stunnel.

On Blue Iris’s application, we need to ensure the server accepts some variables from nginx along with setting a logical configuration. Otherwise, we run into some “fun” issues later on with security and general access problems.


Go to the Blue Iris settings panel.

Click the “Web Server” tab.

Ensure your options look something similar to the above image. You will need to input the machines LAN IPv4 address into the “Local, internal access” input.

“Virtual” has to be just a forward slash /. This is a subdomain, not a folder we’ll be configuring.

Your “Remote, External access” needs to equal the IP address of your WAN IPv4 address. If your WAN IP was to be 12.34.56.78, you would input that to the Remote input field.

Ensure stunnel is unchecked. nginx will be handling all of the HTTPS/encryption from the net to the Blue Iris web server – mostly.


Click the “Advanced…” button at the bottom of the Web Server tab.

The Advanced UI should popup. With this setup, it’s a fairly generic configuration with the exception of “Use X-Forwarded-For Headers” being checked. I’m pedantic, and I like to have everything logged in the event someone gains access to it when they shouldn’t.

Let’s get crackin’ with the reverse proxy now. For the reverse proxy, am using nginx 1.17.x series.

Again, please note the following, as this article assumes the following…

  1. This installation uses SSL via Let’s encrypt. You’re using a wildcard based subdomain (*.some-domain.tld rather some-domain.tld).
  2. Access will be via a subdomain to a domain (blueiris.potatoforinter.net, not potatoforinter.net/blueiris)
  3. BIND or your DNS provider has been configured a proper A record for the domain.
    • NOTE: If using bind, and plan to throw “all the things” at the nginx reverse proxy, use a wildcard A name in addition to the non-WWW based domain.
    • It will look like this in the A field: *.potatoforinter.net. rather www.potatoforinter.net or/and potatoforinter.net. Ensure a proper A record exists for the primary/root domain however.
  4. Knowledge of how nginx includes/variables function.

Config Files for nginx

The virtual host file: /etc/nginx/sites-available/blueiris.conf

server {
        listen 443 ssl http2;
        server_name blueiris.potatoforinter.net blueiris.home.lan;
        include /etc/nginx/ssl.conf;
        set $upstream 192.168.20.2;
        location / {
                include /etc/nginx/reverse.conf;
                proxy_pass http://$upstream;
        }
}

NOTE: Edit server_name to suit your needs on the domains. I have two active. One for the lan resolver, and one for the web DNS.
NOTE: Modify set $upstream‘s IP address to the address that your blue iris installation resides on. If the web port isn’t port 80, append :1234 where 1234 is the port number that blue iris is listening for connections on. It might be 8080, it might just be 8000! It’s whatever you’ve set.

The ssl.conf file…

        ssl on;
        ssl_certificate /etc/letsencrypt/live/potatoforinter.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/potatoforinter.net/privkey.pem;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_session_cache shared:le_nginx_SSL:1m;
        ssl_ecdh_curve secp384r1;
        ssl_dhparam /etc/nginx/ssl/dhparam.pem;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
        ssl_session_timeout 10m;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;
        resolver 192.168.20.1 192.168.20.1 valid=300s;
        resolver_timeout 5s;
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
        add_header Referrer-Policy no-referrer;
        add_header X-Content-Type-Options nosniff;
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-XSS-Protection "1; mode=block";
        add_header X-Robots-Tag none;
        add_header X-Download-Options noopen;
        add_header X-Permitted-Cross-Domain-Policies none;
        add_header X-Download-Options noopen;

NOTE: You will need to modify the resolver IP’s to your local DNS or an internet DNS provider (Level3 DNS, Cloudflare DNS, OpenDNS, Google DNS, etc).
NOTE: You will need to modify ssl_certificate and ssl_certificate_key for your lets encrypt needs.

The reverse.conf file…

    proxy_http_version 1.1;
    proxy_temp_file_write_size 64k;
    proxy_buffer_size 64k;
    proxy_buffers 16 32k;
    proxy_busy_buffers_size 64k;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Host $remote_addr;
    proxy_read_timeout 300;
    proxy_connect_timeout 300;
    proxy_request_buffering off;
    proxy_buffering off;
    proxy_redirect off;

This file is more or less a jumbled addition of proxy variables set over time. I’ve not validated the impact of each setting above when it comes to Blue Iris.

Save those files to the following directories…

  • /etc/nginx/sites-available/blueiris.conf
  • /etc/nginx/ssl.conf
  • /etc/nginx/reverse.conf

Link the blueiris.conf to the sites-enabled folder.

  1. cd /etc/nginx/sites-enabled
  2. ln -s /etc/nginx/sites-available/blueiris.conf blueiris.conf

Now, restart nginx, service nginx restart. Or reload, or whatever command you deem worthy of your fingertips to restart or reload nginx.

If the reload, or restart didn’t throw errors back at you, try accessing the blue iris installation; for example: https://blueiris.potatoforinter.net/ (non-functioning URL)

Forcing Spotify to use a network drive

Spotify Support said this could not be done for “legal reasons” and promptly shut the door on my support ticket a year or two ago as of this writing. They seemed to think I was trying to use the network drive as a share or CDN “to other users”. Which well, still isn’t the case!

With that being said, Spotify on desktop uses a TON of storage for well… the storage of songs that you’ve set as “Download” on various playlists. And even more-so now due to one of their late 2018 or early 2019 update. As of this writing, my Spotify network share sits just under 100GB!

If you’re like me, and have limited space on your desktop machine due to the drives being SSD’s of 1TB or much less, you’re in luck today.

I’ve only tested and executed this on Windows 10 Pro, version 1803 – so as always, YMMV.

Some prerequisites to have done…

  1. Close the Spotify app in full.
    • If you have to, use task manager and close/end anything that says spotify in the process list.
  2. Able to run a command prompt as admin.
    • You should be able to accomplish this by right clicking the start icon (windows icon), click “Command Prompt (Admin)”.
  3. Ensure your network share is active, accessible, and writable.
    • For me, I am using Debian 9 with SAMBA – this is on a virtual machine provisioned for 256GB in a flat file / single virtual machine disk.
    • I’ve included a short config below for the Samba configuration.
  4. Know what IP address that your samba or remote machine’s share resides on.
    • Windows doesn’t do too well with server-shares as a name vs an IP.
  5. Do not delete the current cache folder that resides in your appdata folder – you’ll be moving the content of the Spotify cache folder!

Getting the ball rolling with Samba…

  1. If you don’t have Samba installed, run sudo apt-get install -y samba samba-common
  2. Once installed, create a new user on the host *nix system. In our case, for simplicity, spotify.
  3. Said user will need to be in the same user-group as Samba on the host system, which would likely be sambashare.
  4. Our command (assuming sudo su -) will likely be something like this: useradd -d /srv/spotify/ -m -G sambashare -p spotify spotify
  5. The password is intentionally “spotify”. No need for it to be something too special, as all it is hosting are cache files from spotify – and nothing else.

Samba config file (smb.conf)

Go ahead and get your samba share configured. For me, this is what my Samba share details looks like… Do note that max disk size can be removed from the config below, i intentionally set this on my installation.

[global]
        server role = standalone server
        dns proxy = no
        map to guest = bad user
        passdb backend = tdbsam
        syslog = 1
        workgroup = WORKGROUP
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        obey pam restrictions = yes
        os level = 20
        pam password change = yes
        server string = Spotify Cache Server
        usershare allow guests = yes
        log file = /var/log/samba/log.%m
        max log size = 1000
        unix password sync = yes
        passwd program = /usr/bin/passwd %u
        max disk size = 104857600
        panic action = /usr/share/samba/panic-action %d

[homes]
   comment = Home Directories
   browseable = no
   read only = yes
   create mask = 0700
   directory mask = 0700
   valid users = %S

[spotify]
        path = /srv/spotify/
        force group = spotify
        writeable = yes
        readonly = no
        guest account = spotify
        force user = spotify
        comment = Spotify Cache

Off to the Windows side of things…

At this point, we intentionally do not map a network drive.

  • Get a command prompt active with Admin / Administrator permissions open.
    • Right click the Windows Start Icon (OR Windows Key + X) and click command prompt (Admin).
  • As long as you know the IP address of the Samba share (virtual) machine, you can type in this to the command prompt to ensure the share is active: net view \\IP.IP.IP.IP /all
    • Where IP.IP.IP.IP is the actual samba share host.
  • You should see something like this…
C:\WINDOWS\system32>net view \\192.168.20.207 /all
Shared resources at \\192.168.20.207

Spotify Cache Server

Share name  Type  Used as  Comment

---------------------------------------------------------------------------
IPC$        IPC            IPC Service (Spotify Cache Server)
spotify     Disk           Spotify Cache
The command completed successfully.
  • Outside of the command prompt, navigate to the folder where your Spotify Cache is stored at. Spotify will always default it to: C:\Users\YourUserName\AppData\Local\Spotify in a folder named Storage.
  • Enter into the Storage folder.
  • Select ALL files and folders within the Storage folder, CUT the files and folders, not COPY. (Hint: CTRL A then CTRL X)
  • Now, open up a new (second) explorer window, and navigate to where you have the samba share at.
    • You’ll need to enter the location in manually in the input bar at the top. For me, it is \\192.168.20.207\spotify.
  • When you navigate to this share for the first time, it should ask for a username and password.
    • If you setup via the process above, the username and password is simply spotify (Username might require the workgroup\domain flow, use WORKGROUP\spotify if so).
    • Be sure to check the Remember check box before clicking OK.
  • If the login and access was a success, you should be in the samba share folder. Try creating a folder, title it test or something. If you created the folder without issue, go ahead and delete the test folder.
    • Keep this window open for the next step!
  • Remember all of those folders that you cut above? Yeah, paste them into the new network share now. Get them out of the “Storage” folder currently residing on your C drive.
    • Depending on your LAN ethernet speed and the size of your Spotify cache “Storage” folder, this could take anywhere between one minute to one hour.
    • Wait for this massive process to finish before continuing onward.
  • Once the mass move of folders has completed, go up one level – or to C:\Users\YourUserNameHere\AppData\Local\Spotify
  • Delete the current “Storage” folder. It gets recreated with the next steps below.
  • Jump back to the command prompt from earlier. We’ll use the net use command to create a persistent mapping to the remote share. This also _SHOULD_ create a user:pass mapping to the share, but in the event it didn’t, the above step should have.
    • net use \\IP.IP.IP.IP\spotify spotify /USER:WORKGROUP\spotify /PERSISTENT:YES
      • \ShareIP\ShareName,
      • Password,
      • User plus workgroup details,
      • Forcing it to be persistent.
  • NOTE: If you use something like CCleaner, or something that removes old-caches and stored data, it may wipe your user:pass login credentials! If this happens, Spotify will throw an error stating that the “drive might be full” due to an forbidden access-event.
  • Edit the username & paste into the terminal: mklink /d "C:\Users\YourUserNameHere\AppData\Local\Spotify\Storage" \\IP.IP.IP.IP\spotify
  • Once this mapping and folder ‘link’ has been made, check the C:\Users\YourUserNameHere\AppData\Local\Spotify directory for a folder named “Storage” with the little arrow at the bottom left. Your folder list should ultimately look like this:
  • Enter into the “Storage” folder and ensure you can access, view, and browse about.

Load up Spotify, and see if it loads in the entire cached library. If there’s an error, you’ll see it light up at the top of the Spotify UI.

All in all, this is a fairly simple process. Just have to have some know-how when it comes to Linux, Samba, Windows, and basic TCP/IP networking knowledge.


Notes / Q&A

Q: Spotify says it doesn’t have permission “maybe disk is full”-error…
A: There are four possible issues ongoing:
1) You’re no longer logged into the network share on Windows. Manually navigate via explorer to the root share IP so that it triggers a login-request.
2) The Samba file system or *nix file system is read only – or possibly not even running!
3) A firewall is blocking it – be it on linux (ipfw or iptables) or on Windows.
4) The machine you’ve linked to is at its quota or actually has a full hard drive!

Q: Spotify is extremely slow to load / start up now…
A: This is to be expected when forcing the cache to use the TCP/IP stack and not a direct local-drive access. It will be even slower if your switch or ethernet ports are not 1Gbps. It takes upwards of 45 seconds to one minute for Spotify to load up the entire (near) 100GB cache I have on the Samba drive. This is what it looks like on windows task manager…

When Spotify needs to download new audio, your task manager will look something like this…

This is working as intended. Spotify will download the song, once completed, uploads it to the network share that has been linked from the process above.