No errors appear in the logread output so mwan3.user works correctly. The rules are correct, the routes present are also correct but incomplete the issues occur before the script is called.
in the config interface ‘wgresid’ is redondant you can safely delete it that would be one less thing to worry about.
How does in.www.format resolves ? Does nslookup in.www.format gives a correct answer ? Does kdig +noall +answer replies with an A record (install kdig if you don’t have it: opkg update; opkg install knot-dig) ?
Look at /tmp, does it contains coredumps from netifd ? There is a known issue with this executable.
Could you post the last ten lines or so of the logread output just after starting the tunnel ?
48574 is the port of the server, the port of the client can be anything if it isn’t specified or the specification is ignored the bind() system call returns a random value.
In the old forum it was possible to exchange private messages I would have been able to check the configuration myself unfortunately this isn’t available anymore. However I may have thought of a trick to workaround this restriction if you are interested just say so.
I am not associated with Teltonika, sometimes it is a challenge or I have the issue myself and I need a solution robust enough to be deployed in the networks I control. Of course I ignore users who have displayed an aggressive behavior previously.
Thank you, sorry for confusing whether what I see is the port used on this or the other side. My point was just to check that we have not inserted something which makes us unable to hear the response from the server.
I’m game. I assume any possible solution to be of interest to the forum, our back and forth less so…
I will get back to you on the rest but it’s late today.
I’ll would like to see the 10 or so last lines of the logread output just after starting the tunnel, look at something like
2023-12-19T16:46:06-04:00 lgrrutx netifd: Interface 'wgtls' is setting up now
it may give a clue about the cause of the failure.
For the trick, tell me when you are ready I don’t want to have the information visible for too long.
Several routes are missing, could you try to add them manually:
ip -4 route add ip-of-wg-server via 192.168.176.1 metric 2
ip -4 route add 0.0.0.0/1 dev wgresid metric 4
ip -4 route add 128.0.0.0/1 dev wgresid metric 4
I have followed the path taken when building the wg tunnel. The route to the wg server is explicitly set by /lib/netifd/proto/wireguard.sh the code isn’t that easy to follow but with tracing at least it is possible to see what it is doing.
Add:
set -x
exec >/tmp/wg.log 2>&1
after the #!/bin/sh line. The output will be in /tmp/wg.log
EDIT: the culprit is somewhere around line 213+, the code differs from the one in the base OpenWrt firmware and looks a little suspicious:
defaults="$(ip route show default | grep -v tata | awk -F"dev " '{print $2}' | sed 's/\s.*$//')
What this “tata” does there ? Huhhh.
2nd edit:
Got it, at the end.
Replace the default /lib/netifd/proto/wireguard.sh by this one.
Of course make a copy before …
replace the file as described, and retry. This wireguard.sh is the one coming straight from the codebase of OpenWrt I haven’t edited it. May or may not work, explanation below.
and / or add the debug code (set -x; exec >/tmp/wg.log 2>&1) described above this will show why the route to the wg server is not added. Anyway, I would like to see the contents of this /tmp/wg.log file.
About wireguard.sh: it has been modified by Teltonika, as I understand the added code the objective is to delete the route to the wg server when the tunnel is shutdown.
To do that a file named /tmp/wireguard/default-status is created with enough information to execute the ip route delete command.
Unfortunately the implementaion is wrong the result will fall short of the objective if the configuration contains more than one tunnel only one route can be deleted. Of course the deleted route depends on the build order if the tunnels are built in the wga then wgb order and wga is shutdown manually the deleted route is the one to the wgb server !
The edits made by Teltonica (line 217+) contains modified tests to determine if a route must be added I suspect this fails under certain circumstances but I haven’t been able to replicate the isssue myself so the set -x; exec … to trace the execution.
I have updated my RUTX11 to version 07.06 with keep settings and changed the WAN from wlan1 to eth1, and now the tunnel doesn’t even starts I must perform a firstboot -y and reconfigure everything manually …
Dear all & any who might wonder what became of this,
I did not have the time to continue to pursue for months. I then did a clean upgrade of the firmware of my X10 to the newly released version RUTX_R_00.07.07.1 and suddenly it worked exactly as it should straight from the web UI.