Try the same command but with
sudo at the beginning. Remember that you need to do this in the ProxyVM, not the AppVM itself.
Try the same command but with
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.
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).
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.
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.
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.
@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
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.
Please help me.
Setting these manual MTUs each time I connect is hell.
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.
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.
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.
edited since reply did not show as reply
the previous response didn’t show as a reply
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.
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.
Make a cron job that checks for new vifs and runs the script if necessary.
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
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!
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.
Can I do this in the whonix gw template?
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
This did not work.
Can I use the same strategy by going into the whonix-gw template and creating the same set_mtu.sh files?
Yes, it should work.