CARP and Proxy ARP are not acceptable virtual IP types for PPPoE interfaces

[doktornotor]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

The PPPoE VIPs apparently were implemented in https://github.com/opnsense/core/issues/2060 -- however the only usable VIP type for PPPoE is IP Alias (with the GW specified, or "guessed" as done for #2060). I'm not sure what amount of validation / "shoot yourself in the foot" prevention you aim for here, but options that have no chance of working probably should not be offered to users.

To Reproduce

Steps to reproduce the behavior:

1. Go to 'Interfaces - Virtual IPs - Settings'
2. Click on '+'
3. Select 'CARP' or 'Proxy ARP' in 'Mode'
4. PPPoE interfaces are available for selection in 'Interface' dropdown.

Expected behavior

PPPoE interfaces should not be available in 'Interface' dropdown for anything but "IP Alias".

Relevant log files

CARP

# ifconfig pppoe0 inet 192.0.2.123/32 alias vhid 10
ifconfig: SIOCGVH: Operation not supported

Proxy ARP

# choparp pppoe0 auto 192.0.2.123/32
pppoe0: not found

Additional context

Semi-related forum thread

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 23.7.8 (amd64).

[fichtner]

My question is why are they wedging these things to the ISP side... or are they hoping they would end up set on the parent device?

Cheers, Franco

[doktornotor]

Lol, well... no idea. I cannot meaningfully test this scenario with /32 provided and anything else costing much more money than the 250Mbit VDSL line itself. I linked the thread, so probably better discussed there, I filed this bug only for the VIP types that just cannot work at all.

[fichtner]

I'll ask in the forum although I agree that these should ideally be blocked when they cannot work. What's a bit harder is enforcing them when the WAN switches assignments between PPP and non-PPP. We will see. Thanks for the pointer.

Cheers, Franco

[ecraven]

Might I suggest also thinking about making the gateway mandatory in this case (unless the correct one is auto-detected, which does not seem to work right now). Thanks for looking into it!

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.

[fichtner]

I'll pick it up, thanks for the pointer.