Summary:

vpn pptp remote-access ppp-options mppe {require|prefer|deny} has no effect — PPTP client connections are always negotiated with accel-ppp's permissive default (MPPE_UNSET) regardless of what's configured. Security-relevant: an administrator who sets mppe require to reject unencrypted PPTP clients gets no such enforcement.

What were you attempting to achieve?

Require MPPE encryption for all PPTP remote-access VPN clients, rejecting any client that doesn't support/request it.

Configuration used

set vpn pptp remote-access authentication mode local
set vpn pptp remote-access authentication local-users username test password test
set vpn pptp remote-access client-ip-pool subnet 192.0.2.0/24
set vpn pptp remote-access ppp-options mppe require
commit

What did you expect to happen?

accel-ppp's PPTP module should reject any client connection that doesn't negotiate MPPE encryption.

What actually happens

The generated /run/accel-pppd/pptp.conf contains mppe= (empty) in its [pptp] section. Per accel-ppp's own source (see root cause below), an empty/unrecognized value there leaves conf_mppe at MPPE_UNSET — the PPTP module's actual runtime default, "don't ask client for mppe but allow it if client wants." The administrator's require setting is silently never applied; unencrypted PPTP clients continue to be accepted. There is no error at commit time or in the logs.

Verify with:

sudo cat /run/accel-pppd/pptp.conf | grep -A2 '^\[pptp\]'
— the mppe= line under [pptp] will be empty regardless of the configured value. (A different, correctly-populated mppe=require line will also be present further down under the file's common [ppp] section — see root cause below for why that doesn't help)

Root cause

data/templates/accel-ppp/pptp.config.j2:48 renders mppe={{ authentication.mppe }}, but mppe is defined via ppp-options.xml.i, a sibling of the authentication node in interface-definitions/vpn_pptp.xml.in, not nested inside it — so the config dict's mppe value is at ppp_options.mppe, never authentication.mppe. The sibling l2tp.config.j2:45 uses the correct path for the identical schema shape, confirming this is a copy/refactor slip specific to PPTP.

This isn't masked by the correctly-rendered [ppp]-section mppe= line (from the separately-included ppp-options.j2) — checked directly against accel-ppp's accel-pppd/ctrl/pptp/pptp.c (load_config()): the PPTP control module reads mppe from the [pptp] section only, assigns it straight to conn->ctrl.mppe, with no fallback to or merge with [ppp].

Environment

VyOS version: rolling (verified by direct source inspection of the rolling branch, not tied to a specific dated build)
Affects PPTP remote-access VPN specifically; L2TP's equivalent template already uses the correct path

Prior art (checked on vyos.dev before filing)

No existing task or PR describes this bug. Searched vyos.dev for "pptp" and "mppe", and the vyos/vyos-1x GitHub PRs for "pptp mppe" and "mppe". Nothing matched, and all the related items are closed:

T833 (closed) — the original move of the PPTP server to accel-ppp; it planned mppe as a config option defaulting to require.
T1946 (closed) — PPTP interface name recovery; unrelated.
T2829 (closed) — PPPoE server mppe defined as a node instead of a leaf; a different service and a different bug.
vyos-1x#2891 (T5971, merged) and vyos-1x#2658 (T5801, merged) — rewrites of the ppp-options handling and the L2TP service; neither describes this issue.