Managing a device in another VLAN (with VPN policy based routing installed)

Installing and Using OpenWrt Network and Wireless Configuration
24

You can also utilize include scripts:

cat << EOF > /etc/vpn-policy-routing.custom.user
ip route add 192.168.5.0/24 dev eth0.5 table 201
true
EOF
uci -q delete vpn-policy-routing.custom
uci set vpn-policy-routing.custom="include"
uci set vpn-policy-routing.custom.path="/etc/vpn-policy-routing.custom.user"
uci commit vpn-policy-routing
/etc/init.d/vpn-policy-routing restart

https://docs.openwrt.melmac.net/vpn-policy-routing/#custom-user-files-include-options

1 Like
26 
root@OpenWrt:~# /etc/init.d/vpn-policy-routing restart
Creating table 'wan/pppoe-wan/ [✓]
Creating table 'nordvpntun/tun0/ [✓]
Routing 'Laptop (wifi) ' via wan [✓]
Routing 'Laptop (ethernet)' via wan [✓]
Routing 'Synology NAS' via wan [✓]
Routing 'Plex' via wan [✓]
Routing 'Synology services' via wan [✓]
Routing 'Wiser Heat' via wan [✓]
RTNETLINK answers: File exists
[✗]
vpn-policy-routing 0.2.1-13 started with gateways:
wan/pppoe-wan/
nordvpntun/tun0/ [✓]
ERROR: Error running custom user file '/etc/vpn-policy-routing.custom.user'
vpn-policy-routing 0.2.1-13 monitoring interfaces: wan nordvpntun .
27

chmod +x /etc/vpn-policy-routing.custom.user ?

1 Like
28 
sh -x -v /etc/vpn-policy-routing.custom.user
1 Like
29 
root@OpenWrt:~# sh -x -v /etc/vpn-policy-routing.custom.user
ip route add 192.168.5.0/24 dev eth0.5 table 201
+ ip route add 192.168.5.0/24 dev eth0.5 table 201
RTNETLINK answers: File exists
1 Like
30

This means the route is already present in that table:

ip route show table 201
1 Like
31 
root@OpenWrt:~# ip route show table 201
default via dev pppoe-wan
10.10.3.0/24 dev br-WRT_Guest proto kernel scope link src 10.10.3.1
192.168.5.0/24 dev eth0.5 proto kernel scope link src 192.168.5.1
1 Like
32

In theory, all traffic now from VLAN 5 should now pass through WAN right if I am understanding correctly?
I have no way easily checking if it behaving as expected. However, it looks like all traffic on br-WRT guest should also go through WAN. But when I test it, it is going through the VPN.

33

Because you don't have any rule for that and vpn is the default gateway.

1 Like
34

I must be really thick/really confused.
What was the purpose of this?

192.168.5.0/24 dev eth0.5 proto kernel scope link src 192.168.5.1
35

To know where to send packets destined for 192.168.5.0/24 when host is classified to routing table 201. If it is not in the routing table, it will be sent to default gateway.

2 Likes
36

Right so when VPN is default gateway packets from 192.168.5.0/24 should still go through WAN?

37

The table ID 201 defaults to the active WAN routing policy.
While using the VPN, your traffic is most likely goes to another table.

So you have 2 options:

  • Add a route to the VPN table.
  • Add a policy to prefer the WAN table for specific traffic.
2 Likes
38

Thanks. This makes sense and I am able to implement the second option but would prefer the first option.
How do I find the VPN table number since it isn't listed under /etc/iproute2/rt_tables?

1 Like
39

It is mentioned when you do a /etc/init.d/vpn-policy-routing support

2 Likes
40

So VPN is routing table 202 it seems. So I created a route on table 202 similar to the following for WRT_Guest just as a proof of concept but with no luck:

config route
	option gateway 'WAN gateway ip'
	option interface 'WRT_Guest'
	option target '0.0.0.0'
	option netmask '0.0.0.0'
	option table '202'
41

This static route is very wrong. You add a default route (0/0) egress Guest interface via the wan gateway IP in table 202.
If some network is missing from the rt 202 then you need to add it without gateway, but with proper interface (WRT_Guest), target (192.168.5.0) and netmask (255.255.255.0).

2 Likes
42

Ok, that explains why it's not working but then how do I get it to route via WAN rather than through VPN?

43

Haven't you added a rule for that in vpn-pbr already?

1 Like
44

Yes, I did but I had it disabled which explains a lot! BUT whilst traffic from VOIP and WRT_Guest does now go through WAN when VPN is active and thus the default gateway, I am still unable to administrate the client in the VOIP vlan, which is the original reason for the thread.