When working with OpenVPN connections, you might encounter warnings like:

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1469', remote='link-mtu 1569'
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400', remote='tun-mtu 1500'

These messages indicate a configuration mismatch between your OpenVPN client and server regarding Maximum Transmission Unit (MTU) settings. The MTU determines the largest packet size that can be transmitted without fragmentation.

Inconsistent MTU values can lead to:

• Packet fragmentation and reassembly overhead
• Reduced VPN performance
• Potential connection drops
• Higher latency for TCP connections

From your DD-WRT router configuration, we can see:

tun-mtu 1400
mtu-disc yes

This sets the tunnel MTU to 1400 and enables Path MTU Discovery. The server is pushing these values to clients.

Your client config is missing explicit MTU settings. Let's modify it to match the server:

dev tun
cipher AES-128-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote vpn.server.com 1194 udp
pkcs12 key.p12
remote-cert-tls server
tls-auth tls.key 1
tun-mtu 1400
link-mtu 1469

If you prefer to let OpenVPN handle MTU automatically:

# Remove tun-mtu from server config
# Add this to client config:
mtu-disc yes
fragment 0
mssfix 1400

After making changes, verify with:

ping -M do -s 1472 vpn.server.com

Gradually reduce the packet size (-s parameter) until you find the maximum unfragmented size.

For environments with strict MTU requirements:

# Server config (DD-WRT)
tun-mtu 1400
link-mtu 1469
mssfix 1360
fragment 1400
mtu-disc yes

# Client config
tun-mtu 1400
link-mtu 1469
mssfix 1360
fragment 1400
mtu-disc yes

Add these to your OpenVPN config for debugging:

verb 4
mute 10

This will provide detailed MTU-related information in your logs without being too verbose.

---

When working with OpenVPN connections, you might encounter these common warnings in your client logs:

WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1469', remote='link-mtu 1569'
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400', remote='tun-mtu 1500'

These messages indicate a mismatch between the Maximum Transmission Unit (MTU) settings on your client and server configurations. The inconsistency can lead to suboptimal network performance and potential packet fragmentation.

The MTU values control how large packets can be before they get fragmented:

• tun-mtu: Specifies the MTU for the virtual tunnel interface
• link-mtu: Represents the total packet size including OpenVPN headers

A simple calculation relates these values:

link-mtu = tun-mtu + encapsulation overhead (typically 69 bytes for UDP)

From your DD-WRT router configuration, we can see these relevant parameters:

tun-mtu 1400
mtu-disc yes

The server is explicitly setting tun-mtu to 1400 (resulting in link-mtu of 1469). The mtu-disc yes enables Path MTU discovery.

The client configuration doesn't specify MTU values, which means:

• Default tun-mtu of 1500 is being used
• Resulting in link-mtu of 1569 (1500 + 69)

Here are three approaches to resolve the inconsistency:

Option 1: Standardize on Server Settings

Modify client configuration to match server values:

dev tun
cipher AES-128-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote vpn.server.com 1194 udp
pkcs12 key.p12
remote-cert-tls server
tls-auth tls.key 1
tun-mtu 1400
link-mtu 1469
mtu-disc yes

Option 2: Adjust Server to Client Defaults

Change server configuration (in DD-WRT web interface):

tun-mtu 1500

This would automatically set link-mtu to 1569.

Option 3: Optimal MTU Discovery

For best performance, determine the optimal MTU for your specific network path:

# Linux/Unix command to find optimal MTU:
ping -M do -s 1472 -c 4 vpn.server.com

# Windows command:
ping -f -l 1472 vpn.server.com

Adjust the packet size until you find the largest value that doesn't fragment, then calculate:

optimal_tun_mtu = max_packet_size - 28 (IP/ICMP headers)
optimal_link_mtu = optimal_tun_mtu + 69

For networks with complex routing or PPPoE connections, you might need additional parameters:

fragment 1300
mssfix 1300

These help handle cases where intermediate networks have lower MTUs than your VPN endpoints.

After making changes, verify with these commands:

# Check current MTU on Linux:
ip link show dev tun0

# On Windows:
netsh interface ipv4 show subinterfaces

Monitor your OpenVPN logs for remaining warnings and test VPN throughput with tools like iperf3.