I've recently been trying to get my 4G backup built into my original ISP router (repurposed as a wifi AP) working with openwrt.. I've confirmed its working by creating a static route:
OK, you have 2 WANs - you wanna use 1 (regular ISP) as primary and the other (cellular 4G) as backup. Plus, you wanna run Wireguard over it, cool!
Exactly!
I would have thought the metric would have prevented the 4G backup being used.. however after reading your reply I had a thought, perhaps wireguard (metric: 10) is routing the 4G connection and overwriting the given metric (metric: 100)?
Perhaps if I prevent 192.168.1.40 being routed through wireguard my issue will be solved? Will that mean the clients connected through the wireless AP will also not be routed through wireguard?
I will give it a test tonight.. probably don't want the 4G backup routed through wireguard as its painfully slow most of the time.
You simply add this when you want to use the 4G connection. FYI, setting up DNS requires some more finagling with DNS, so I just simply gave the DST IP for the example.
mwan3 needs designated wan interfaces to work. I believe a Macvlan might help there, it is also proposed as a workaround in case of single interface devices which want to work with multiple interfaces.
Yes this should be automatic in the whole house VPN client use case. Wireguard installs a /32 route to the peer, but it may not choose the WAN interface that you want to use. With full diversion of all IPs to the VPN, the VPN server is the only destination IP your router accesses by sending a packet (encapsulated and encrypted) on the raw Internet through the modem.
No matter how the real Internet is connected, the virtual Internet for VPN users-- the 0.0.0.0 default route-- is always into the tunnel so that packets can be encrypted first. That creates new packets with a destination IP of the VPN server, and another routing is conducted to send them there.
I think that when Wireguard is told to route allowed IPs 0.0.0.0, it actually installs a split route 0.0.0.0/1 and 128.0.0.0/1. This leaves your original raw default route in place but inactive*. Should Wireguard be taken down and its routes removed, the original route works again.
Using route or ip route show will help understand this.
When two routes to the same IP exist, the more specific one will be used, regardless of its metric vs the less specific one.
Unfortunately still struggling with this.. not entirely sure how to proceed.
The discussion above is a little over my head if I'm being honest.
I've been attempting to create a secondary wan connection using vlans, macvlans, static addresses etc. in hopes that I can get mwan3 configured.. but I've had no luck.
I've only managed to gain access to the 4G AP by using a static route.
Might have to just settle with manually creating the route in the event of a failure..
I decided to give this another try over the weekend, managed to get my ISP router configured as "wanb"... Just finished testing, appears to actually be working.. kinda!
Not sure if there is any issue with the way I've configured the following:
config device
option type 'macvlan'
option ifname 'eth0'
option name 'veth1'
option mtu '1500'
option ipv6 '0'
option mode 'vepa'
config interface 'wanb'
option proto 'static'
option ipaddr '192.168.1.39'
option netmask '255.255.255.0'
option gateway '192.168.1.40'
option metric '30'
option device 'veth1'
list dns '1.1.1.1'
list dns '1.0.0.1'
option force_link '0'
I have noticed I need to manually stop the wan interface for the 4G interface to kick in, otherwise I just get timeouts on my clients not sure if this is normal behaviour? I've been monitoring mwan3, I can see the policy being updated during my testing so not sure why the manual stop is required.
Edit: I no longer have to manually stop the interface when using the mwan3.user script.
Also currently things are working without wireguard, the next thing I need to do is reconfigure wireguard to only route connections from the main wan.. @lleachii not sure if you can assist with this? I've disabled "route allowed ip's" for the time being.
Edit: I've come up with a solution that seems to be working really well, I'm using the /etc/mwan3.user script to disable the wireguard interface when wan goes down.. I'm open to any suggestions if this can be done in a cleaner/simpler manner however:
if [ "${ACTION}" = "ifup" ] && [ "${INTERFACE}" = "wan" ] ; then
ifup cf_warp
fi
if [ "${ACTION}" = "ifdown" ] && [ "${INTERFACE}" = "wan" ] ; then
ifdown cf_warp
fi
if [ "${ACTION}" = "connected" ] && [ "${INTERFACE}" = "wan" ] ; then
ifup cf_warp
fi
if [ "${ACTION}" = "disconnected" ] && [ "${INTERFACE}" = "wan" ] ; then
ifdown cf_warp
fi
Also I was using vpn-policy-routing to stop a single client being routed to the VPN.. I don't believe vpn-policy-routing is compatible with mwan3. So I'll need to figure out an alternative way to do this also.
Edit: turns out I can configure a mwan3 policy to do this!