Messages

@meyergru
I block QUIC totally by blocking all UDP traffic on ports 80 and 443.

This is indeed a maintained source of DoH servers i use as well.
You also could add this rule to apply to TCP traffic on these ports only, since DoH uses TCP.

Thanks for the suggestion.
However, I don't have managed switches installed. All other networking equipment I have monitored for years without such behaviour.

Strangely nslookup of 94.16.122.152 resolves s7.vonderste.in.
Not known as a part of the ntp.pool, maybe just an NTP client.
Indeed this doesnt explain the source ip.

Update:
Just now a new request was made from 192.168.90.100:123 to a different destination ip: 217.144.138.234, which appears to be an NTP server: ntp2.wup-de.hosts.301-moved.de. Again i am unable to locate the source ip / host on my LAN. Maybe some WireShark is in order...

Hi,

Today i noticed that suspicious traffic from LAN -> WAN was blocked by Q-Feeds (thanks Q-feeds).
What i cannot understand is where this traffic originated from: 192.168.90.100 (port 123).
This should be impossible, since the DHCP range that i use is 192.168.1.0/24.
No fixed IPs are assigned.
ARP Table does not show the source IP (192.168.90.100).
Hostname of the source IP is empty.

The destination was 94.16.122.152 (port 123).
While this may look as ordinary NTP traffic, the destination IP does not appear an NTP server (no response).
Also, why would the originating IP address be out of the DHCP range?
And why would the destination IP be on a Q-Feeds blocklist?

Is this a spoofing attempt? Is this legit?
What am i missing?
How to find out which client this originated from?

As a mitigation and while i am figuring this out I have:
- Blocked the ASN for the destination address in F/W;
- Allowed only 192.168.1.0/24 and 224.0.0.0/8 out from LAN into F/W.

You are trying to reroute any LAN traffic to 172.16.200.1 but using the same desination port.
Are you sure this is correct? Is the TOR plugin listening on these ports?

Updated to 25.7.7_2 without a problem.
Thanks!

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! :)

[Solved] Great help from Deciso!

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?