PPPoE Virtual IP/IP Alias does not get set-up properly

[syserr0r]

On all my PPPoE connections that should have 6 addresses (in the case of the below connection it should have .49 .50 .51 .52 .53 and .54) only the negotiated IP address is set-up. It appears this hasn't been a big problem because my ISP shoves all traffic for all IPs down the PPPoE link, but it means I can't bind a daemon to one of the IP Aliases (as I am trying to do with HAProxy). It also causes errors in the system log. There may be other implications.

ifconfig shows:

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet6 fe80::xxx:xxxx:xxxx:xxxx%pppoe0 prefixlen 64 scopeid 0x8
        inet6 2a02:390:feed:xxxx:xxx:x:xxxx:xxxx prefixlen 64 autoconf
        inet xx.xx.xx.49 --> 212.69.63.39  netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

In addition, System > Log File shows lots of lines like:
opnsense: /usr/local/etc/rc.newwanip: The command '/sbin/ifconfig 'pppoe0' inet 'xx.xx.xx.50'/'29' alias' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Destination address required'

Entering a shell and running: /sbin/ifconfig pppoe0 inet xx.xx.xx.50/29 alias produces: ifconfig: ioctl (SIOCAIFADDR): Destination address required

However, running the command and specifying the gateway (other end of the pppoe link) adds the address to the pppoe0 interface properly:
/sbin/ifconfig pppoe0 inet xx.xx.xx.50/29 alias 212.69.63.39

Producing:

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        inet6 fe80::xxx:xxxx:xxxx:xxxx%pppoe0 prefixlen 64 scopeid 0x8
        inet6 2a02:390:feed:xxxx:xxx:x:xxxx:xxxx prefixlen 64 autoconf
        inet xx.xx.xx.49 --> 212.69.63.39  netmask 0xffffffff
        inet xx.xx.xx.50 --> 212.69.63.39  netmask 0xfffffff8
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

[syserr0r]

Running OPNsense 17.7, my PPPoE connection still does not have all the IP aliases added to it -- is this resolved another way (as I notice the log file no longer has all the 'Destination address required' log entries?