How I optimize all 19 nodes with a VPN server

So, I’ve been working on a way to improve network latency and make better use of the local network while still keeping a fixed IP for the VPN server. It might sound a bit fancy, but it’s really just a practical solution.

Before we dive in, I assume you already have a VPN setup in place. If not, you can refer to this article: Don’t Have a Fixed IP at Home for Running a Node? A Step-by-Step Guide to Get It with a VPS

The idea here is something called “VPN — Split Tunnel,” which, as the name suggests, splits our network into two parts:

• VPN Side: This part handles communication with the VPN, specifically for things that need a fixed IP, like node 0g RPC requests.
• Local Network Side: This side is where all the usual download and upload activities happen, like syncing blocks for the nodes.

The reason I set it up this way is pretty simple: my VPN server is a bit underpowered with just 1 vCPU and 1 GB of RAM. It could manage a few clients, but if all 19 nodes were connected, it would probably become a single point of failure. Plus, by doing it this way, I can reduce the latency for syncing the nodes, which is a nice bonus.

Let’s jump into the setup. There are two parts: configuring the VPN server and the VPN client. The VPN client setup is very easy — just a few clicks in the Ubuntu Network Manager UI, and you’re done. Most of the configuration work will be on the server side.

VPN Server Setup

I SSH to my vpn server and start the setup. The idea behind this is we have to apply Policy-Based Routing (PBR) which we can setup difference routing part for difference traffic.

Imagine you’re setting up a VPN on your Linux server, and you want to make sure that specific traffic, like from a certain application or IP address, always goes through the VPN connection. To do this, you’ll be using Policy-Based Routing (PBR), which lets you define custom routing rules that go beyond the basic routing table.

1. Edit the “/etc/iproute2/rt_tables” File

First, we need to set up a new routing table dedicated to handling traffic through the VPN. Think of this table as a special set of instructions that tell your server, “Hey, if the traffic matches certain criteria, use this route!”

Open the file with nano

sudo nano /etc/iproute2/rt_tables

inside nano, add:

200     vpn

• 200 is the sequence of the routing. OS will excute low number squence first.
• “vpn” is the additional routign table we will add in later ahse.

So, we added a new entry in a file called /etc/iproute2/rt_tables, which is like a directory of all your custom routing tables. The table will be used later in next step.

2. Add routes to custom VPN Table

There are 2 routing rules that we will add to VPN table.

• First rule: The first command sets the default route for the vpn table. This means that any traffic that doesn't match a more specific route in the vpn table will be sent through the gateway at 10.8.0.1 via the tun0 interface.

sudo ip route add default via 10.8.0.1 dev tun0 table vpn

• Second rule: The second command specifies that any traffic destined for an IP address within the 10.8.0.0/24 subnet (which includes all IPs from 10.8.0.0 to 10.8.0.255) should also be routed through the tun0 interface. This ensures that communication within this IP range happens through the VPN.

sudo ip route add 10.8.0.0/24 dev tun0 table vpn

3. Add Policy Routing Rules

Now that you’ve set up the custom vpn table and added the necessary routes, the next step is to create policy routing rules. These rules will determine when to use the vpn table based on specific criteria, such as the source IP address of the traffic.

What we want to achieve here is to create a Policy Routing Rule that directs traffic based on the source IP address.

In this step, you’re setting up a rule that tells your system: “Whenever traffic originates from a specific IP address, route it using the vpn table."

Here’s the command to do that:

sudo ip rule add from 10.8.0.12/32 table vpn

You’re telling the system, “If any traffic comes from the IP address 10.8.0.12, make sure to use the vpn table to determine how it should be routed."

What If You Have Another VPN Client?

If you have another VPN client with a different IP address, such as 10.8.0.13, and you want its traffic to be routed through the VPN as well, you’ll need to add a similar rule for that IP address:

sudo ip rule add from 10.8.0.13/32 table vpn

This additional rule will ensure that any traffic originating from the IP address 10.8.0.13 will also follow the routing rules defined in the vpn table. Essentially, for every VPN client you want to include in this routing policy, you’ll need to add a separate rule specifying that client's IP address. This way, all designated clients' traffic will be securely routed through the VPN.

Why do we need this rules? The answer is to prevent Asymmetric Routing.

Asymmetric routing occurs when packets travel out through one path but return through a different, unintended path. In the context of our VPN setup, imagine you’re forwarding traffic from the outside world to a service running on your VPN client. If the incoming traffic arrives via the VPN tunnel (due to port forwarding), but the returning traffic (like ACKs) tries to go back out through the regular internet connection instead of the VPN, you have an asymmetric routing issue.

This can cause problems because the response packets are not following the same path as the incoming packets, leading to dropped connections, security risks, and unreliable communication. To prevent this, we create a Policy Routing Rule that ensures all traffic, both incoming and outgoing, consistently follows the same VPN path, maintaining a stable and secure connection.

VPN Client Config (for Ubuntu)

If you’re using Ubuntu’s Network Manager (the default option when installed) to manage your VPN connection, enabling split tunneling is straightforward but involves a few specific steps. Here’s how you can configure it:

1. Open Network Manager
2. Edit your VPN Connection
3. Navigate to IPv4
4. Uncheck “Use this connection only for resources on its network”
5. Apply

Step 4 is crucial. By unchecking this box, you allow the VPN to route only the traffic that matches the routes you define (which, in our case, are provisioned from the server), while other traffic can bypass the VPN and go directly to the internet.

VPN Client Config (Windows OS)

If you’re using Windows OS, you can easily add one line in your client configuration file profile. Just refer to step 1.2 in the article ”Don’t Have a Fixed IP at Home for Running a Node? A Step-by-Step Guide to Get It with a VPS” , which guides you on creating the OpenVPN client profile. You can simply add the line shown below:

... 
route-nopull 
...

Yes, just add that simple keyword to your `.ovpn` client file to enable tunnel splitting. It’s as simple as that!

Summary

After configuring the /etc/iproute2/rt_tables file and setting up the custom routing table, the system is now ready to use policy-based routing. This setup ensures that traffic originating from the VPN client with the IP 10.8.0.12 is correctly routed back through the VPN, while all other traffic continues to use your local network.

That’s all for today — thank you for reading!