Changing Default MTU for Networking VMs

[DVM]

Try the same command but with sudo at the beginning. Remember that you need to do this in the ProxyVM, not the AppVM itself.

[DVM]

@crkorg

I ran the command with sudo. Something happened, but I don’t know what. I’ll test it now. Is it getting the MTU now from the network manager? I’m not seeing an MTU in that command

This iptables rule will make other AppVMs use the MTU set in the ProxyVM.
If the interface use MTU 1280 (for example) then it will use that on every single VMs. Just try it by going to https://browserleaks.com/ip and see if “MTU” is set to the correct one.

[DVM]

@crkorg

Browser leaks usually shows my MTU as near what I set it to, but slightly less than that. Browserleaks.com never seems like a good indication of the MTU. Instead, I just use sudo ifconfig and read the output of the interfaces. Is this not correct?

If it’s close to the one you’ve set in the ProxyVM, it means it’s fine.
If you want a certain MTU size, you’ll have to set that to the ProxyVM interface (eth0).

@crkorg

When I do that, am I going to have to run the command again? Is there a way to make the command automatically load?

I guess your sys-firewall is disposable, so you’ll lose everything each reboot. You can put a new AppVM in front of the firewall, put that iptables rule in /rw/config/rc.local and set the other VMs to use it instead of sys-firewall. That’s the easiest workaround.

@crkorg

My system-firewall is not disposable, although at some point I want it to be. Will the command persist even after I shut it down? I know when I restart the system-firewall VM, I lose all of the settings for the interfaces and get new vif#.#s every time I open it.

Would I just put this command as a script in rc.local? Like create mtu_interface_command.sh and put the command in there and make it executable?

If it’s not disposable, then you can put everything you need in /rw/config/rc.local, it should persist between reboots. You can make another script and call it from there or you can just paste the commands inside it and it will be executed each time the VM comes up.

[crkorg]

After running this command (sudo iptables -t nat -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu), I am still getting new vif#.#s show up, and they are all at 1500 for the MTU, and eth0 is at 1000.

@DVM @unman this didn’t work at all.

@Sven i’ve seen you post a lot of smart things. this is stumping me, and it’s either stumping everyone else who has replied or I am not implementing what they are saying correctly

@renehoj @Emily @deeplow does anyone know what to do here? hope it’s okay i’m mentioning some people on here who i have seen post some smart things

i am probably not implementing this correctly, but I thought I followed unman’s instructions. I’ve tried other things. It’s a real annoyance having to set the MTU each time for multiple vifs.

[crkorg]

Please help me.

Setting these manual MTUs each time I connect is hell.

[crkorg]

Unman, this is the original poster. Can you please help me? I’m almost certain I am doing something wrong, but I don’t know what. I created the script, I put it in the directory you specified. I thought it worked at first, but it’s not working now.

Can you create a qube and test your script with an MTU value of 1000 and then restart it, then connect multiple vif interfaces (through different networking qubes), and then see if you are getting new vifs with an MTU value of 1000?

I’m sorry to bother you and everyone who I have asked for help in this thread. I wish I were more skilled and this were easy for me to understand or implement on my own.

@unman

#!/bin/bash

command="$1"
vif="$2"
vif_type="$3"
ip="$4"

case "$command" in
  online)
    ip link set dev $2 mtu 1000
    ;;

I put this in rw/config/rc.local and rw/config/network-hook.d as set_mtu.sh and made it executable and readable and writable by all in both places. Nothing is changing.

[DVM]

@crkorg

After running this command (sudo iptables -t nat -I POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu), I am still getting new vif#.#s show up, and they are all at 1500 for the MTU, and eth0 is at 1000.

The iptables rule is not supposed to change the MTU values of all interface, it’s a rule that change the MTU on the fly. Like I told you, if your MTU is changed while checking online, then it means it’s working.

[crkorg]

edited since reply did not show as reply

[crkorg]

the previous response didn’t show as a reply

@DVM

I know that when my MTU isn’t low enough, my connection is very slow and whonix has more failed circuits, likely due to higher packet loss.

Because I am going through a VPN on a router that uses Wireguard before I use additional networking qubes to change IPs for SEO, the website is going to see the MTU of the lowest VPN, so if I connect, this isn’t a realistic way of testing to see if this has had an effect.

Are you saying if I run this command or create a script in rc.local that it will automatically change the MTU “on the fly” and so nothing will be running at 1500?

I could do this, but when I ran the other script in rc.local that @unman had created, it didn’t affect any of the vif interfaces after the reboot. I still don’t understand why unman’s script didn’t work. I would much rather be able to type ifconfig and see that the vif MTUs are all at the value I want rather than relying on third-party website testing.

[crkorg]

So it’s interesting… I have to wait until the vif interaces show up. But then once they show up, if I run systemctl start set_mtu.service, it changes every vif listed. It saves me time.

I wish there was a way to restart this command whenever there is a new vif interface connection.

[BEBF738VD]

Make a cron job that checks for new vifs and runs the script if necessary.

[crkorg]

You’re genius.

It’s finally done.

It may have been the systemctl service before that had changed a vif, and not unman’s script, which ended up not working. I still don’t know why the script from @unman
didn’t work.

[crkorg]

i’m using the service, using cron. It doesn’t make sense because the service is supposed to already change things on the fly, but if it works, it works!

(Solution!)

[crkorg]

I’m having a hard time implementing it in whonix. I did post about MTU on the whonix forum and was told by Patrick to find out elsewhere.

@BEBF738VD

Alright, try this in your TemplateVM that is used for sys-net (you’ll need root privileges):

Note: the script assumes that all VIFs follow the same naming pattern: vif#.# (doesn’t matter what # as long as it’s a number)

1. Copy the following script to /usr/bin/set_mtu.sh (change the mtu value according to your needs, here it’s 1500):

#!/bin/bash
for vif in $(ip link show | grep -o 'vif[0-9]*\.[0-9]*'); do
    ip link set $vif mtu 1500
done

2. Make it executable:

chmod +x /usr/bin/set_mtu.sh

3. Copy the following to /etc/systemd/system/set_mtu.service

[Unit]
Description=Set MTU

[Service]
ExecStart=/usr/bin/set_mtu.sh

[Install]
WantedBy=multi-user.target

4. Reload and enable:

systemctl daemon-reload
systemctl enable set_mtu.service

5. Shutdown your template, restart sys-net and check if the service is running:

systemctl status set_mtu.service

Can I do this in the whonix gw template?

[disp6252]

If you don’t have ICMP blocked before sys-whonix (in your router/vpn/networking qubes) then you can try to fix MTU issue in sys-whonix with this command:
sudo iptables -I INPUT -p icmp --icmp-type fragmentation-needed -m state --state RELATED -j ACCEPT
Tor is not yet fully bootstrapped. 30 % done - KVM - Whonix Forum

[crkorg]

This did not work.

[crkorg]

Can I use the same strategy by going into the whonix-gw template and creating the same set_mtu.sh files?

[disp6252]

Yes, it should work.