reduce_mtu parameter not working
tanc7 opened this issue · comments
Describe the bug
When you set the reduce_mtu parameter in config.cfg and spin up a new VPS to reflect the changes, the MTU on the server that is spun up is still 1500, making certain websites and apps like Apple and Amazon inaccessible.
I am referring to the documentation at "https://trailofbits.github.io/algo/troubleshooting.html#various-websites-appear-to-be-offline-through-the-vpn"
To Reproduce
Steps to reproduce the behavior:
- I am using Vultr via the API key
- Change the reduce_mtu parameter to reduce_mtu: X where X is the amount you want to reduce the MTU of the primary network interface.
- Start the automated setup.
Full log
algo@IPSecAlgo:~$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 172.30.243.34/32 scope global lo valid_lft forever preferred_lft forever inet6 fd00::e:f322/128 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 56:00:03:90:60:3c brd ff:ff:ff:ff:ff:ff inet 140.82.17.37/23 brd 140.82.17.255 scope global dynamic enp1s0 valid_lft 48760sec preferred_lft 48760sec inet6 2001:19f0:6001:2c6b:5400:3ff:fe90:603c/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 2591506sec preferred_lft 604306sec inet6 fe80::5400:3ff:fe90:603c/64 scope link valid_lft forever preferred_lft forever 4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 10.49.0.1/16 scope global wg0 valid_lft forever preferred_lft forever inet6 2001:db8:a160::1/48 scope global valid_lft forever preferred_lft forever algo@IPSecAlgo:~$ logout
Are you using IPsec or WireGuard clients?
For WireGuard the reduce_mtu
option only reduces the MTU on the client side (look in the config files that were generated). There should be no reason to reduce the MTU on the server.
Does your ISP have a lower than normal MTU?
I will test the ISP MTU when I get home. How do I do it? Run the ping command in your documentation without any VPNs?
I don't know of a more accurate way to test your ISP MTU than ping without using a VPN.
It's easy to change the MTU of a WireGuard client right from the WireGuard app. Try setting the WireGuard MTU to 1280 and if you still have issues the problem likely lies somewhere else.
You can use the tracepath
command in your client to discover your MTU.