Updated 10/24/2018 since routing didn’t work anymore. You have to disable source-validation, thanks to Roelf for the comment with the correct command.
For some time now I wanted to be able to test some network stuff. I want to be able to connect certain devices over a VPN to the Netherlands but without the need to configure every client with VPN connections.
With this scenario it is possible to test different geo stuff accessing my network from different places in the world, it also helps me test the different latencies when going across the ocean and back. It also could be used to access certain video services in another country or access a different Netflix catalog, but I would never use it for something like that obviously
After reading up on the different forums and asking some questions I was able to configure my USG in a way which gives me the most flexibility possible for my scenario. This is the step by step guide how to configure your USG and network so all your network on that special network will be routed over the VPN connection to the Netherlands.
The first step is to configure my ‘hoekstraonline NL’ network as described in this blogpost. Connecting through my ‘hoekstraonline NL’ wireless network and specific ports on my router (tagged with the same VLAN 100) will be the basis of my configuration. I want all that network going over the VPN connection to NL. All me regular traffic will go over my Comcast connection as usual but machines connected to that wireless network and specific ports on my routers will be routed over the VPN connection.
So lets create the VPN Client network first. Nowadays this can be done through the UI (I am running Unify version 5.6.20 stable candidate when I am writing this)
After you create this network you can check on your USG how the routing table looks like. It should have added the VPN NL network. Enter the following command on your USG (via SSH):
ubnt@USG:~$ netstat -r
My routing table looks like this:
the pptpc0 interface is the VPN connection I just defined, you can see from the flags the connection is up (U). The eth1.100 is the virtual network which was added in the previous blogpost.
The next step is to change the routing depending on the source address. Unfortunately this can’t be done through the GUI from Unifi. They add more and more functionality every month, but this has to be done through the command line. so fire up your bash shell or putty and connect to your firewall (USG in my case).
In the shell type; configure
We have to define a new routing table we call table 1 which will route traffic to my VPN connection on the 10.0.0.0/24 network.
ubnt@USG# set protocols static table 1 route 0.0.0.0/0 next-hop 10.0.0.1
Now we have to define the modify policy. A modify policy allows us to modify various items when the rule matches. So if the source address came from 192.168.2.0, then we want to use routing table 1:
ubnt@RTR# set firewall modify SOURCE_ROUTE rule 10 description ‘traffic from eth1.100 to VPN NL’
ubnt@RTR# set firewall modify SOURCE_ROUTE rule 10 source address 192.168.2.0/24
ubnt@RTR# set firewall modify SOURCE_ROUTE rule 10 modify table 1
Now we need to apply this policy to the interface. When it comes to applying a policy to an interface, it needs to be done on the input interface before the routing lookup takes place.
ubnt@USG# set interfaces ethernet eth1 vif 100 firewall in modify SOURCE_ROUTE
A last step which you need to add (this changed so this step was added 10/24/2018) is to disable source validation (thanks to Roelf for the comment and help)
ubnt@USG# set firewall source-validation disable
After this you can give the commit and save command and you can test your network routing. From a client in the 192.168.1.x range nothing should be different. But when you test it from a 192.168.2.x client you see the traceroute change to the 10.0.0.1 hop and than off to the Netherlands.
The first tracert is from a machine in the 192.168.1.x range. You see the first hop is my USG gateway and than it goes out to the internet.
The second tracert is from the machine when it’s in the 192.168.2.x range. You see the second hop goes through the 10.0.0.0 VPN gateway and you also see the response times go up since it’s traveling the ocean now.
The last step is to add these settings to the provisioning script stored on my cloudkey, so when I reset the USG the settings won’t be lost.
One of the sources I used to write this article.