23.1.8: dhcp6c script race condition causes hundreds of dpinger processes?

[rssor]

In the event it's not possible to fix the unicast issue, am I right that a new floating automatic egress rule buried in advanced settings might address the issue? Then there's the secondary issue with reflected responses I think might be fixable with a second rule.

Rule 1: It seems like I can define an egress rule that matches on src ip of a WAN interface and forces it out the correct gateway, and if that's correct the only issue is that I can't add it before the automatic DHCP out rule I can't control.

Is that viable, or would having a rule like that the needs to be updated on IP changes as a floating egress problematic?

Rule 2: The only other rule I don't think I can make at the moment is preventing entirely a packet with incoming interface WAN1 going out WAN2 and the other way around (automatic DHCP rules permit it before I can block it).

This would solve the issue during a manual reload, where the broadcast goes out and I get a unicast response, but since the interface doesn't have the address yet it reflects it out the other interface. But since these are both gateways these are actually the only two interfaces on the entire machine I never want traffic to pass between.

[franco]

And thoughts on this? I'm not very optimistic about the patches doing anything to help here, but they also do not appear to have a downside that I could find.


Cheers,
Franco

[rssor]

After seeing that even the on Linux the same unicast routing issue seems to exist (policy based routing is the only option there as well) I don't think any patch will work, so just some way to narrow the allowed out rules (so that I can use policy based rules to prevent the traffic from moving from one WAN interface to the other) is probably the only action worth taking here.

The reason I want the slightly tweaked rules is that for the traffic I posted on June 7th:

Code: [Select]

WAN 2023-06-07T11:48:34-04:00 <- 72.31.136.237:67 67.WAN2_IP:68 udp let out anything from firewall host itself
WAN2 2023-06-07T11:48:34-04:00 -> 72.31.136.237:67 67.WAN2_IP:68 udp allow DHCP client on WAN2
Has a DHCP response from WAN2's DHCP server come in on WAN2 and get routed out WAN1 because the "let out anything from firewall host itself" rule doesn't actually verify that it's from the firewall host itself.

I'm trying to avoid touching the machine until 23.7 comes out, as it has a kernel fix I need to avoid constant filesystem corruption on the hardware. ( https://github.com/opnsense/src/commit/567cc4e6bfd92d7351e385569f2bb4b7c89b6db0 )

[franco]

You are right. We should pin the gateway to the automatic firewall rules, but I'm not sure if we can do that without specifying the IP address... perhaps "(em1:0)" as source works with kernel address expansion, but it would have to be a floating outgoing rule since we don't know where it originates from?

(Sorry for stating something obvious perhaps, not enough time to go through the thread again at the moment.)


Cheers,
Franco