Messages

Having configured a wireguard interface with both an ipv4 and an ipv6 address from any provider (mullvad, proton when using some servers), the "hack" mentioned in the docs (broaden the v6 subnet and use the other ip as a gateway, mark the v4 gateway as a "far" one and use the VPN DNS address as the ip) works well.
As far as I can tell, ticking "Dynamic Gateway Policy" in the interface settings should also work for both v4 and v6 in principle. However, the gateway created when applying that setting is marked as "IPv4" and indeed produces no results when applied to an IPv6 rule. Cloning the gateway and changing the type (and nothing else) manually and applying that to the v6 rule does work but, in my opinion, shouldn't be necessary. Is there something that can be done to correct this behaviour?

You could try setting the tunable `kern.hz` = 1000. In VMs FreeBSD defaults to 100, which saves some CPU but messes up timer accuracy and such. You could try even higher if using shapers at those speeds, but 1000 is the default for bare metal and seems to work well for me at least.

Seems to help in my case. Haven't tested it extensively though.

I sincerely apologise, it was late when writing this. Turns out the service I was testing with was being accessed via ipv6, making me think the redirect was working but not being logged for some reason. It didn't occur to me at the time of writing that I had set it up for ipv6. Very sorry for being a hassle.

Reflection is turned off in the Firewall->Advanced menu, following a piece of advice I had read on here some time ago.

When adding a port forwarding rule for a certain interface or set of interfaces, the expected behaviour would be for that rule to apply only for the interface(s) selected, even if the source field contains a "superset" of the subnets of those interfaces. In essence, the rule should apply to the "intersection" of the "source" and "interfaces" fields, assuming I understand the meaning of the "interfaces" field correctly.

Currently, the interfaces field seems to be ignored when applying said rules, leading to unexpected results.

There is an issue reported on GitHub (https://github.com/opnsense/core/issues/7952) that has, erroneously in my opinion, received the "support" label. Since it does not seem to be getting any attention, I assume because of that, I thought posting this here would help in bringing some much wanted attention, or at the very least acknowledging, said issue.

I seem to be having issues with the intel3 kernel with PPPoE and DHCPv6 on WAN. Very similar to the problem discussed a little while ago with dhcp6c. Reverting to the intel2 kernel and restarting seems to consistently fix the issue. To re-iterate, WAN receives an IPv6 address but not a prefix. It seems weird since I use an igb interface, and most of the changes regarding that were already present in intel2. Happy to provide more info if needed.

Edit: Clicking apply in the interface settings seems to work, it's just after boot up that it is not picked up. Will try to narrow it down more.

Edit 2: Seems like an ISP issue, just something to keep an eye on.

Check if you have "Block private networks" checked in the interface settings. If so, try unchecking it.

I know. It hasn't occurred much since that report and is really minor. I consider this solved as the patch works. Thanks for the help and the work you are putting in the project! Good luck with the issue reports and I will probably be available to test anything that comes up. Cheers!

Scratch that, it did pick up a prefix after 8 mins. Used to be much quicker. Don't think it is an ISP issue, as it is the first time I've seen it take this long.

Doesn't seem to get a prefix anymore (with request prefix only disabled). It used to with 24.7.4 with the same config.

Haven't applied the patched build. The work around of requesting just a prefix works for now. Do you want me to test it?

I believe so

I remember you writing that the relevant patch won't be in 24.7.5, but just to confirm, the behaviour seems to be the same. Otherwise smooth as always!

This is a bit odd:

2024-09-19T22:22:05   Informational   ppp   [opt3] IFACE: Rename interface ng0 to pppoe0   
2024-09-19T22:22:05   Informational   ppp   [opt3] IFACE: Up event   
2024-09-19T22:22:05   Notice   ppp   ppp-linkup: executing on pppoe0 for inet   
2024-09-19T22:22:05   Informational   ppp   [opt3] xxx.xxx.xxx.xxx -> xxx.xxx.xxx.xxx
2024-09-19T22:22:05   Informational   ppp   [opt3] IPCP: LayerUp   

According to the log ppp-linkup is calledbefore ng0 is renamed to pppoe0, but it's already told the interface name is pppoe0. In theory that's asking for trouble, but I've never seen someone raise such an issue before.


Cheers,
Franco

I don't think I have a peculiar configuration. There is a vlan on top of the physical WANPARENT interface, with pppoe0 on top of that.