Hi all, I did a single configuration change, adding a Virtual IPv6 address to my LAN to create an ULA, and the OPNsense did not boot anymore (tried with 23.1_6 and 23.1.1_2).
The configuration diff is as simple as
2010,2011c2025,2039
< <virtualip>
< <vip/>
---
> <virtualip version="1.0.0">
> <vip uuid="fa820ff4-41b4-4c9a-8595-8373a45fef7d">
> <interface>lan</interface>
> <mode>ipalias</mode>
> <subnet>fd80:0192:0168:0001:2a1:ecff:fe68:f1c0</subnet>
> <subnet_bits>64</subnet_bits>
> <gateway/>
> <noexpand>0</noexpand>
> <nobind>0</nobind>
> <password/>
> <vhid/>
> <advbase>1</advbase>
> <advskew>0</advskew>
> <descr>ULA LAN</descr>
> </vip>
This results in the Enter full pathname of shell or RETURN for /bin/sh at boot directly after Setting up routes...done. and before Setting up DHCPv4 and Setting up DHCPv6. This was reproducible every time and was not a one-time timing hickup.
Luckily I have virtualized the OPNsense on Proxmox VE, so I just reverted to the last snapshot.
I then learnt that I used a stupid address for ULA and changed it to a randomly generated one and now OPNsense boots again. The only change in the diff is really the <subnet>...</subnet> of the <virtualip>.
Even if I used a stupid virtual IPv6 address, I think, OPNsense should not refuse to boot?
At the very least there should be validation of whether the address entered is RFC compliant.
But there is a check for valid IPs?
@sbellon: What exactly did you enter that was accepted but still prevented booting?
@meyergru: See my initial posting?
I thought that was the address that worked afterwards.
fd80:0192:0168:0001:2a1:ecff:fe68:f1c0 is a perfectly legal ULA, I do not see why this should not work. Also, for an IP alias, you could use almost any IPv6, so the IPv6 validity check that is applied in the web UI should suffice.
It was reproducible that booting with that Virtual IP resulted in the screenshot attached to my first post. I changed literally only the address to a randomly generated fd01:6da2:3e56:1/64 ULA prefix and now it boots again:
2029c2029
< <subnet>fd80:0192:0168:0001:2a1:ecff:fe68:f1c0</subnet>
---
> <subnet>fd01:6da2:3e56:0001:2a1:ecff:fe68:f1c0</subnet>
I am still at a complete loss as to why this should happen, unless there is some special conflict with other settings on your box. I just tried just the same VIP and everything works as expected.