pfSense

Summary¶

There is currently no supported migration path for existing PPPoE High Availability deployments from the legacy MPD (mpd5) backend to the new if_pppoe backend.

This is a problem because if_pppoe is intended to replace the current MPD-based PPPoE implementation, but an HA installation in which CARP state determines which firewall establishes the PPPoE session cannot migrate to if_pppoe without losing automatic PPPoE failover.

This request is related to #16174, but the scope is different.

Issue #16174 requests support for using a CARP VIP directly as the if_pppoe parent interface.

This issue requests a supported PPPoE HA migration mechanism, regardless of whether that is implemented by supporting a CARP VIP as the PPPoE parent or by another mechanism.

Current production setup¶

We operate two pfSense nodes as an HA pair using CARP.

There are two independent PPPoE WAN connections:

• PPPoE connection 1: DSL
• PPPoE connection 2: FTTH

Each PPPoE connection has a dedicated Ethernet transport network between the pfSense HA pair and the corresponding provider equipment.

The transport interfaces themselves use static IP configuration. A CARP VIP is configured on each static transport network and is used as the PPPoE parent with the legacy MPD backend.

The CARP VIP is therefore not configured on the dynamic PPPoE interface itself. CARP operates on the static Ethernet transport interface below PPPoE.

Example architecture:

                  PPPoE Provider
                        |
                Ethernet Transport
                        |
                 Static L2/L3 Network
                        |
                     CARP VIP
                    /         \
               pfSense 1    pfSense 2
                 MASTER       BACKUP

With the legacy MPD backend, the PPPoE session is established by the active CARP MASTER node.

When CARP fails over, the former MASTER no longer owns the CARP VIP and the new MASTER can establish the PPPoE session.

As a result, PPPoE connectivity follows the active firewall.

Behaviour with mpd5¶

The existing MPD implementation handles a configured CARP VIP used as a PPPoE parent specially.

When the configured PPPoE parent references a _vip interface, pfSense checks the CARP state.

If the local node is not MASTER for that VIP, the interface is skipped.

If the local node is MASTER, pfSense resolves the CARP VIP to the underlying real Ethernet interface and establishes PPPoE using that interface.

This effectively ties PPPoE operation to CARP state and allows PPPoE connectivity to follow an HA failover.

Behaviour with if_pppoe¶

With if_pppoe, the CARP VIP cannot be used in the same way.

The configured PPPoE parent is passed to the kernel PPPoE implementation as the PPPoE device.

A CARP VIP is not a usable Ethernet parent device for if_pppoe, so the PPPoE interface cannot be established correctly when the CARP VIP is selected as its parent.

Selecting the underlying real Ethernet interface allows if_pppoe to use a valid parent device, but this removes the existing dependency between CARP state and PPPoE operation.

There is currently no equivalent supported mechanism which tells pfSense:

CARP MASTER  -> Start / establish PPPoE
CARP BACKUP  -> Stop PPPoE / keep PPPoE down

Migration problem¶

The pfSense documentation states that if_pppoe is intended to replace the current MPD-based PPPoE implementation.

For this HA configuration, migration is currently impossible without removing working automatic PPPoE failover.

There is no supported mechanism available today which preserves the existing CARP-controlled PPPoE HA behaviour when switching to if_pppoe.

Consequently, we cannot switch the installation completely to if_pppoe and disable the legacy MPD PPPoE backend while retaining the existing HA functionality.

Keeping the legacy MPD backend enabled indefinitely is not a desirable migration strategy when if_pppoe is intended to replace it.

Expected result¶

pfSense must provide a supported solution for PPPoE High Availability with CARP when using if_pppoe.

This is not merely a request to support a specific legacy configuration or to preserve the ability to select a CARP VIP as the PPPoE parent.

The actual requirement is that a pfSense HA pair must have an officially supported way to ensure that only the active CARP MASTER establishes the PPPoE session, while the BACKUP node keeps the PPPoE session down and is able to establish it after a CARP failover.

For example:

CARP MASTER:
    establish / bring up PPPoE

CARP BACKUP / INIT:
    terminate PPPoE or keep PPPoE down

CARP failover:
    old MASTER stops PPPoE
    new MASTER establishes PPPoE

Whether this is implemented by supporting a CARP VIP as the PPPoE parent, by binding if_pppoe to the real Ethernet transport interface and reacting to CARP state changes, or by another mechanism is an implementation detail.

What matters is that PPPoE HA with CARP must remain possible and supported when migrating from MPD to if_pppoe.

At present, there is no equivalent supported HA mechanism with if_pppoe.

This creates a clear migration blocker: administrators with working PPPoE HA deployments are currently forced to keep the legacy MPD PPPoE backend enabled because switching to if_pppoe removes the existing CARP-controlled PPPoE failover functionality.

Before the legacy MPD PPPoE backend is removed, disabled by default, or becomes unsupported, pfSense must provide a supported migration path for PPPoE HA deployments so that existing CARP-based HA functionality is not lost.

This gap should be resolved as part of the transition from MPD to if_pppoe, rather than leaving existing HA installations permanently dependent on a legacy backend.

A replacement backend should not remove an existing HA capability without providing an officially supported replacement.

Steps to reproduce¶

1. Configure two pfSense systems as a CARP HA pair.

1. Configure a static Ethernet transport network on both nodes.

1. Create a CARP VIP on this static transport network.

1. Configure a PPPoE connection using the CARP VIP as its parent.

1. Use the legacy MPD (mpd5) PPPoE backend.

1. Verify that PPPoE is established on the CARP MASTER.

1. Trigger a CARP failover and verify that PPPoE connectivity follows the new MASTER.

1. Enable Use if_pppoe kernel module for PPPoE client and reboot as required.

1. Verify that the PPPoE connection can no longer use the CARP VIP successfully as its parent.

1. Select the underlying Ethernet transport interface and verify that it provides a valid if_pppoe parent, but that the CARP-controlled PPPoE HA behaviour is lost.

Impact¶

This is a blocking issue for migration from MPD to if_pppoe in environments using CARP-based PPPoE High Availability.

Our current HA deployment uses two independent PPPoE WAN connections, DSL and FTTH, and both rely on CARP state to determine which firewall establishes the PPPoE connection.

The existing configuration works with MPD.

We want to migrate to if_pppoe and completely disable the legacy MPD PPPoE backend.

We currently cannot do so because pfSense does not provide an equivalent supported PPPoE HA mechanism with if_pppoe.

At present, administrators using this type of HA deployment are effectively required to keep the legacy MPD backend enabled because no equivalent supported HA solution exists with if_pppoe.

Therefore, this is not only a request for an additional feature. It is a missing migration capability required to replace the legacy MPD backend in PPPoE HA environments.

Please provide a supported solution for CARP + PPPoE + HA with if_pppoe before MPD support is removed or becomes unsupported.

Related issue¶

Related ticket: #16174 - CARP VIP support for if_pppoe

We understand the comment in #16174 stating that CARP and HA are only supported on static interfaces and not on dynamic interfaces.

In the setup described here, however, the CARP VIP itself is configured on a static Ethernet transport interface. CARP is not configured on the dynamic PPPoE interface.

The dynamic PPPoE interface uses the CARP VIP on the static transport network as its parent with the legacy MPD implementation.

This request therefore does not require CARP to operate directly on a dynamic PPPoE interface.

What is required is a supported mechanism for coordinating an if_pppoe session with the HA/CARP state of the firewall so that existing PPPoE HA installations can migrate away from MPD without losing automatic failover.

The required outcome is clear:

CARP + PPPoE + HA must have a supported migration path to if_pppoe.

Existing HA deployments should not be forced to remain permanently on the legacy MPD backend because the replacement backend does not yet provide equivalent HA functionality.