A little confused on OpenVPN MTU

JaredBusch

I have a lot of Ubiquiti ERL scattered around generally working great.

Today I had a really odd connectivity issues while working remote via ScreenConnect at a client site. This site has always seemed slow, but I just wrote it off to "DSL."

This site is the only site that uses DSL with PPPoE for their service. The ERL is handling the PPPoE auth and everything has been in place for more than a year.

This evening I decided to look into it closer.

The router was originally setup with the PPPoE wizard which created a few settings.

firewall

modify PPPoE_OUT {
    description "TCP clamping"
    rule 1 {
        action modify
        modify {
            tcp-mss 1452
        }
        protocol tcp
        tcp {
            flags SYN
        }
    }
}

interfaces

ethernet eth2 {
    description WAN
    duplex auto
    pppoe 0 {
        default-route auto
        firewall {
            in {
                name PPPoE_IN
            }
            local {
                name PPPoE_LOCAL
            }
            out {
                modify PPPoE_OUT
            }
        }
        mtu 1492
        name-server auto
        password xxxxxxxxx
        user-id xxxxxxxxxx
    }
    speed auto
}

Wondering about the seemingly harsh MSS clamping, I started tinkering with MTU.
I removed the firewall out rule and then tinkered with various MTU settings on the eth2 and pppoe 0 interfaces.

Eventually I determined that having no MTU specified gives me what I would expect. I lose 8 bytes over a straight Ethernet connection. This means eth2 auto negotiates to 1500 and pppoe 0 then sets itself to 1492.

a bunch of ping -c 1 -s 1472 -M do 8.8.8.8 and ping -c 1 -s 1464 -M do 8.8.8.8 later confirms that this works like I think. The 1472 needs fragmented and the 1464 works.

Great, I have confirmed everything works like I expect and I have removed the odd firewall modify rule.

So now I do some internal pings across the OpenVPN tunnel. I am assuming I have additional overhead that needs accounted for, but I start with the 1464 just because. To my surprise, ping -c 1 -s 1464 -M do 10.204.1.1 works. Testing lets it go all they way up to ping -c 1 -s 1472 -M do 10.204.1.1. This is the value you would expect from a normal 1500 MTU Ethernet line.

Now the OpenVPN config has no Specific MTU applied, so I assume it is setting itself to 1500 like anything else.

openvpn vtun10 {
    description "Site A to Site B"
    local-address 10.204.9.2 {
    }
    local-port 1195
    mode site-to-site
    openvpn-option --comp-lzo
    remote-address 10.204.9.1
    remote-host vpn.domain.com
    remote-port 1195
    shared-secret-key-file /config/auth/xxxxxxxxxx
}

But the tunnel has to go through pppoe 0 to get out, so how the hell does that work?

Does the encrypted packet just get broken into 1464 chucks and the ping command just does not know it because it is inside the encrypted packet? If so, should I set the tunnel to a lower MTU manually so that each individual encrypted packet will not get fragmented when sent? If so, how much overhead does OpenVPN have?

JaredBusch

Google tells me to set openvpn options to link-mtu 1472 for a normal ethernet line and thus I would think that I need to set it to 1468 for my pppoe example.

with the erl that would make the above OpenVPN seciton look like this.

openvpn vtun10 {
    description "Site A to Site B"
    local-address 10.204.9.2 {
    }
    local-port 1195
    mode site-to-site
    openvpn-option "--tun-mtu 1464"
    openvpn-option --comp-lzo
    remote-address 10.204.9.1
    remote-host vpn.domain.com
    remote-port 1195
    shared-secret-key-file /config/auth/xxxxxxxxxx
}

Doing that results in ping -c 1 -s 1436 -M do 10.204.1.1 being the largest unfragmented ping I can do through the tunnel.

JaredBusch

So someone tell me if I am off base or doing a good thing here.

scottalanmiller

Everything that you are doing sounds logical and makes sense to me. I'm pretty confident you are not going to hurt anything here. Will it help dramatically? No idea there. But I think it is likely to help without much risk. Seems like a good idea.