Bug #2598
reply-to on IPv4+6 rules breaks v6
| Status: | Resolved | Start date: | 08/16/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 100% |
|
| Category: | Rules/NAT | |||
| Target version: | 2.1 | |||
| Affected version: | 2.1-IPv6 | Affected Architecture: |
Description
The auto-added reply-to on WAN rules in combination with IPv4+v6 rules breaks v6 connectivity, as the v4 IP is included as the reply-to address. Work around is just disabling the reply-to, at least where that's feasible. PF seems to ignore any v6 matching the rule if a v4 reply-to is specified, as it's not just being improperly routed, it's being logged as blocked.
There isn't a clean easy answer here. Splitting the rule, where it requires reply-to or route-to, into two separate rules in rules.debug is probably the best solution.
Associated revisions
Fixes #2598. In case the rule is both for v4 and v6 generate 2 rules for each family. This is the only solution for now
History
#2
Updated by Ermal Luçi 4 months ago
- % Done changed from 0 to 100
Applied in changeset f73e35319a7f36c761cadac132c2f3484103b88f.
#3
Updated by Bernhard Lichtinger 3 months ago
This works now for dualstack rules on WAN. But it also creates 2 separate rules on other (OPT) interfaces for dual-stack rules, which is not needed. But I think it does not harm either.
Checked on 2.1-BETA1 (amd64) built on Sun Feb 24 10:55:18 EST 2013
#4
Updated by Jim P 3 months ago
- Status changed from Feedback to Resolved
It creates two rules because it has to. On WAN without the default gateway it needs to add reply-to on the rules separately, the IPv4 rule needs the IPv4 gateway, on IPv6 it needs the IPv6 gateway. Can't do that in a single rule, so it's working as intended.