@JonathanLee Interesting. What we're living through now is the partial realization of what I somewhat mistakenly believed Web 3.0's 'semantic web' concept from a quarter-century ago was all about. I.e., tell the 'search engine' what you're looking for in natural human language, and it will deliver. Berners-Lee originally expressed his vision of the Semantic Web in 1999 as follows: I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A "Semantic Web", which makes this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The "intelligent agents" people have touted for ages will finally materialize.

@JonathanLee said in Seeking Insight on IPV6 Suricata Alerts – "Excessive Retransmissions" and "Wrong Direction First Data": SURICATA Applayer Wrong direction first Data Here is the link in the Suricata docs for this stream rule alert: https://docs.suricata.io/en/latest/rules/app-layer.html#applayer-wrong-direction-first-data. The short version of the story is that even today, after several attempted fixes within Suricata, the coders of client/server software apps seem to still be able via crappy coding to craft network flows that trip up the Suricata parser. This is basically a harmless error. As @SteveITS said, the best thing is to disable all the Suricata stream event rules. They are informational anyway and don't necessarily indicate malicious traffic.

@SteveITS It looks like it is detecting ipv6 better already is showing alerts [image: 1752342154032-screenshot-2025-07-12-at-10.39.56-resized.png] It sees some ipv6 going to my interface. Again snort also would spot stuff every once a a while. My son got a bad bug on his tablet and it had a Russian email server running I checked it on virus total and it was spot on as malware known abuses so I reported it

@johnpoz This even does this with the newest CE edition inside of UTM virtualized environment outside of the 2100s [image: 1752772658328-screenshot-2025-07-17-at-10.15.51-resized.png] It is not just the 2100s this is set up for standard stuff everything else works with it just the status page

@Gertjan Fixed it. I had on the interface address both an IPv6 address and an "IPv4 address embedded in the IPv6 address (this is known as IPv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses)" before that is normally not for interfaces only the static device assignments so that is corrected my Pv6-mapped IPv4 addresses or IPv6 embedded IPv4 addresses are now only on the Lan devices and not on the firewall interfaces. [image: 1752100262620-screenshot-2025-07-09-at-15.29.37-resized.png]

@Seeking-Sense said in How do I enable IPv6 traffic on VLAN for IoT Matter traffic?: @dennypage … Do you have any experience with the Tapo switches? I don’t have direct experience with Tapo. However I do have experience with Kasa, and I can attest that TP-Link goes out of its way to push / force you onto cloud services.

@Bob-Dig That looks like it worked! Is there a limitation I should be aware of with how quickly those rules will update? I just don't want to leave an open hole in my firewall whenever my ISP drops the ball.

@JonathanLee said in Alias tables don't contain IPv6 addresses anymore: Is your zone transparent ? I had an issue with mine set to (type transparent) and it was causing issues Zone type is at default "transparent" not "type transparent".

Hmm, that's a good question. Let me run some tests.... You can install using the legacy installer and upgrade if needed: https://atxfiles.netgate.com/mirror/downloads/ Steve

@Gertjan said in Dynamic DNS client "extracted from local system": To know if the WAN IP really changed ? Easy. Store the latest succeeded updated WAN IPv4 address locally. This is the cache file. Compare the actual WAN IPv4 with the cache ;: Just going to take this opportunity to point out that this causes a problem in the case where we restore to a replacement router in our lab before delivery. DDNS is updated to our office IP. Live router will not update because its cached IP didn’t change. (Workaround is to manually modify the file on disk to fool it, as I recall)

Did you have a specific question? If you're unsure I would first try installing CE on whatever hardware you have to test it. Steve

@JonathanLee said in IPv6 HE tunnel broker and Netflix quick fix idea: This fixed my issues 100% anyone else parse AAAA and A dns records like this? That issue is very old. Hit the search button - its just above : [image: 1721814205482-979fea0f-8b0a-4338-afa4-9be21a3aeefa-image.png] The issue has even a pfBlockerng solution made for it : [image: 1721814277228-99d7ab85-cb14-44e3-958e-e48648d7256f-image.png] Check the check box. Add all the host names that should not be resolved to AAAA. Done.

@Globaltrader312 I have now also removed the firewall rules under NAT

UPDATE: This issue is not specific to the use of large mtg (jumbo frames). It affects ICMP6 generally in this configuration. I don't know if the issue is due to the VLAN or the combination of a VLAN on a bridge. IPv4 is not affected and ICMP message sizes (with do-not-fragment set) respect the configured mtu.

@sloopbun Me to :-)

@tmoore said in Setting up ipv6 with one /64 allocation: For what it's worth my ISP is Teksavvy. I phoned in to them this morning and asked them to give me a /56 address delegation which they have done. So now I have a /56. Are you connected via Bell or Rogers? If Rogers, you might want to check the Rogers config. A friend of mine is with Teksavvy on Rogers. Another friend used be be with them on Bell. As for that pending gateway, you have to provide a monitor address that responds to pings. For mine, I ran traceroute to Google and picked the first address that responded. That address is 2607:f798:10:10d2:0:241:5615:217. It might be different for you, depending on where you are.