Wireguard MTU on LBR20 running Voxel firmware

[jonathan_winters]

After my LTE provider made a change a week or so ago, I have been working my way through the various issues that their changes created for me. It now appears that I'm behind an extra layer of NAT/CG-NAT that is really throwing off some of my internal networking (which was all finely tuned prior to the recent change).

So far my fix has been to tunnel all of my traffic through wireguard to a VPS that I have running in Oracle cloud (in the Always Free tier). It works well to work around the issues presented by CG-NAT, but the downside is that my speed/performance has REALLY taken a hit. The best I can tell is that between the wireguard tunnel and my local network, I'm running into a fair amount of packet fragmentation, presumably due to the MTU coming from my LAN + the wireguard tunnel + CG-NAT.

To update the MTU, I copied the original `/etc/init.d/wg-client` init script into the overlay directory so that I could customize it, and then adjusted the MTU to 1400 there (reduced from 1420). Of course, the change persisted, but I'm still losing far more of my bandwidth than I would expect that I should based on my history with using wireguard in various environments, so I'm wondering if I should either:

1) Further reduce the MTU to prevent more fragmentation - I don't know for sure the implications of going even smaller, but it seems like even the default 1420 is already pretty small, so I'm cautious to take it down even more.

OR

2) See if I can find some way to reduce the complexity in my home network to reduce the impacts of the Wireguard tunnel.

For some context, here is my network connection:

INTERNET --> Oracle Cloud VM [ WG "Server" ] --> ISP: CG-NAT/T-Mobile LTE --> LBR20 [ WG "Client" ] --> TP-Link Omada Gateway --> LAN

NAT1: My LBR20 *receives* an RFC5735 IP address from T-Mobile's CG-NAT - 192.0.0.2/27
NAT2: My LBR20 creates a small LAN for itself and the Omada Gateway - 192.168.1.0/24
NAT3: My Omada Gateway is the gateway for my entire home LAN - 172.16.0.0/24

I'd prefer to remove the 2nd NAT but the LBR20 doesn't have an option for Bridge/IP-Passthrough mode when using LTE as the primary connection, so as far as I know about the LBR20, that is an unavoidable hop. If someone knows of a way to put this into bridge mode while using the LTE modem as the primary uplink, please let me know!

Does anyone have any thoughts or advice on the best way around this?

As an aside, I've been running Voxel firmware on my LBR20 for quite a while now and have REALLY appreciated all of the power and flexibility it has given me. I've managed to create a library of scripts that allow me to quickly and easily run various `AT+` commands to update the MBN, restart the modem, and change the band locks, and I've also managed to rig up a series of symlinks that retain my bash history and other fun things. Overall I'm REALLY happy with the flexibility of this setup, so hopefully I can get this last piece fixed up.

 

[Voxel]

1) Further reduce the MTU to prevent more fragmentation

IMO this way.

As an aside, I've been running Voxel firmware on my LBR20 for quite a while now and have REALLY appreciated all of the power and flexibility it has given me. I've managed to create a library of scripts that allow me to quickly and easily run various `AT+` commands to update the MBN, restart the modem, and change the band locks, and I've also managed to rig up a series of symlinks that retain my bash history and other fun things. Overall I'm REALLY happy with the flexibility of this setup, so hopefully I can get this last piece fixed up.

Thank you.

Voxel.

 

[jonathan_winters]

Thanks for the confirmation!

I pulled the commands out of the wg-client script to update the MTU on the fly -- that is so much better/faster than rebooting to activate a small change like this to the tunnel.

 

[jonathan_winters]

Voxel.

I'm working on a script to bring down the wireguard tunnel without rebooting the LBR20. Is this something you have the in your roadmap at all? In my case, I'm running my own wireguard server and when my hosting provider had an outage, I did too at home. It would've been nice to just bring down the tunnel instead of rebooting the whole device (which is painfully slow). Ultimately, I'd like to set up a watchdog that will bring down the tunnel if my endpoint ever goes offline for more than a minute... this is Phase 1 of that project.

I noticed in `/mnt/circle/overlay/etc/init.d/wg-client` that you're deleting the original default route when bringing up the wireguard tunnel instead of creating a new route higher up the routing table that preempts the original default route. Is there a particular reason for going this way?

I ask because leaving the original default route would make it easier to revert to the original settings when bringing down the tunnel. (We would just have to delete the higher default route from the tunnel.)

I'm not looking to bog you down with work that isn't a priority for you, but if there was a reason for your method I don't want to reinvent the wheel if you've already discovered that this is truly the best way to handle it on these Netgear devices.

Edit: Here is a gist of the changes I made. This has worked in my use-case (I'm using only LTE uplink so I don't know how this would behave when using the other uplink/failover options). I edited the default script to update the MTU and *not* delete the original default gateway. And then if I need to manipulate the tunnel after that, I use my `wg-client-forked` script.

Again - I'm not looking for you to QA or review anything here -- if you have any input I'm happy to receive it, but I'm happy to run this at my own risk in my home network. So mostly I'm interested to hear about why you were removing the original default gateway (just to make sure I'm not missing something).

 

[Voxel]

Sorry. Not so many feedbacks ftom me now. I am not expert in all areas unfortunately. Scio me nihil scire или scio me nescire.I am not very experienced expert in WG.

Voxel.

 

[sfx2000]

After my LTE provider made a change a week or so ago, I have been working my way through the various issues that their changes created for me. It now appears that I'm behind an extra layer of NAT/CG-NAT that is really throwing off some of my internal networking (which was all finely tuned prior to the recent change).

If you're on T-Mobile, you're not behind a CGNAT - it's worse - it's 464XLAT... there is no bridging of the modem, as it is the router for IPv4/IPv6

The CLAT client in the device is what assigns the RFC1918 local address, the LTE APN only provides IPv6...