VyOS and Torguard – part 2

If you are looking for traffic engineering your traffic into Torguard’s WireGuard server, I hope this post will be some kind of help or at least help point you to what you are looking for. What we have done from the previous post, we have enabled WireGuard and configured VyOS WireGuard to establish a secure tunnel from our VyOS router/firewall to Torguard WireGuard.

The firewall rules examples shown in this post are the zone-based firewall instead of the typical interface firewalling. I use zone-based because it is easier to manage and I use zone base firewalls at my day-to-day job.

I am going to use my test Emby server as a guinea pig. The scenario is route normally locally, but for Internet access, route via Torguard. The traceroute below shows the paths.

# Local routing
root@emby:~# traceroute 10.0.20.10
traceroute to 10.0.20.10 (10.0.20.10), 30 hops max, 60 byte packets
 1  10.0.7.1 (10.0.7.1)  0.236 ms  0.599 ms  0.585 ms
 2  10.0.20.10 (10.0.20.10)  1.167 ms  0.993 ms *
root@emby:~#

# Internet access
root@emby:~# traceroute -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.0.7.1  0.220 ms  0.266 ms  0.284 ms
 2  96.120.104.209  13.351 ms  13.339 ms  13.344 ms
 3  68.87.139.9  13.088 ms  13.297 ms  13.709 ms
 4  68.86.205.173  22.035 ms  22.025 ms  22.003 ms
 5  96.110.40.29  18.495 ms  23.169 ms 96.110.40.25  23.737 ms
 6  96.110.37.134  17.027 ms 96.110.37.142  17.624 ms 96.110.37.134  17.558 ms
 7  173.167.57.102  17.534 ms  15.219 ms  14.944 ms
 8  1.1.1.1  14.674 ms  14.451 ms  14.652 ms
root@emby:~# 

To complete to our objectives in our scenario, we need to implement are the following:

• Source NAT
• Firewall policy
• Policy-based routing

Let’s create a source NAT. Since Torguard only provided a single 10.29.0.x IP address for our WireGuard interface, we need to masquerade our internal IP address(es) to tunnel through the WireGuard tunnel.

set nat source rule 1500 description 'torguard source nat'
set nat source rule 1500 outbound-interface 'wg1000'
set nat source rule 1500 source address '10.0.0.0/14'
set nat source rule 1500 translation address 'masquerade'

Since the zone-based statefull firewall is enabled, we need to create firewall rules to allow traffic from one zone to torguard zone. We need to create firewall rules then create a zone for Torguard and add the WireGuard interface wg1000 that was created previously to the Torguard zone.

# Create a firewall rules
set firewall name all_to_torguard default-action 'drop'
set firewall name all_to_torguard rule 100 action 'accept'

# Create zone and add the firewall rules and wg1000 interface to the zone
set zone-policy zone torguard default-action 'drop'
set zone-policy zone torguard from server firewall name 'all_to_torguard'
set zone-policy zone torguard from trust firewall name 'all_to_torguard'
set zone-policy zone torguard interface 'wg1000'

Now that we have source NAT and firewall rules that will allow the traffic. We need to traffic engineer the Emby traffic. The objectives are local routes should be routed normally and Internet routes should be routed to the Torguard. To accomplish this, we need to create two rules – one for the local routes and the other for the Internet routes.

set policy route torguard rule 2000 description 'route normally'
set policy route torguard rule 2000 destination address '10.0.0.0/14'
set policy route torguard rule 2000 set table 'main'
set policy route torguard rule 2000 source address '10.0.7.106/32'
set policy route torguard rule 2001 description 'destination torguard'
set policy route torguard rule 2001 destination address '0.0.0.0/0'
set policy route torguard rule 2001 set table '1'
set policy route torguard rule 2001 source address '10.0.7.106/32'

set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface wg1000

Once the policy and static route have been created, we need to apply the policy to the inbound interface.

set interfaces bonding bond0 vif 7 policy route 'torguard'

Once completed, verify the traffic path with traceroute. As you can see, the local routing is being routed normally. However, the traceroute to 1.1.1.1 took a different path compare to the example previously.

# Local routing
root@emby:~# traceroute -n 10.0.20.10
traceroute to 10.0.20.10 (10.0.20.10), 30 hops max, 60 byte packets
 1  10.0.7.1  0.400 ms  0.780 ms  0.740 ms
 2  10.0.20.10  0.524 ms * *
root@emby:~# 

# Internet access
root@emby:~# traceroute -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  10.0.7.1  0.428 ms  0.720 ms  0.697 ms
 2  10.29.0.1  89.258 ms  94.975 ms  94.817 ms
 3  128.199.32.253  95.464 ms  95.368 ms  95.261 ms
 4  138.197.250.120  95.701 ms 138.197.250.114  96.016 ms 138.197.250.98  95.632 ms
 5  138.197.250.80  95.293 ms 138.197.250.92  95.357 ms 138.197.250.94  95.402 ms
 6  80.249.211.140  106.648 ms  111.388 ms  116.864 ms
 7  1.1.1.1  95.392 ms  91.034 ms  91.958 ms
root@emby:~# 

We can also use the show policy route statistics command to verify that it is working.

$ show policy route statistics 

------------------------
Firewall Global Settings
------------------------

Firewall state-policy for all IPv4 and Ipv6 traffic

state           action   log     
-----           ------   ---     
invalid         drop     enabled 
established     accept   disabled
related         accept   disabled

-----------------------------
Rulesets Information
-----------------------------
--------------------------------------------------------------------------------
IPv4 Policy Route "torguard":

 Active on (bond0.7,ROUTE)

rule  packets   bytes     action  source              destination
----  -------   -----     ------  ------              -----------
2000  474       36.75K            10.0.7.106/32       10.0.0.0/14         
2001  891       216.17K           10.0.7.106/32       0.0.0.0/0           
10000 9.10M     10.39G    DROP    0.0.0.0/0           0.0.0.0/0

That should complete this post. Hope you’ll find this helpful.

Cheers!