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
pf nat64 rule not matching
Hello,
I'm trying to get a basic OpenBSD NAT64 router setup. I'm following
along with these instructions:
- https://blog.obtusenet.com/dns64-nat64-on-openbsd/
My unbound instance looks like it's correctly configured and returning
correct IPv6 addresses, so that's good.
# dig ipv4.google.com +short
ipv4.l.google.com.
64:ff9b::8efa:bc0e
However, the pf rule using af-to does not appear to do anything and
I haven't been able to figure out why. When I try to ping6, I get 100%
packet loss.
I inspected packets through tcpdump (after adding "log" to everything
in pf.conf) and nothing seems to be getting blocked, though it also
appears the 64:ff9b::/96 address are not being translated either; I
think the packets are passing through pf unchanged (the rule doesn't
apply, but I don't know why).
Here is my entire pf.conf:
wan = "igc0"
trusted = "igc1"
untrusted = "igc2"
iot = "igc3"
cerberus_ssh = "36285"
table persist file "/etc/martians"
set block-policy drop
set loginterface egress
set skip on lo0
block in log quick from urpf-failed
block in log quick on egress from to any
block return out log quick on egress from any to
block return log all
pass
# allow IPv6 PD from ISP
pass in inet6 proto udp from fe80::/10 port dhcpv6-server to fe80::/10 port
dhcpv6-client no state
# allow ICMPv6 traffic (necessary for IPv6 to work)
pass inet6 proto icmp6 all
# perform nat64 (NOT WORKING)
pass in to 64:ff9b::/96 af-to inet from ($wan:0)
# allow outbound queries from local unbound and NTP
pass out inet6 proto { tcp, udp } from ::1 to port { domain, ntp }
# allow DNS & NTP queries from the iot network
pass in on $iot proto { tcp, udp } from $iot:network to port { domain, ntp }
# allow ssh, http, & https
pass inet6 proto tcp to port { ssh, http, https, $cerberus_ssh }
I have IP forwarding turned on:
# sysctl | grep forwarding
net.inet.ip.forwarding=1
net.inet.ip.mforwarding=0
net.inet6.ip6.forwarding=1
net.inet6.ip6.mforwarding=1
I have an IPv4 and IPv6 address for igc0 via autoconf.
Here's a rough sketch of my network topology:
+---+
| ISP modem |
+---+
|
|
igc0
+---+
| cerberus (OpenBSD router) |
+---+
igc1 igc2 igc3
| ||
| ||
... ... +-+
| vulpes (OpenBSD client) |
+-+
>From both vulpes and cerberus, ping6 ipv4.google.com hangs and never
returns.
I tried substituting ($wan:0) for my actual IPv4 address assigned to
igc0, but I got no change in behavior. I read in the man page that
:0 does not include aliases when used on an interface. When I print
the rules out using pfctl -vvsr, it gets expanded to (igc0:0:1),
which looks weird and I don't understand why. My understanding is
that it should be "... af-to inet from IPV4_ADDRESS_OF_WAN_IF", but
I don't know if (igc0:0:1) is the IPv4 address of igc0, and I can't
figure out how to verify if that's right... or even if that's
the problem in the first place and I'm chasing a red herring.
I feel like I'm missing something, but I can't see it. The Book of PF
doesn't have any information on NAT64 that I could see, and the man page
for pf.conf shows an example of what I'm already doing with no
additional instructions. I've found maybe 3 articles about NAT64 on
OpenBSD through searching, but none give me any more context or clues
beyond the one I mentioned earlier.
I'd appreciate any help I could get!
Evan
Here's my dmesg:
OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8332189696 (7946MB)
avail mem = 8059916288 (7686MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x75d9f000 (122 entries)
bios0: vendor American Megatrends International, LLC. version "ALN4L102" date
11/08/2023
bios0: Default string Default string
efi0 at bios0: UEFI 2.8
efi0: American Megatrends rev 0x5001a
acpi0 at bios0: ACPI 6.4
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT SSDT HPET APIC MCFG SSDT UEFI
RTCT PSDS NHLT LPIT SSDT SSDT DBGP DBG2 SSDT DMAR FPDT SSDT SSDT SSDT SSDT TPM2
PHAT WSMT
acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) SIO1(S3) RP09(S4) PXSX(S4)
RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4)
RP14(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) N100, 3392.18 MHz, 06-be-00, patch 0012
cpu0:
FPU,VME,D
