Messages

I just ran into that microcode issue. I have two (almost) identical devices, TK Edge 4L and TK Edge4Go¹, both Intel Celeron J3455. The Edge 4L is affected by this issue, TK Edge4Go is not. Should I remove os-cpu-microcode-intel from the working Edge4Go, too?
Why is one affected, the other not?


1) https://www.thomas-krenn.com/de/produkte/low-energy-systeme

Code Select Expand

kenv smbios.bios.vendor: American Megatrends Inc./Advantech
kenv smbios.bios.version: T011G206
kenv smbios.bios.reldate: 04/18/2023
sysctl hw.model: hw.model: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz

Thank you Cedrik, took some time to sink in, but sounds reasonable to me. It's quite a bit different from what I had in mind. Let's see how I can sell this concept to my customers IT guy.

Reading the man pages is a good idea, I wrote them :)

Someone is reading it, now you know!

Edit:
One more thing! I know, this question will come, even if a bit off topic: Switching from a classical segmented IP filter (vulgo: firewall) setup to a host based filter, any idea, if and how this impacts overall performance? This is no a huge setup, but has ~200-300 hosts IPs per interface.

The magic in a HA environment is that both OPNsense learn the same on link /64 prefix from the RAs sent by the Fritzbox...

I'm not getting it: Shouldn't I the get the /58 prefix at the OPNsense and slice it up into /64 there? Reading the documentation, I do not see, how these parts (Track Interface vs. ndp-proxy) fit together. This is more a question, if I really want this, not how to do it, I love reading man pages :-)

This is the os-ndp-proxy-go plugin? Do I need the os-ndproxy, too?

G'day everyone.

I am running an OPNsense HA setup (CARP) with two nodes:

- opnsense-alpha
- opnsense-beta

Both are connected to the same upstream router, a FRITZ!Box, which receives an IPv6 prefix from the ISP.

_Upstream situation_

Both OPNsense nodes are connected to the same L2 segment (WAN side). The Fritz!Box receives a delegated prefix from the ISP:

2001:9e8:1484:3080::/58


_Observed behavior_

Each OPNsense node independently requests DHCPv6 Prefix Delegation. However, the Fritz!Box assigns different delegated prefixes to each node:

- opnsense-alpha: 2001:9e8:1484:3080::/58
- opnsense-beta:  2001:9e8:1484:30c0::/58

As a result, the tracked internal networks differ:

    alpha:
        LAN: 2001:9e8:1484:3081::/64
        DMZ: 2001:9e8:1484:3082::/64

    beta:
        LAN: 2001:9e8:1484:30c1::/64
        DMZ: 2001:9e8:1484:30c2::/64

_Problem_

This leads to a fundamental issue:
- The two HA nodes do not share the same IPv6 prefixes
- Internal networks differ depending on which node is active
- CARP failover results in a different IPv6 network for clients

This not just breaks the expectation of transparent failover, but also confuses v6 servers (and may be even clients?) running in a the DMZ.

_Question_

Is this expected behavior with DHCPv6-PD in an HA setup?

More specifically, is there any supported way in OPNsense to achieve consistent IPv6 prefixes across HA nodes when using DHCPv6-PD? Or is this fundamentally incompatible unless:
- a static routed prefix is used, or
- only one node performs DHCPv6-PD?

_Additional notes_
WAN connectivity and PD itself work fine on both nodes. Issue only appears when combining CARP, Track Interface and DHCPv6-PD from a consumer router (Fritz!Box). This is not about broken IPv6 connectivity, but about design limitations of DHCPv6-PD in HA scenarios.

Any guidance or recommended architecture would be appreciated, thank you!

G'day members,

today I wanted to change my user password in a shell using passwd(5). I got
~~~
[user@OPNsense ~]$ passwd  -l
Changing local password for user
Old Password:
passwd: sorry
~~~
I'm pretty sure, the password is correct, because it works with sudo. What did I miss?