There are several issues that frequently crop up when deploying lancache. Here is the information on how to handle them if they happen to you.
Disabling systemd-resolved DNSStubListener
If your cache host is running a recent Linux distribution, it is likely running
systemd-resolved, which listens on port
53. If you want your cache host to bind to
0.0.0.0:53 (INADDR_ANY, all IPv4 addresses), you will first need to disable
systemd-resolved’s stub listener.
sudo -e /etc/systemd/resolved.confand change the line starting with
DNSStubListener=no- removing the
sudo rm /etc/resolv.conf
sudo ln -s /var/run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo service systemd-resolved restart
- Check that you can still resolve DNS on the cache server by running
nslookupfor a domain of your choice (e.g.
Unraid Port Bindings
Unraid provides network storage, virtual machines and docker functionality and on the face of it seems a great platform for running up your lancache. However people often run into problems with ports. To use lancache you need to have unchallenged access to:
- Port 80: where HTTP content is requested.
- Port 443: so that HTTPS is handled.
- Port 53: so that DNS requests can be directed.
These are usually in heavy rotation by the unraid UI. While some users have managed to add another IP and move some services arround there is an easier way. Simply run up an unbuntu VM on unraid. You can assign an uncontested IP to your VM with ease and now you are on the “happy path” for install. Use the Separation of Concerns principle and put your caching all inside one easy to operate wrapped up VM of its own.
Slow Download Speeds
Its quite common to see different or odd behaviour at the download client with a lancache in your network. Sometimes this is as simple as the way the client does the maths on showing your current speed. An example would be:
- Client requests 20MB file.
- Lancache intercepts the request and makes the same request from the internet
- The client is now waiting and getting no data as the cache fetches the file. Speed is zero at the client.
- Lancache finishes downloading and informs the client.
- Client downloads 20MB over a 10Gbit nic to an M2 harddrive at speeds the 1990s wouldn’t even dare dream of and gets the file almost instantly. The average speed in the client blips upto 100Kbps and returns to zero.
It worth remembering that your cache is aiming to provide for many people and that using one client to assess speed can be misleading. That said there are some games that have odd behaviour that can be improved. Some CDNs use back off mechanics that don’t play well with the slicing module in nginx. Others have “interesting” behavior with range requests. For the most part we have found the standard behaviour to be satifactory but if you want to try and tune it, try out the advanced section.
Lancache, and in particular lancache-dns, is not currently enabled for IPv6. Therefore we recommend checking your LAN Party network and ensuring that if you are providing or allowing IPv6 DNS servers, that clients are not able to get the external v6 address for the major CDNs. If they do get a “none poisoned” IP via IPv6 then they will go direct to the internet for the files and bypass the cache totally.
Future support for IPv6 is being investigated but is at an early stage.
Non-RFC1918 IP Ranges
Several of the most popular game clients/launchers, including Steam Origin and Riot, only work properly if they detect the cache is on an RFC1918 private IP address (i.e 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16).
The clients have built in logic that will ONLY enable their built in TLS downgrade / HTTP fallback modes if the hostnames they are connecting to resolve to an RFC1918 private address. If the hostnames resolve to a public IP range (even if that range sits on your local network) the client will use encryption and thus lancache will not be able to cache the traffic.
As this is built in logic from the games companies, there is no work around for this situation. However even if your local network is setup to give client machines a public ip address, you can still setup lancache on a private IP and configure your router to perform the appropriate routing or NAT locally - it is only the hostnames pointing to the lancache itself that must resolve to a private IP and it does not matter what IP space the clients use.
The exact reason for this logic is known only to the game companies in question, but it is likely a failsafe measure to ensure that they are only downgrading to unencrypted communication when they can be 100% sure they are talking to a local cache and not sending unencrypted traffic over the internet to a public ip that could be anywhere.