Messages

I tend to agree that the scope isn't correct, but I would extend this to the whole use of the link-local of what is likely the WAN interface which the clients can never reach from a configured LAN.

I'm not sure where that DNS server comes from? It also doesn't usually happen otherwise it would have been fixed quite a while ago.



Cheers,
Franco

This is the link local on the WAN interface fe80::82ee:73ff:fee2:6622/64 alongside with my global IPv6 address.
As this entry is related to recursive DNS, it might be related that I'm running unboundDNS on my FW?

Franco,

not sure where I have a mistake in my setup. I think it could give out SLAAC on WAN, as there is a virtual interface pppoe (which holds the actual v6 address) and the WAN physical interface (just a thought).

But how can I troubleshoot this, and why is RA generating config for the WAN interface at all?

Happy to share more configuration if this helps, but currently I'm a bit clueless where to start.

Best
Alexander

[%pppoe0]

Hi

I'm running Opnsense 25.7.1_1 with DSL pppoe termination on my WAN interface.
I do receive my IPv4 using pppoe and IPv6 using DHCPv6.
I configured my LAN (multiple) interfaces with static /64 networks out of my delegated prefix.

When configuring my Service-> Router Advertisements [interface] I can't start the Service anymore.
The logs show:

Code Select Expand

/usr/local/sbin/pluginctl: The command '/usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog' returned exit code '1', the output was '/var/etc/radvd.conf:36 error: syntax error'

The line in the config file creating the problem seems to be RDNSS which includes the suffix %pppoe0:

Code Select Expand

interface pppoe0 {
        ...
        ...
    RDNSS fe80::82ee:73ff:fee2:6622%pppoe0 {
    };
        ...
        ...
};

I can manually modify and start the service from CLI. So everything is working then, but just not from the UI.

Is that a config issue on my side or is the generation fo the config file broken?

Best
Alexander

[aa]

I have exactly the same issue and tried multiple options to resolve this, none of them worked  :(

However, I had the following observation:

Hosts which are only defined in unbound (so no A/CNAME in the public DNS) do work
; <<>> DiG 9.10.6 <<>> localonly.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: xxxx
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

Hosts which are defined in unbound and in the public DNS (w/ A or CNAME in the public DNS) do NOT work.
The difference I see is in the number of ANSWER, which seems like unbound is passing the public answer to the client instead of an overwrite
; <<>> DiG 9.10.6 <<>> localnpublic.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: xxxxx
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

Dear Sensei users,

An update on broken Elasticsearch indices:

After digging together with users who have reported the issue, it looks like the indices were broken because some index file integrity got broken.

This is usually because of abrupt shutdown of the firewall. If power goes off suddenly, before Elastic does a full write of its in-memory buffers, than we have a broken index.

So, not to experience this issue try to turn off your system gracefully.

If in any case this happens, Sensei 0.8.0.beta6 has a "Fix Elastic indices" button under Sensei -> Configuration -> Reporting & Data menu. Just click on the button and Sensei will reset only the broken indices.

0.8.0.beta6 is available for update for 0.8 users.

0.8 looks stable enough to offer as an update for existing 0.7 installations. If we do not see any outstanding issues, we'll move 0.8 to the general repo in a few days.

I just had a power outage on my opnsense, after the reboot the reports could not be displayed. The "Fix Indices" shows all good, but the report still does not show up. I still have the system in a "broken" state if you want to investigate further...

OpnSense 19.1.4
Sensei 0.8beta6

Hi,

I just installed Sensei on my OPNsense and I think it's working great.
I found in the dashboard an interesting "HotSpot" I'd like to investigate further. However, the "Top Destinations Locations Heatmap" does not allow for a Drill Down, nor is there a geo location filter available.

Can you please advise on how to investigate on such hotspots?
Is it possible to retrieve DNS/IP for a certain geo location hotspot?

Regards
Alexander

Is there an update on this?
I try a fresh install with a i7-8700 CPU/Shuttle XV310 and see the same kernel panic.
The suggested boot options did not help

Edit:
This is a fresh install on a pyhsical device - no hypervisor involved.
But it is the exact same kernel panic.

Any advise?

I have the same problem now - we're you able to solve this?