By Russell Brown

About a year ago, I decided to set up a unity asset cache at home, for use when I was working there.

It turned out to be a good decision, and I continue to use it to this day.

Chug chug chug...

Chug chug chug…

Setting up the asset cache is not the subject of this article, however. You can read about that in Unity’s documentation.

This article concerns solving a problem I encountered when trying to get the transition from office to home working smoothly with my new asset cache server.

The problem is that you configure the asset cache server in Unity to a specific IP address:


Chances are, the IP address of the server your cache is running on in the office won’t be the same as the IP address of the server you’re using at home. If they are the same, great! You don’t have this problem.

Furthermore, your local network at home may not even be using the same subnet. If you are, this problem is a little easier to solve. This article assumes you’re not using the same subnet.

Let’s say that at the office, your cache server is on, while at home the server is on

There are probably a number of different ways to solve this problem. The most obvious is this:


Just change the setting when you go home, and change it back when you’re back in the office! What could be more simple? Yeah, but I’m a programmer, and I don’t like repeating myself when I could automate a task with a little effort up front.

What I want is to be able to switch between the office and home, and for it to “Just Work” without any effort from me.

The solution I went with was to add a virtual IP address on my server, and a route on my router to forward requests on the other subnet to my server.

Here’s where we’re starting from:


My laptop knows that it should go to the router for everything, so it sends the request intended for to the router. But the router doesn’t have any route for that address, so it just fails.

We need to add a static route on the router so it knows where to send this request. Now, all routers are different, but here is an example from an ASUS router (LAN -> Route):


We’re telling the router that requests for addresses that start with 192.168.5 should be sent to (it is assumed at this point that the server’s IP address is static: if it isn’t, this isn’t going to work reliably).

So is that it? Well, not quite. Now we have this situation:


The request is now being sent to the correct server, but the server rejects the request because the IP doesn’t know what to do with it. That is to say, it knows it’s not for itself, and it doesn’t have anywhere further to which it should be routed.

So, we need to configure the server to accept requests to

This is where this article becomes very platform-specific. My server runs Linux (Ubuntu 16.10, specifically). If your server is another OS (e.g. Windows or OSX), the steps are going to be different, but the outcome should be the same.

The trick here is to add a virtual interface on the machine’s existing physical interface. This is done in /etc/network/interfaces

The first step is to identify the primary physical interface (if you have multiple, you need the one that will be receiving requests from the router). For example:

# The primary network interface
auto br0
iface br0 inet static

Note the name of the interface (in this case, br0). Yours may be something different, such as eth0.

Now, add a section beneath that which defines the virtual interface (using the same base name as the primary interface):

# Virtual interface pretending to be the office
auto br0:0
iface br0:0 inet static

This creates a virtual interface for the address that we need, leading to this happy situation:


I had to reboot my server in order for this to work, but once I did, I was able to connect to my Unity Cache Server at home via the same IP address as the office server without having to reconfigure Unity.