Messages

Indeed may seem pretty 'fringe' haha.
Im not understanding everything, but the things i do get and agree with i have implemented.
My goal is to see how this works for some time.

I'm especially fascinated by replacing the suffix of the IPv6 address for all devices on LAN by some random address using Outbound NAT.
For now i have created ~20 random suffixes and loaded these in an alias. These are used round-robin (sticky).
Since i have a fixed IPv6 prefix, i don't need to worry about that changing. I plan to rotate these random suffixes regularly, but would love to see a more automatic solution.

Thanks Millerwissen for your time and ideas.

Thanks. I didnt express myself clearly which is important with these complicated matters ;)
So far the following is updated and working:

- Created virtual IPv6 address f777::1 instead of fd07::1 to prevent IPv4 preference as described in your first post.
- Setup of NAT66 to translate all routable addresses of LAN devices (other than the servers) to a virtual IPv6 routable address based on /64 prefix from ISP. Suffix is not based on a MAC address. Does it matter what suffix i choose? Just the first address in the range (::1) or last or aything?
I think it would be good to regularly rotate the address. Is there a way to do this automatically?
- Setup of floating FW block rules for the f000/4 address space.

I plan to see how this works for a while.
PS: Please explain why traffic to multicast addresses like ff::/8 need to be allowed to WAN as in your example. These addresses are normally not forwarded to WAN.

Hi Millerwissen,

Thanks for your extensive information!
My ISP issues just a /64 prefix by DHCPv6 on WAN and suffix is derived from MAC addresses by SLAAC on LAN.
This means that each of my servers exposed to WAN has a unique, routable address. This is desirable since it means that the IPv6 addresses are predictable and fixed, but not ideal.

But it also means that other devices (i'm talking about other devices than the servers) are exposed using the RA.
Therefore they could be tracked across the internet. Does it make sense to translate these addresses at the Opnsense router using your (no. 3) method?
Also i would like to improve network segregation using your approach. On the other hand i dont want to "mess up" my network.

I have already changed any ULA addresses i use from fd::/8 to f000::/4. But since this this range is not considered "bogon", i still need to add firewall rules for blocking f000::/4 out from WAN.

Hi, just purchased a Plus License for 1 yr because i have confidence in your product and want to support your great efforts.

@franco
Awesome! Looking forward to your mail.
You just made my day! :)

Hi All,

Today a very sad thing happened during the BIOS update of my dec3850: a sudden power loss.
This interrupted the update process and "bricked" the device. No POST after restart :( :(

While we have no support contract in place (just a private / non-profit organisation) I sent an email to Deciso to check what (if anything) can be done.
I hope the dec3850 can be recovered.
If anyone has an idea here on how to revive it this would be very welcome.

I can see the same behavior when selecting "Lookup hostnames". This has been a problem for me since March 2025.
However, since last update (25.7.6) the auto-refresh is very slow. this used to be quick, even with hundreds of lines per second.
What can cause this? Something changed in FW backend or is there something else?

@mimugmail
Do you have any valuable input or ideas regarding this?

Thanks all!
I created a new virtual IPv6 and IPv4 address (to which services are automatically bound) and referred requests there.

Another item i am wondering about is changes to chrony.conf.
Manual changes (e.g. ratelimit, prefer option etc) do not appear to be persistent. Every reboot resets the configuration to default again.
And the GUI does not provide a method to set those. What am i doing wrong?

Thanks, i realise i have not been specific enough.
A ping request from LAN via FQDN results in a RA, so address resolution appears to work fine.
Only pinging this routable address (which points to a virtual IPv6 address on LAN) does not work (Destination host unreachable).
This is strange, because ping requests from LAN to other RA's on the same LAN (non-virtual addresses) are successful.

It gets stranger, because ping requests which originate from WAN are not answered by any of the virtual or non-virtual RA's.
If i add FW rule to allow for echo requests to pass to these RA's these pings from WAN are successful.

So, this still appears to be a local problem where FQDNs are successfully resolved, pings to non-virtual addresses are succesful, but pings to virtual addresses result in "Destination host unreachable".
I have tried to activate "Reflection for port forwards", "Reflection for 1:1" and "Automatic outbound NAT for Reflection". No success.
Ideas?

@meyergru: could you please be a little more specific? I tried both options on and off and it didnt seem to make much difference. Should i restart maybe?
PS: @Patrick I did change the local domain name to something different.

Hi All,

I have a few virtual IP addresses on the WAN interface which are exposed to the internet via FDQNs and can be reached by external clients fine thourgh the FDQNs as well as through their IP address.

However, these virtual IPs are not reacheable (pingable) from within the LAN itself. Whenever a client within the LAN requests Unbound to resolve the FDQNs the response is NXDOMAIN.
This appears to be related to virtual addresses only, because non-virtual addresses exposed to the internet via FDQNs can be reached by ping from within the LAN network fine.

I've tried various settings in firewall, Unbound and DNSMasq (DHCP), but I can't seem to get it to work. What am i missing?

Kets

That would be a list of more than 2,300 sources and it's still growing. It's not purely OSINT, and it also includes our own proprietary sources, such as data from our honeypots. The real value is in the work we've already done, filtering out false positives and prioritizing the data. Simply adding raw OSINT feeds often leads to tons of false positives and unnecessary IOCs clogging your memory.

I used to block via freely available lists and now that I activated your plugin I put that "block based on free lists" rule after the Q-Feeds one.

Result: for 100 blocked connections 72 are caught by Q-Feeds and still 28 by the free lists.

My free lists are:

FireHOL1
FireHOL2
FireHOL3
Spamhaus DROP
Spamhaus DROP6
Herr Bischoff's IP blocklist (https://ipbl.herrbischoff.com/list.txt)

Surprised at least FireHOL and Spamhaus are apparently not included in your feed?

Kind regards,
Patrick

P.S. I can send you a list of addresses if you want to investigate. And of course these numbers vary a bit over time, but roughly 25-30% make it past your feeed and are caught by my other block lists.

I also noticed the same thing. Can assist if needed.

While i don't have similar problems, first thoughts are its either one of the following:
- Bad/marginal cable. Replace some cables to see if it helps.
- Loss of ICMP / ICMPv6 packets at the WAN interface, similar to what is discussed in this topic: https://forum.opnsense.org/index.php?topic=46990.0
You could try the suggested solutions.

Just updated the plugin. Looks like its working fine. Will keep an eye on it.

2x GPS and 1x DCF77

Reconciliation of multiple sources is an interesting subject.

Are both GPS receivers using same GPS service?

GPS (receiver) is accurate to approx 100ns. Is the DCF77 broadcast any better?

Yes, both GPS sources are professional NTP appliances from Meinberg. DCF77 is not more accurate than GPS however, but I wanted some diversity in the time sources.
for example in case GPS reception is disturbed.
When bought these are quite expensive, but they are regularly offered on Ebay for a few hundred USD/EUR. Support from Meinberg is excellent. They still offer firmware updates for many of their NTP appliances, even many years after production. Highly recommended.