I need to configure a router for a family member, that is not technical at all. So I have to make sure its stable and works. After some trial and error with the PBR app, I came to the conclusion that it is 'not' a good option in this particular case. Its slow to boot and for some reason does not always work. So I was looking for an alternate solution.
The latter.
Generally, most of the conditions can be met, except the last one with the failover.
For that you either monitor it yourself with a script and change the gateway or look into mwan3.
These 2 are not needed if you want to block lan->wan traffic. The absence of a forwarding means that it will be blocked, thus no need for a blocking rule.
Also not needed since you have a lan-to-openvpn rule.
But again these are just firewall rules, not ip routing rules. If you don't have the latter, you'll end up with firewall blocking the traffic that doesn't go to the correct gateway,
Thank you, that makes sense, so those need to be added for wan and openvpn under "routing/ipv4-rules" ? And do I need to add route-nopull to openvpn config ?
What I'm reading is that it tags all packets not in ipset wan(6) and then uses the tag to route packets over table 2 that points to the vpn. Based on this I have:
execute commands from "Route LAN to VPN by IP set"
echo '2 wan' >>/etc/iproute2/rt_tables
for IPV in 4 6
do
uci -q delete firewall.wan_set${IPV%4}
uci set firewall.wan_set${IPV%4}="ipset"
uci set firewall.wan_set${IPV%4}.name="wan${IPV%4}"
uci set firewall.wan_set${IPV%4}.family="ipv${IPV}"
uci set firewall.wan_set${IPV%4}.match="net"
uci -q delete firewall.lan_mark${IPV%4}
uci set firewall.lan_mark${IPV%4}="rule"
uci set firewall.lan_mark${IPV%4}.name="Mark-LAN-WAN"
uci set firewall.lan_mark${IPV%4}.src="lan"
uci set firewall.lan_mark${IPV%4}.dest="*"
uci set firewall.lan_mark${IPV%4}.ipset="wan${IPV%4} dest"
uci set firewall.lan_mark${IPV%4}.proto="all"
uci set firewall.lan_mark${IPV%4}.family="ipv${IPV}"
uci set firewall.lan_mark${IPV%4}.set_mark="0x1"
uci set firewall.lan_mark${IPV%4}.target="MARK"
uci set network.lan.ip${IPV}table="1"
uci set network.wan.ip${IPV}table="2"
uci -q delete network.lan_wan${IPV%4}
uci set network.lan_wan${IPV%4}="rule${IPV%4}"
uci set network.lan_wan${IPV%4}.in="lan"
uci set network.lan_wan${IPV%4}.mark="1"
uci set network.lan_wan${IPV%4}.lookup="2"
uci set network.lan_wan${IPV%4}.priority="30000"
done
uci commit firewall
uci commit network
service firewall restart
service network restart
That is how netifd works (and one of the reasons netifd was not used in the pbr app anymore )
The default route should go via your vpn so the main routing table should not need a default route via the wan according to the netifd paradigm.
What I am not sure about is if there will be a proper escape route for the vpn endpoint via the wan
It is not stacked on top per se but there should be a route for the VPN endpoint (server) via the wan, not sure how that is handled by netifd and OpenVPN.
The examples of netifd are all made with WireGuard as VPN
I seem to have an ipset that is not-existent called "wan dest". First I thought it was a mistake, but its not. If "wan" is used it will not work if "wan dest" is manually entered it does
I understand what the rule is supposed to do, what I did not understand was why
firewall.lan_mark.ipset='wan dest' <----------------- works
firewall.lan_mark.ipset='wan' <----------------- does not
When selecting an ipset in luci its purpose remains unassigned(instead of assigning it to destination address which was what I wanted.) In retrospect that seems only logical because it might as well be used as a source address ipset. Hence the added dest.
At least that is what I think is the case.
Anyway, I had it working by disabling OpenVPN on startup, setting the default route and then starting OpenVPN manually, that came with its own set of problems. I had to modify /etc/rc.local to add a default route to the modem., but that did not always work reliable. So that became as ugly as:
while ! ip route add default via <modem ip address>;do sleep 1;done
/etc/init.d/openvpn start
exit 0
Than I had to modify /etc/iproute2/rt_tables to add table 2
# custom values
#
2 wan
As of now, I have two working situations, one with OpenVPN and one with WireGuard. Now I just have to figure out exactly what steps were actually needed.
