Re: pf nat64 rule not matching
> I don't think there is at present. There are no "only use v4" or "only > use v6" addresses modifiers, and pf isn't figuring out for itself that > it only makes sense to use addresses from the relevant family for > af-to translation addresses (although it _does_ do this for nat-to). Good to know. I was able to get this working by using ($wan) instead of ($wan:0), fwiw. > Ah I meant that the router should not use the local unbound dns64 > resolver for its own traffic - otherwise it won't be able to reach v4 > hosts because there won't be anything to handle the translation. > Either point it off-machine (ISP or public resolver) or run another > local resolver for its own traffic. Ah, that makes sense. I was totally doing this. *facepalm* I've changed it to use Quad9. Thanks for the follow-up! > Please keep replies on the mailing list. My bad! Still getting used to the `mail` client and how this mailing list operates in general, and I see now the default behavior is to do a reply-all that includes your personal email in addition to the mailing list. Apologies!
Re: pf nat64 rule not matching
On 2024-03-15, Evan Sherwood wrote: > > Is there a way to configure this without hard-coding my IPv4 address? > I do not think my IPv4 address from my ISP is static, thus my original > interest in the ($wan:0) form. I don't think there is at present. There are no "only use v4" or "only use v6" addresses modifiers, and pf isn't figuring out for itself that it only makes sense to use addresses from the relevant family for af-to translation addresses (although it _does_ do this for nat-to). >> Regarding the other rules and tests, the ::1 rule is wrong, packets >> outgoing on the network won't have a ::1 address, try "!received-on >> any", and packets sourced from the router itself won't hit the af-to >> rule so tests need to be from another machine (and probably best use >> different DNS servers not doing dns64 on the router). > > Thanks for this follow-up. You're right that I was trying to only target > traffic that originated from the router itself with this rule. I had > figured out that the tests needed to be from another machine, though > that did take me a while. > > What are the reasons for doing dns64 on a different machine? Ah I meant that the router should not use the local unbound dns64 resolver for its own traffic - otherwise it won't be able to reach v4 hosts because there won't be anything to handle the translation. Either point it off-machine (ISP or public resolver) or run another local resolver for its own traffic. -- Please keep replies on the mailing list.
Re: pf nat64 rule not matching
> Try changing ($wan:0) to $(wan) and see what happens. Huh, that worked! Thanks!
Re: pf nat64 rule not matching
Try changing ($wan:0) to $(wan) and see what happens.
Re: pf nat64 rule not matching
> Can you try if the same happens with a more specific rule (for > testing)? > > i.e.: > > pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96 > af-to inet from "actual IP on igc0"/32 This worked! Specifically, I think the ($wan:0) was the problem. I could've sworn I tried this with the actual IP and it wasn't working before, but I might've deleted the inet6 at that point, so maybe I created a new problem then... which you also pointed out: > I am suspecting that the missing inet6 may lead to some confusion. Is there a way to configure this without hard-coding my IPv4 address? I do not think my IPv4 address from my ISP is static, thus my original interest in the ($wan:0) form. > Alternatively, remove the block rules; URPF may be an issue here, if > you lack a route for the /96. I had tried commenting out all of the block rules and saw no change. Tcpdump also showed no blocks, fwiw. > Regarding the other rules and tests, the ::1 rule is wrong, packets > outgoing on the network won't have a ::1 address, try "!received-on > any", and packets sourced from the router itself won't hit the af-to > rule so tests need to be from another machine (and probably best use > different DNS servers not doing dns64 on the router). Thanks for this follow-up. You're right that I was trying to only target traffic that originated from the router itself with this rule. I had figured out that the tests needed to be from another machine, though that did take me a while. What are the reasons for doing dns64 on a different machine?
Re: pf nat64 rule not matching
On 2024-03-15, Tobias Fiebig via misc wrote: > > Moin, >> # perform nat64 (NOT WORKING) >> pass in to 64:ff9b::/96 af-to inet from ($wan:0) > > Can you try if the same happens with a more specific rule (for > testing)? > > i.e.: > > pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96 > af-to inet from "actual IP on igc0"/32 "actual IP on igc0" is a good idea. If I try a similar rule without () using an interface with v4+v6 addresses, pfctl rejects it due to af mismatch. > I am suspecting that the missing inet6 may lead to some confusion. > Alternatively, remove the block rules; URPF may be an issue here, if > you lack a route for the /96. "match log(matches)" and "tcpdump -neipflog0" is your friend for figuring out which rules are used. I suspect the urpf too. Regarding the other rules and tests, the ::1 rule is wrong, packets outgoing on the network won't have a ::1 address, try "!received-on any", and packets sourced from the router itself won't hit the af-to rule so tests need to be from another machine (and probably best use different DNS servers not doing dns64 on the router).
Re: pf nat64 rule not matching
Moin,
> # perform nat64 (NOT WORKING)
> pass in to 64:ff9b::/96 af-to inet from ($wan:0)
Can you try if the same happens with a more specific rule (for
testing)?
i.e.:
pass in on igc3 inet6 from "put actual v6 prefix here" to 64:ff9b::/96
af-to inet from "actual IP on igc0"/32
I am suspecting that the missing inet6 may lead to some confusion.
Alternatively, remove the block rules; URPF may be an issue here, if
you lack a route for the /96.
A minimal (== based on the default pf.conf) config working for me:
```
# $OpenBSD: pf.conf,v 1.55 2017/12/03 20:40:04 sthen Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf
set skip on lo
block return# block stateless traffic
pass# establish keep-state
# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010
# Port build user does not need network
block return out log proto {tcp udp} user _pbuild
pass in on vio0 inet6 from 2a06:d1c0:deac:1:d5:64:a115:1 to
2a06:d1c7:a:4764::/96 af-to inet from 193.104.168.184/29 random
```
With best regards,
Tobias
