The MTU setting is well described "max-mtu", i.e. a lower one can be negotiated.
Can you capture the LCP stage of PPP negotiation from either the client or server, it sounds like it's negotiating a smaller one for some reason.

Also I'd expect something is wrong on the client side, can you see the PPP config options the Teltonika is using?

On server, what is in /var/run/accel-pppd/l2tp.conf ?
The setting should read ppp-max-mtu=1454 under l2tp section

vyos@oobm:~$ cat  /var/run/accel-pppd/l2tp.conf
### generated by accel_l2tp.py ###
[modules]
log_syslog
l2tp
chap-secrets
auth_mschap_v2


ippool
shaper
ipv6pool
ipv6_nd
ipv6_dhcp

[core]
thread-count=1

[log]
syslog=accel-l2tp,daemon
copy=1
level=5




[l2tp]
verbose=1
ifname=l2tp%d
ppp-max-mtu=1450
mppe=prefer
bind=89.145.160.86

[client-ip-range]
0.0.0.0/0

[ip-pool]
192.168.255.1-254
gw-ip-address=192.168.255.1

[chap-secrets]
chap-secrets=/run/accel-pppd/l2tp.chap-secrets
gw-ip-address=192.168.255.1

[ppp]
verbose=1
check-ip=1
single-session=replace
lcp-echo-timeout=0
lcp-echo-interval=30
lcp-echo-failure=3

PCAP from VyOS will be enough?

So we have configured option max-mtu this means

ppp-max-mtu=n
Set the maximum MTU value that can be negotiated for PPP over L2TP sessions.

But I think we need to provide possibility set min-mtu

[ppp]
min-mtu=n

Minimum acceptable MTU. If client will try to negotiate less than the specified MTU then it will be NAKed or disconnected if rejects greater MTU.

The config you posted has the following which is not correct, it should read 1454.
ppp-max-mtu=1450

On the server, do you have the following
set vpn l2tp remote-access mtu 1454

If so could you post output of
show vpn l2tp

The default in code is 1436 - so I really don't understand how the value of 1450 has got there unless there is a problem generating the file at /var/run/accel-pppd/l2tp.conf and it isn't being re-written.

Could confirm it is being re-written (check timestamp of l2tp.conf file) if you make a modification to the l2tp settings?

Also, your client should still not end up with 1454 set.
On our system, we have mtu set to 1500, and various clients appear to negotiate both 1500 and 1492 settings successfully via LCP stage of ppp.

A Pcap from the server should shed some light as to whether it is being negotiated or not (I think it might not be getting negotiated).

I've just realised, if you look in /var/log/messages you should see the LCP negotiation of MRU (i.e. the agreed MTU)

Seems both sides negotiating at 1450... but Linux interface gets 4 bytes less.

Hello.
Do you need something else?

Line 478 and 479 seem to be the important ones here.
The MRU of 1450 appears to be correctly negotiated. i.e. Vyos is setting the remote side to a maximum of 1450 bytes, because that is what the remote side requested!

If you want it to be 1454, the remote side should be requesting 1454.
On the Vyos side the MTU is MAXIMUM transmission unit it is configured to support, if the remote side wants to negotiate less, then Vyos will give it less. This is by design of PPP protocol.
Vyos (and any other PPP server I've come across) expects the client to ask for the largest possible MTU first, then negotiate downwards if one of the sides can't go that high.

It looks to me like this is a problem with the remote side not correctly requesting 1454, if it did then there wouldn't be a problem.

Either you haven't configured the remote side correctly, or it has a bug.

To me Vyos appears to be behaving correctly and as designed.

p.s. 478 and 479 referred to qmimux0.pcap