11

I went to this file /etc/dhcp/dhclient.conf and added these two lines before the request line:

default interface-mtu 1200;

supercede interface-mtu 1200;

After I restarted and the system boots up, I run ifconfig and it says my MTU size is 1280. Why?? How can I change it to exactly 1200??

Update:

cat /etc/resolv.conf:

lrwxrwxrwx 1 root root 29 Mar 19 13:05 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

The resolv.conf file:

nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 2606:4700:4700::1111
nameserver 127.0.0.53
options edns0

The resolvectl output is:

Current DNS Server: 1.1.1.1
     DNS Servers: 1.1.1.1
                  8.8.8.8
                  2606:4700:4700::1111
      DNSSEC NTA: 10.in-addr.arpa

The dpkg -l *dnsmasq* output is:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig- 
aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture     
Description
+++-======================-================-================- 
==================================================
un  dnsmasq                <none>           <none>           (no 
description available)
ii  dnsmasq-base           2.79-1           amd64            Small 
caching DNS proxy and DHCP/TFTP server
un  dnsmasq-base-lua       <none>           <none>           (no 
description available)
Olivia Stork
  • 157
Afshin
  • 553
  • 3
  • 8
  • 19

5 Answers5

9

To determine the correct MTU setting, start with all MTU settings = 1500 and VPN = off. (VPN requires different testing).

Note: first remove your mods to /etc/dhcp/dhclient.conf and reboot.

In terminal:

ping [-c count] [-M do] [-s packet_size] [host]

The options used are:

  • c count: number of times to ping
  • M hint: Select Path MTU Discovery strategy. may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
  • s packet_size: Specifies the number of data bytes to be sent.

You should always start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 1 until you get a fragmented packet. Take that value (last good value) and add 28 to the value to account for the various TCP/IP headers. Eg. let's say that 1452 was the proper packet size (where you first got an ICMP reply to your ping). The actual MTU size would be 1480, which is the optimum for the network we're working with.

ping -c 4 -M do -s 1472 8.8.8.8 # this will probably show fragmentation

ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation

ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?

ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?

reference: How to determine the proper MTU size with ICMP pings

Update #1:

I would recommend that you remove the 3 extra nameservers that you added to /etc/resolvconf/resolv.conf.d/head and let systemd-resolved properly manage /etc/resolv.conf. That should work better with VPN.

Update #2:

You can also setup a DIFFERENT wired/wireless connection profile, just for VPN, that hardwires the MTU=1200. In terminal, type nm-connection-editor and there you can customize a profile just for VPN with autoconnect and MTU.

enter image description here enter image description here

heynnema
  • 73,649
5

You can automate the setting of the mtu for the VPN port when the VPN goes up as suggested in script /etc/NetworkManager/dispatcher.d/01-ifupdown. Scripts in the dispatcher.d folder are called with the port and event as arguments.

So, create a script in folder dispatcher.d with the following contents (if you want mtu 1200):

#!/bin/sh

#info : pre-up and pre-down are not implemented in network-manager


if [ "$2" = "vpn-up" ]; then

    /sbin/ifconfig "$1" mtu 1200

fi

(The name of the script does not matter.) Then make it executable with chmod +x <script>.

Olivia Stork
  • 157
oscar1919
  • 1,747
  • 14
  • 15
4

You could use tracepath ( from the iputils-tracepath package) to determine the Path MTU: 

walt@bat:~(0)$ dpkg -S $(type -p tracepath)
iputils-tracepath: /usr/bin/tracepath
walt@bat:~(0)$ tracepath primus.ip4.torontointernetxchange.net
 1?: [LOCALHOST]                                         pmtu 1500
 1:  spark3y                                               0.525ms 
 1:  spark3y                                               0.497ms 
 2:  spark3y                                               0.465ms pmtu 1492
 2:  dsl-xxx-xxx-xxx-xxx.tor.primus.ca                    32.701ms 
 3:  10.201.117.2                                         34.726ms asymm  5 
 4:  bb1.tor.primus.ca                                    39.238ms 
 5:  primus.ip4.torontointernetxchange.net                33.295ms reached
     Resume: pmtu 1492 hops 5 back 4
waltinator
  • 37,856
2

For those running Ubuntu under WSL, I found that MTU changes when joining a VPN were not propagating to the WSL vEthernet interface

# In windows command prompt
C:\Users\timothy.vanheest>netsh interface ipv4 show subinterface

MTU  MediaSenseState   Bytes In  Bytes Out  Interface




4294967295                1          0     111928  Loopback Pseudo-Interface 1
  1500                1  57917164385  17028233076  Wi-Fi
  1500                5          0          0  Ethernet
  1500                5          0          0  Local Area Connection* 1
  1500                5          0          0  Bluetooth Network Connection
  1500                5          0          0  Local Area Connection* 2
  1350                1  791851055   63176967  Ethernet 3
  1500                5          0          0  Ethernet 4
  1500                1    5268640   18986381  vEthernet (WSL)

Running this command (as admin) fixed it in a way that survived restarts.

# See: https://github.com/microsoft/WSL/issues/3957#issuecomment-479343268
C:\Users\timothy.vanheest> netsh interface ipv4 set subinterface "vEthernet (WSL)" mtu=1350 store=persistent

Not the best since it means I'm using a hardcoded MTU instead of the one that is optimal for the current network, but it's stable.

turtlemonvh
  • 121
2

I know this is an old topic, but for posterity in case anyone else comes across this question (since it's not answered anywhere else I can find).

Specifically addressing the question of setting the MTU in /etc/dhcp/dhclient.conf; not addressing whether this is ideal or how to check for a proper MTU value. Just the mechanics of setting the value.

OP spelled the 'supersede' statement wrong. The line below is the proper syntax, tested using isc-dhclient-4.4.1. Note: other services may apply their own changes to the MTU, but this will change the setting as far as dhclient is concerned.

supersede interface-mtu 1200;
NerdPirate
  • 21