Messages

+1

I use it.

However, the ddclient plugin provides the "nsupdate" method. According to do the documentation at https://ddclient.net/protocols.html that should do it, but might require editing ddclients config files? Never tried.

I like the os-rfc2136 plugin because it works out of the box and I can set TTLs.

[Thanks for a fresh look]

first of all: Thanks for a fresh look :)

I know how much work this is.

Just a few personal notes for desktop view, some already repeated:

- Readability is not great. Body (article) Text sizing indeed needs improvement.
- Is it really a good idea to have body (article) text on a grey background? Despite the size, that degrades readability.
- The type face runs pretty wide by nature. That also does not improve readability.

All that being said, in my personal opinion the official OPNsense documentation - which uses the same type face - is much more readable.

Just my 2 cents :)

So I understand this problem is technical / development related and can not be changed.

It was just an idea from a pure users perspective to eliminate those ahead numberings and not knowing which product is based on what without reading notes. Maybe one day.

Sorry for noise guys :)

We can't have the same numbers.

I see, this gets confusing here. I simply don't have the background to understand why you can't have the same numbers :)

Example thought with some initial release dates in mind:

Would it be a problem to release 24.7 Business Edition in October based on 24.7 Community Edition released in July?

Any drawback on this?

[future]

@Franco: I do know all the facts, that's why this is my idea for mid term future release cycles.

Take the forum itself: There 24.7 prod series board is now labeled 24.7, 24.10 although no 24.10. CE is not even out yet. Confiusing already, but what as soon as 24.10 CE comes out ;-)?

I guess you get my point:

For example, labeling the BE on it's actual CE BASE would be more consistent and intuitive to users.

LTE releases of software do that too, they are not ahead of something.

As said, that's just an idea and I'm sure you have more thoughts and logic behind this.

[7]

Hi folks,

I don't know if this is the right place to ask, but anyway:

It's really hard to easily distinguish between business and community edition releases. For example right now, CE is currently at 24.7x while BE is at 24.10x

This indicates to the user that BE is ahead in development and features, which is not the case.

Since BE is a toughly tested product based on a CE release, it is clear and logical that it must by nature be behind the CE release which it is based on.

I think this confuses many users, including myself sometimes. Yes, I do know about the release cycles and I read the release notes of the BE series which indicate the CE base. But not everyone does, especially not new users.

Could there be a cleaner an more intuitive way - maybe starting with the 25.x series?

best & thanks,
Stefan

PS: I personally use both. I happily pay for 2 BE subscriptions because I like the idea of supporting the project, although I sometimes even switch to CE on the BE "licensed" machines because there is a feature "I want now" :)

[can]

https://forum.opnsense.org/index.php?topic=30962.0

P.S. There's been some discussion recently about state tracking for ping. It's fairly loose... so stopping ping and starting another one between the same hosts can continue to use a session established by the first ping.

so the behavior seems to be ping host OS / implementation specific?

Tested right now on a Mac everything works fine: Toggling on/off a block rule is reflected right away as long as ping is restarted between:

Code Select Expand

for ((;;)) { ping -c 1 -t 1 9.9.9.9 | grep "0 packets\|from" ; sleep 1 ; } }

# note: zsh, ping / grep command notation for MacOS

Off Topic: Very nice idea for a widget. I would definitely enable that too  :)

[without disabling it first]

Just checked on a OPNsense VM. Setup of this VM: Pure LAN client (other box on this network advertises stateless)

Two findings, not to mix up:

(1) VTNET (parent) interface enabled and assigned, both IPv6 and IPv6 config types set to "none": Interface does not receive a IPv6, only link-local

(2) unassigning the interface without disabling it first: status active, full IPv6 assigned (nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>).

After rebooting, everything is fine (if down, no IPv6). So it seems changes to not properly reflect right away. That might indeed be worth a bug report but should be double checked by someone running a recent version (older install on this VM here).

Edit1: Additionally, I think this whole thing would be more clear if interfaces->overview would have 4 colored "plug" icons for the 4 displayed states (up, up disabled, down, down disabled) - which are currently only visible while hovering with the mouse - so not on a tablet.

Edit2: checked across reboots

[hardware interface settings:]

VLAN: You don't have to disable the parent interface. Indeed in all my use cases I have it enabled (HW settings etc).

Example config for VLANs:

hardware interface settings:

(1) enable the interface

(2) set both IPv4 and IPv6 Configuration Type "none" *)

(3) adjust hardware settings as needed

VLAN setting:

(4) create your VLANs

(5) assign your hardware interface as parent

Assignments:

(6) assign / add the VLAN interfaces


*) note: The interface will still have a link-local IPv6. That's correct.

[You need Router Advertisements.]

Thank's - my Details looks different

This is not very helpful - can you post a screenshot?

For now - I got the problem that the radvd crashes.

You need Router Advertisements. Without at least one router delivering RAs (radvd), a IPv6 network cannot run properly.

Two short reads on it:

https://networkengineering.stackexchange.com/questions/82652/is-possible-to-use-dhcpv6-without-slaac

and with some more detail:

https://blogs.infoblox.com/ipv6-coe/why-you-must-use-icmpv6-router-advertisements-ras/

It would have been very helpful to know in the first place that your RA daemon is broken  ;)

---

Bottom line:

(1) get Router Advertisements working on both of your interfaces (LAN networks)

(2) start with RA default settings, try RA mode "stateless" (I don't know that OPNsenses default setting is) and walk your way up from there as needed.

forgot to ask: what is your router advertisement mode setting on your client (LAN) interfaces?

/services_dhcpv6.php: The command '/usr/sbin/daemon -f -p '/var/run/dhcpleases6.pid' '/usr/local/opnsense/scripts/dhcp/prefixes.sh'' returned exit code '3', the output was 'daemon: process already running, pid: 37530'

That's OK, I get that too restarting DHCPv6

unknown or unexpected DHCP6 option opt_86, len 16

That's OK, I get that too.

XID mismatch

I do NOT see this error.

---

Since you configured your FritzBox for IA_PD only, what are your v6 related DMZ interface settings (request prefix only etc)?

However, except for the xid error (which I'm unaware of) things look good.

Below is a screenshot of my interfaces->overview->WAN->details listing for comparison.

some more ideas:

(1) did you try restarting radvd?

(2) sure not firewall / vlan related?

[delegated a /64]

Seems like topics get mixed up here. First, congrats to Melroy vd Berg for solving the bridge based issue  :)

@open:

(1)

Yes, I get a /56 from ISP an delegated a /64 to DMZ Interface

I'm having a bit of trouble understanding your setup due to naming stuff. Assuming your interface named "DMZ" is your WAN interface on OPNsense, you say it only gets a /64 prefix delegated from the FritzBox to OPNsense?

(2) error logs

It's very strange that there are no dhcp6c errors / warnings at all in system->Log Files->General. You should check if there are any dhcp related errors right after you reboot OPNsense.

FYI: attached is a current screenshot of one if my FritzBoxes v6 downwards delegation, /57 to OPNsense in this case (screenshot is German though). But since you have no dhcp6c errors at all and say all prefixes are correctly delegated, this should look similar at your side.

In general, OPNsense IPv6 router chain behind a FritzBox works fine. I run it with the previous  OPNsense release (24.7.9_1-amd64) on 2 different locations.

Although I can not present you simple solution, a few things to check:

Assuming "DMZ" is your uplink / gateway ("WAN") interface at OPNsense.

(1) you get a prefix delegated large enough on DMZ

(2) increase logging level of DHCP to see what actually happens (interfaces->settings->IPv6 DHCP)

(3) did anything change in the FritzBox itself? Firmware / settings? (Have seen this before breaking correct downstream delegation)

(4) Do you have Router Advertisements enabled? Try playing with that. When enabled, there are almost no devices at all using the DCHPv6 anyway and you won't see leases.

Maybe post some screenshots of your config and / or DHCP related log stuff?

best & good luck,
Stefan