Between 21.02 and 23.05 (and now 24.10) OpenWRT made many improvements to its UCI interface to dnsmasq w/r to the DNS options, notably CNAME is very useful for us, (among other improvements).
1 Like
Hello,
- What the router model is? I would like to know it is MTK or Qualcomm, then will know if it supported the Vanilla OpenWRT.
- Feel free to let me know what problems you have about the router features?
We are interested in the GL-X3000 and possibly the GL-XE3000
mediatek/mt7981
As mentioned above the CNAME feature is important to us and support for it was added to LUCI after 21.02
With the GL GUI I could not get wireguard configured for our environment and we already know how to do it with LUCI.
MWAN support is important for us as well.
We did our first, brief, field-test on the X3000 on Thursday and it lost connection after a couple minutes. Prognosis is this is due to a bad MWAN config but we have not root-caused yet.
I see OpenWRT has binaries published.
MWAN must have latency settings or it will never work correctly because WiFi clings on for forever so you have to set a latency threshold for it to switch to LTE properly.
LTE is a little better because the tower drops the connection but the client will just attempt to reconnect so it will bounce so you must set it to presumed-failed and not become usable until there is multiple successful pings below the latency threshold.
Something like
<60 ms for WiFi
<120 ms for LTE
I tried to get vanilla OpenWRT 24.10.2 to work but had no luck getting the modem to connect following the OpenWRT instructions. (set usbmode et. al.)
Is there any way to get the RM520N to work with ModemManager?
Hi,
- CNAME can be added in router SSH terminal, please edit this file
/etc/dnsmasq.conf - Add the CNAME rules in the at the end:
- Restart the process to take effect:
/etc/init.d/dnsmasq restart
- May I know what are the features of the WireGuard VPN (Server and Client) in the GL GUI which did not meet your requirements? What environment do you mean?
- Vanilla firmware may I could not support to, you can learn about this in the OpenWRT forum.
I can get connected using the custom Wireguard client conf file but it does not appear to Route Allowed IPs so that doesn't work.
Oh it's even more broken. It does not even set routes for the Allowed IPs.
This is unusable.
The routes for the Allowed IPs are supposed to be kernel routes managed by the wireguard driver.
When setting up a Wiregaurd Server
The client configuration screen does not seem to work.
Clicking the Apply button makes the screen blink but otherwise does nothing.
Expanding the options I do not see a place to enter the public key.
Hi,
This issue did not reproduce in my XE3000.
I can add the profiles, and edit the Allowed IPs, etc.
May I know what firmware version of your X3000/XE3000 is?
I have been using the 4.8 beta
Adding Allowed IPs ≠ Route Allowed IPs
The Wireguard client does not appear to route the allowed IPs nor does it have an option to enable/disable it.
I reflashed back to 4.7
I can now configure a Wiregaurd server but the software will not let me assign an IP for the clients.
Can I edit the assigned IP in a config file somewhere?
There's no location to set the endpoint and port for a client. Bloody hell.
This whole thing is a mess.
Wireguard is not like a classic VPN.
Trying to jam it into that box just causes problems.
The assigned IPs on the wireguard interfaces do not need to be on the same subnet (as they are required to be in a point-to-point VPN).
Further it is undesirable for the wg interface IPs to be on the same subnet because that makes the Allowed IPs and routes more complex.
Each wg interface should have its own subnet. If you only want it to have a single IP then assign it a /32 and set your Allowed IPs accordingly.
The "backside" wireguard tunnel fills this roll. What IP is used is different based on which egress NIC is selected upon output routing.
For site-to-site, in many cases you do not even need to assign an IP to the wireguard interfaces.
Note that all wireguard tunnels are site-to-site. You have clip routing to make it pretend to act-like a client-server.
You only need an IP assigned to the wireguard interface if the device itself is going to originate traffic egressed to the wireguard interface. e.g. This can happen if you set up a forward DNS, e.g. /hidden.domain.com/
There is no such thing as a "client" and "server" wireguard. It's all just wireguard. You can have quick-setup templates for rolls but everything needs to be editable not locked away.
We were able to configure wireguard via LUCI however something in the system is blocking ingress on port 800 from IPv6 even after we added rules to allow it.
It appears to work with IPv4 but we are out of IPv4 address and must use IPv6.
We have temporarily changed the inbound port for this wg node to a port >1024 but this is undesirable as opens a security breach for a user daemon to take-over the tunnel.
This spurious blocking of port 800 is what caused multi-wan to fail as the tunnel failed on X3000 side despite the upstream wg connecting.
In firmware 4.8, for VPN clients, route allowed IPs is enabled by default, and the routes are written into the VPN instance’s routing table.
We separate VPN server and client modes to better define their roles, focus on their specific features, and support modularization.
While it may not be as powerful as vanilla OpenWrt, our goal is to make it easier to use.