2018 – miqrogroove

OpenVPN tls-auth Option is Critical

Someone attempted a very noisy attack against my router’s built-in OpenVPN server today. While there was no chance this person could guess my encryption parameters to gain access, he or she did manage to cause a denial of service.

The log excerpt looks like a whole lot of these:

Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:22475 TLS: Initial packet from [AF_INET]148.163.126.72:22475 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:57036 TLS: Initial packet from [AF_INET]148.163.126.72:57036 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS handshake failed
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS handshake failed
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:55183 TLS: Initial packet from [AF_INET]148.163.126.72:55183 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:12142 TLS: Initial packet from [AF_INET]148.163.126.72:12142 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS handshake failed
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 SIGUSR1[soft,tls-error] received, client-instance restarting

Continue reading OpenVPN tls-auth Option is Critical

How to Filter Xfinity Script Injections

Is your Xfinity ISP injecting horrible scripts and dialog messages into every unencrypted website that you visit? It might look like this:

We’ve increased Internet speeds in your area.

Update your modem to start enjoying them.

We’ve noticed you have an older modem that can’t keep up with faster Internet speeds now available in your area.

To start enjoying faster Internet, you can:

Buy from a retailer

Before you make your purchase, visit mydeviceinfo.xfinity.com to view a list of modems certified on our network.

Lease an XFINITY Gateway (Comcast lease fees would apply)

Call 1–855–242–2876 to order a Wireless Gateway and we will send you everything you need to get set up.

Thank you for choosing XFINITY. Ensuring that you get the most from your Internet service is part of our commitment to improving your overall experience.

In the Chrome web browser, you can block this with the ComcastBlocker extension. The Xfinity script still loads, but its effects are minimized by removing all the display elements.

Solving Disconnected Folders Over Wi-Fi

Avoid the First Default Setting for Share Caching

I’m starting to realize that the Offline Files feature in Windows causes more problems than it solves when it comes to unreliable network connections.

In 2016, I described how to minimize the effects of an occasionally high ping when the slow-link mode goes into effect: Offline Files Stay Disconnected

But that doesn’t solve the problem. Fine-tuning or even disabling the slow-link mode forces the Client Side Cache (CSC) to use its “Action on server disconnect” configuration any time the network isn’t performing perfectly. The default behavior, “Work offline”, treats each affected (meaning cache-enabled) share as being totally unavailable and then the CSC attempts to retrieve cached copies. This happens even if the server is still available but failed a single ping check.

Why is this still a problem? Well, in practice, most files don’t need to be available offline. By default, the Windows file server is configured, and the Windows client is designed to allow each user to select individual files as “Always available offline” from the file context menu. When a user selects this option, that one file is copied to the CSC, and in theory that one file is always available. This allows for targeted use and minimal sync time. The problem arises with all the other files. When the CSC goes offline and marks the shared folder as disconnected, it effectively blocks access to all the files that were never cached, even if the server and its files are still available.

At this point, you and I now understand the situation that needs to be avoided. We don’t want to have a large number of files under the unnecessary clutches of the CSC, regardless of network quality.

Update 08/17/2018

At first, I thought the solution was to change the file server’s default configuration of allowing users to decide which files are cached. I changed folders that needed maximum online availability to be set to “No files or programs from the shared folder are available offline.” This server setting automatically disables the CSC.

Unfortunately, the result was that the folders configured for offline caching worked great, but the folders configured for no offline caching only worked until some network error or server reboot. In this configuration, once a path became disconnected, an Offline Files message is logged in the Event Viewer, and even though no files are being cached the entire path becomes unavailable. At that point, the workstation persistently throws Error 0x80070035 any time that particular path is accessed, until the workstation is rebooted.

The only solution I’ve found that works now is to completely disable the Offline Files feature on the workstation. With Offline Files disabled from the Control Panel, the network and server errors are now transient and I am not having any problems with disconnected paths or persistent errors.

Offline Files is ultimately broken and does not improve the Windows experience.

Windows 2012 Can’t Ping NVR Host

I just resolved a long-term problem where one specific Windows 2012 server was unable to ping one specific device on the same LAN.

There were no relevant resources or similar-looking cases on the web. Everything else on this LAN worked normally. The server could ping all other clients, and the clients could ping the server and the NVR. I just could not get the server to ping the NVR for the life of me.

I suspected at one point that this was a routing issue due to my desire for strong security policies around IOT devices. This turned out not to be the case as I could find nothing wrong with the router or any routing tables.

At last, I decided this problem was so specific that it could be a bug in the NVR itself. In this case, the only thing special about the Windows server from the NVR’s perspective was that the server was providing both DHCP and DNS to the NVR. I tried disabling each service, and found exactly what I was looking for.

The NVR will not respond to pings from its DNS server.

I don’t know why this is broken and don’t really care to investigate any further. The workarounds are either:

Create a DHCP reservation with its own option to specify a 3rd-party DNS server, OR
Disable the NVR’s DHCP client and set a static address with an alternative DNS server address value.

In my case, the NVR does not need to use the local DNS server, so this is an easy fix. So long as my server’s IP address is not used in the NVR DNS configuration, everything works normally and the server can ping the NVR.

High Resource Use by Start Screen

While diagnosing what I thought was a Windows Update failure, I discovered unrelated massive resource consumption and file scanning activity apparently tied to the Start screen in Windows 2012.

Symptoms:

10 to 20% constant CPU usage by Windows Explorer.

Rapid file scanning or Shared Folder usage in the case of folder redirection.

Triggers:

Resource consumption begins immediately after opening the Start screen and performing a keyboard search.

Closing the Start screen does not help.

Workarounds:

Sign out the current user. This action will shut down Windows Explorer, preventing the unwanted symptoms until triggered again by a user.