"Recent posts
#1
Development and Code Review / Re: shouldn't fc00::/8 also be...
Last post by meyergru - Today at 05:31:46 PMYou will find the answers here: https://en.wikipedia.org/wiki/Unique_local_address
Site-local-adresses (fec::/10) have been deprecated and are in the global allocation block, so potentially could be routeable at any point.
fc00::/8 is proposed to be managed, but is not at this time. So, only fd00::/8 is truly locally administered and thus "private" in some sense.
Not that it matters much if you do not have explicit allow rules and also use such ranges, which would go against specifications, anyway.
Site-local-adresses (fec::/10) have been deprecated and are in the global allocation block, so potentially could be routeable at any point.
fc00::/8 is proposed to be managed, but is not at this time. So, only fd00::/8 is truly locally administered and thus "private" in some sense.
Not that it matters much if you do not have explicit allow rules and also use such ranges, which would go against specifications, anyway.
#2
26.1 Series / Re: Wireguard VPN
Last post by meyergru - Today at 05:21:19 PMAlso:
You have to deduct something for the VPN header overhead from your actual MTU, you know that?
Also, Patrick is right: That blocked packet clearly shows that the default deny rule applies, so whatever rule is supposed to allow that VPN traffic seems to be incorrect.
Quote from: leony on Today at 11:41:12 AMMTU value is for the PPPoE
You have to deduct something for the VPN header overhead from your actual MTU, you know that?
Also, Patrick is right: That blocked packet clearly shows that the default deny rule applies, so whatever rule is supposed to allow that VPN traffic seems to be incorrect.
#3
German - Deutsch / Re: [Gelöst] IPv6 RFC 7217 Adr...
Last post by drosophila - Today at 05:10:17 PMEs scheint, als ginge es ab FreeBSD15, zumindest entnehme ich diesem Post: https://lists.freebsd.org/archives/cu/2026-January/009885.html, dass es dann via `net.inet6.ip6.use_stableaddr` eingeschaltet werden kann.
#4
26.1 Series / Re: Wireguard VPN
Last post by Patrick M. Hausen - Today at 04:57:58 PMPlease show the firewall rule you created that is supposed to let WireGuard connections in on your WAN interface.
#5
26.1 Series / Re: Wireguard VPN
Last post by leony - Today at 04:47:16 PMHi,
I have static IP so no need for Dynamic DNS etc..
I think I will give up. It simply doesn't work. Should not be this difficult. And for the note I believe Opnsense is quite buggy in Wireguard (especially for peer generator). Anyway I won't go into the details much. Please see the firewall log which I could get, the packets simply being discarded for the reason I don't understand.
I have static IP so no need for Dynamic DNS etc..
I think I will give up. It simply doesn't work. Should not be this difficult. And for the note I believe Opnsense is quite buggy in Wireguard (especially for peer generator). Anyway I won't go into the details much. Please see the firewall log which I could get, the packets simply being discarded for the reason I don't understand.
#6
Development and Code Review / shouldn't fc00::/8 also be blo...
Last post by drosophila - Today at 04:45:00 PMIf I enable "Block private networks from WAN", the rule gets generated with the following contents: "fd00::/8, fe80::/10, ::/128". Shouldn't that be either "fd00::/7" or have an additional "fc00::/8" in it? They're both private with the only difference being that fc:: is supposedly assigned by the IANA. AFAIK, this process never materialized but still...?
Plus, even though deprecated, wouldn't the site-locals (fec::/10) also be considered "private"?
Also, the description of the checkbox in the interface config only mentions RFC1918, there is no mention of IPv6 at all so which ranges will get blocked won't be known unless you look at the rules.
Am I missing something again?
Plus, even though deprecated, wouldn't the site-locals (fec::/10) also be considered "private"?
Also, the description of the checkbox in the interface config only mentions RFC1918, there is no mention of IPv6 at all so which ranges will get blocked won't be known unless you look at the rules.
Am I missing something again?
#7
26.1 Series / Re: New IPv6 address assignmen...
Last post by franco - Today at 03:22:48 PMThere's basic, advanced and override mode already... not sure what else would make sense.
Cheers,
Franco
Cheers,
Franco
#8
26.1 Series / Re: New IPv6 address assignmen...
Last post by nero355 - Today at 03:02:50 PMQuote from: franco on Today at 01:05:09 PMFrom what I've seen it's impossible to guess what the ISP will offer even more so if we specifically request something and the ISP ignores it.How about more "Advanced/Export Mode Finetuning Options" so to speak for dhcp6c on the WAN Interface ?!
We could fix the misalignment in dhcp6c, but then it's still pretty much broken in the core because it will make other assumptions.
#9
26.1 Series / Re: [KEA DHCP Error] Interface...
Last post by nero355 - Today at 02:58:03 PMQuote from: franco on Today at 12:59:17 PMThere was some fuzz with Kea lately about interfaces which led to https://github.com/opnsense/core/issues/10072I think this is a different issue since it's not just KEA complaining about this...
Not sure if related but worth a peek.
Maybe wait for the 26.1.6 Release and check again after a reboot ?
It's nothing that breaks functionality or stability, but it's weird that multiple Services complain about something they shouldn't and have nothing to do with ?!
#10
26.1 Series / Re: Destination NAT: Associate...
Last post by franco - Today at 02:57:49 PMPeople asking for automatic firewall rules visiblity and people asking why automated firewall rules are visible everywhere are mutually exclusive.
Both GUIs show the same automatic rules because it's the same feature.
Cheers,
Franco
Both GUIs show the same automatic rules because it's the same feature.
Cheers,
Franco
