FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
480 views 9 comments
by anonymous
Scenario : RUTX11 communicating via Telstra Mobile Broadband with Openwrt router ver 21.02.1 with client systems (Linux and Android) at both ends. Connections and data transfer work well in both directions on original RUTX11 7.0.0 firmware. After upgrade to 7.1.2, connections still work Ok. On connections initiated on RUTX11 client to server on Openwrt, connection is established and small data packets can be exchanged but large data transfers freeze. Tried many investigations and changes to config to no avail.

Reverted back to 7.0.0 and restored config and everything back to normal. I cannot investigate further as I cannot continue without a working system.

1 Answer

0 votes
by anonymous
Hello,

Check the MTU of the wwan0 interface it is probably smaller than the default 1500 bytes. With the default MTU of 1420 bytes on the wireguard interface large enough UDP packets will be dropped this explains why small transfers succeed but large ones fail.

Fix: set the MTU of the wg interface to be the MTU of wwan0 minus 80 bytes.

Regards,
by anonymous
Thank you for the suggestion. I suspected the MTU as suggested elsewhere and had tried a lower MTU with no luck on my earlier upgrade.However, I did not check the wireless link MTU.

This time, using ping the Telstra wireless broadband MTU  appears to be 1432, leaving 1352 for WG.

So I changed the MTU setting for wwan to 1432 and both peers of the wg link to 1352. These settings worked as expected on RUTX11 ver 7.0.0. But after upgrade, to 7.1.2 still no success.

Also wireguard was installed on a Ubuntu PC connected to the RUTX11 and used to set up a separate tunnel over the wireless link. It works perfectly.

After trying MTU of 1300 with no success, I've restored the system to V 7.0.0 and everything is ok.

None of this explains why it works on 7.0.0 but not 7.1.2. So it does not seem an MTU problem, and increasingly its looking like a bug in 7.1.2.
by anonymous
There must be something subtle here I have a RUTX11 v07.01.2 with two WG tunnels, one to a dd-wrt in the same EU country using the default 1420 bytes MTU and one to another dd-wrt in the US this one uses a 1360 bytes MTU. For the latter if set to 1420 it fails with the same symptoms small packets (ping/traceroute/...) go through but large enougth packets (scp/https ...) are dropped which can be seen by monitoring the packet counters. The cause is probably an IPv4->IPv6 conversion somewhere in the path.

What are the MTUs of the base interfaces used by WG ? I have seen one using 1460 bytes on the mobile interface for some unknown reason.
by anonymous
Hello,

I'd like to request for a little bit more detail regarding this issue. I've tested WG tunnel on my end using a large file (3GB+) and trying to transfer it from one end-point to another end-point via WG tunnel from one LAN device to another LAN device. I've also tried transferring the same data over the internet but I did not seem to run into any issues regardless of which interface was in use for the test - mobile or wired (Ethernet).

I've also done some testing with iperf3 and it seems like router can handle ~350-400 Mbps throughput over the tunnel when running in TCP mode without any bandwidth limitations and using wired WAN. It did struggle quite a bit with the UDP test, dropping packets consistently when transferring any sort of data faster than ~125-150 Mbps but after digging a little bit deeper into this problem it seems to be a separate issue with iperf3 package itself.

The mobile data transfer was (naturally) much lower than over the wire but it did not hang up during a real file transfer and when testing it with iperf3.

It is unlikely that it's an MTU-related issue in this case. In regards to MTU, the maximum permitted MTU value will be dictated mostly by the mobile operator that you've connected to and they may be dropping packets which are too large (possibly at their edge). Also, MTU being the issue doesn't explain why tunnel would work with an older firmware rather than a new one since in both firmware versions the default MTU value of mobile interface is the same.

This may be a very specific issue with the newest firmware and the server/client data exchange, with some external variables also possibly impacting performance of the tunnel. Could you try setting up an alternative wireguard tunnel somewhere else (can also do it online by using, for example, a VPS) and testing whether these issues occur with different devices when RUTX11 tries to transfer traffic to them via the wireguard tunnel? I'd like to get to the bottom of this issue but it sounds like this one may be quite difficult to catch in action consistently unless the environment would be setup in an identical manner just like the first time.

Any information or potential thoughts would be highly appreciated as well.

Best regards,

Tomas.
by anonymous

Thanks again other routers with openwrt

by anonymous
If you have a spare wg config to the same destination I (or Thomas) can test it would be very helpful.
by anonymous
Thanks for your offer. But I'm unwilling to upgrade the RUTX11 remotely. Its working well for now on the old firmware and I'll investigate again when next on site.
by anonymous
If you (or anybody else who may be facing the same issue) can reproduce this issue and send us over the details, we'd appreciate it before the issue becomes widespread if, in fact, it turns out that the WG service is faulty on our end.
by anonymous

Any information or potential thoughts would be highly appreciated as well.

Hmm. Maybe. I don't have a pristine RUTX to check but by default are the lan->wireguard and lan->wireguard firewall rules set with MSS clamping active in version 7.01.2 ?

  

by anonymous
MSS clamping is not enabled on LAN and WG zone (when it's created) by default.