PPPoE IPv4 IP Alias fails without dynamic peer on 26.7 (possible regression of #2112)

**Important notices** Before you add a new report, we ask you kindly to acknowledge the following: * [x] I have read the contributing guidelines 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 * [x] AI tools were used to create at least part of the text submitted herewith. If AI was used, please disclose: * Model used: OpenAI GPT-5.6 Sol * Extent of AI involvement: AI was used to help structure and phrase this bug report and to compare the observed behavior with existing OPNsense issues. The reproduction steps, command output and technical observations are based on live tests performed on the affected OPNsense system. The final report was reviewed by the reporter. **Describe the bug** On OPNsense 26.7, IPv4 Virtual IPs configured as **IP Alias** on a PPPoE WAN are not added correctly when the VIP Gateway field is left empty. The PPPoE connection itself comes up correctly. The dynamically negotiated PPPoE peer/gateway is available in `/tmp/pppoe0_router`, but the IPv4 IP Alias VIPs fail to appear on `pppoe0`. Adding exactly the same VIP manually with the currently negotiated PPPoE peer succeeds immediately. This appears very similar to the problem previously reported in #1415 and #2060 and addressed by PR #2112. PR #2112 specifically mentions that with PPPoE the gateway is not known in advance and therefore needs to be obtained dynamically from the gateway file. Last known working version: not independently tested. However, the historical PPPoE VIP fix was introduced years ago, so the current behavior on 26.7 may be a regression of that handling. **To Reproduce** Steps to reproduce the behavior: 1. Use a WAN interface configured with PPPoE and a dynamically negotiated PPPoE peer/gateway. 2. Go to **Interfaces / Virtual IPs / Settings**. 3. Add an additional routed public IPv4 address as: * Mode: `IP Alias` * Interface: `WAN` * Address: an additional routed IPv4 `/32` * Gateway: empty 4. Apply the configuration, reconnect PPPoE or reboot the firewall. 5. Check the PPPoE interface: ```sh ifconfig pppoe0 ``` The negotiated WAN IPv4 address is present, but the configured IPv4 IP Alias VIP is not. 6. Check the current PPPoE peer: ```sh cat /tmp/pppoe0_router ``` The dynamically negotiated PPPoE peer is correctly present in this file. 7. Manually add the same VIP while explicitly supplying that peer: ```sh /sbin/ifconfig pppoe0 inet <VIP>/32 alias <DYNAMIC-PPPOE-PEER> ``` This succeeds immediately. 8. Check the interface again: ```sh ifconfig pppoe0 ``` It then correctly contains both addresses: ```text inet <WAN-IP> --> <DYNAMIC-PPPOE-PEER> netmask 0xffffffff inet <VIP> --> <DYNAMIC-PPPOE-PEER> netmask 0xffffffff ``` The same behavior was observed with multiple routed IPv4 `/32` VIPs. **Expected behavior** When an IPv4 `IP Alias` is assigned to a PPPoE interface and no static VIP gateway is configured, OPNsense should automatically use the currently negotiated PPPoE peer when adding the address to the point-to-point interface. The PPPoE peer should not need to be hard-coded in the Virtual IP configuration because it is dynamically negotiated and may change after a reconnect. The resulting operation should effectively behave like: ```sh /sbin/ifconfig pppoe0 inet <VIP>/32 alias "$(cat /tmp/pppoe0_router)" ``` or otherwise obtain the current PPPoE peer internally before configuring the IPv4 alias. **Describe alternatives you considered** Manually supplying the current PPPoE peer works: ```sh /sbin/ifconfig pppoe0 inet <VIP>/32 alias <DYNAMIC-PPPOE-PEER> ``` Hard-coding that address in the Virtual IP Gateway field is not considered a safe workaround because the PPPoE peer is dynamically negotiated and may change. A local `newwanip` hook/script could also read `/tmp/pppoe0_router` and recreate the VIPs after every PPPoE connection, but this duplicates functionality that appears to have been handled by OPNsense historically in PR #2112. For that reason I would prefer to determine whether the existing PPPoE VIP handling has regressed before implementing a local workaround. **Screenshots** Not applicable at this time. **Relevant log files** During configuration/boot, the IPv4 aliases fail to be configured. Errors observed include: ```text ifconfig: netlink error: Empty IFA_LOCAL/IFA_ADDRESS ifconfig: ioctl (SIOCAIFADDR): Invalid argument ``` The PPPoE interface itself is up and healthy: ```text pppoe0: flags=<UP,POINTOPOINT,RUNNING,...> inet <WAN-IP> --> <DYNAMIC-PPPOE-PEER> netmask 0xffffffff ``` The same peer is available to OPNsense at runtime: ```sh # cat /tmp/pppoe0_router <DYNAMIC-PPPOE-PEER> ``` Manually using that peer when adding the VIP succeeds without an error. **Additional context** This appears closely related to the historical PPPoE Virtual IP issues: * #1415 — PPPoE Virtual IP/IP Alias does not get set-up properly * #2060 — Virtual IP Addresses (by PPPoE) * #2112 — PPPoE Virtual IP fix #2 The symptom in #1415 is particularly similar: adding an alias without the PPPoE destination/peer failed, while explicitly supplying the peer to `ifconfig` succeeded. PR #2112 states that the PPPoE gateway is not known in advance and that the gateway should therefore be obtained from the gateway file when configuring IPv4 VIPs. The current OPNsense 26.7 system still has the dynamically negotiated peer available in `/tmp/pppoe0_router`, and using that exact value manually makes the VIP work. **Environment** OPNsense 26.7 WAN type: PPPoE Interface: `pppoe0` IPv4 WAN address: dynamically negotiated `/32` PPPoE peer/gateway: dynamically negotiated Additional public IPv4 addresses: routed `/32` addresses configured as `IP Alias` VIPs VIP Gateway field: empty