On 2019/12/14 17:36, Eugene Grosbein wrote: > 15.12.2019 2:54, John W. O'Brien пишет: >> Hello FreeBSD Networking, >> >> As the subject summarizes, I have a mostly-working NAT64 rig, but return >> traffic is disappearing, and I haven't been able to figure out why. I >> observe the post-translation (4-to-6) packets via ipfwlog0, but a simple >> ipfw counter rule ipfw matches nothing. > > Have you read NETWORK ADDRESS TRANSLATION (NAT) section of ipfw(8) manual > page carefully? > It tells: > >> To let the packet continue after being (de)aliased, set the sysctl >> variable net.inet.ip.fw.one_pass to 0. > > Did you set sysctl net.inet.ip.fw.one_pass=0 ? >
Hi Eugene,
Yes, I am familiar with the one_pass flag. It is disabled. However, I
don't believe it applies to the nat64lsn module. The IPv6/IPv4 NETWORK
ADDRESS AND PROTOCOL TRANSLATION section, Stateful translation
subsection says:
> After translation NAT64 translator by default sends packets through
> corresponding netisr queue.
I find no mention of an interaction between nat64lsn and one_pass.
Furthermore, the outbound path (6-to-4) is working, and aliased packets
are successfully matching ipfw rules.
This is what the rule counters look like in the working case after
sending a single ping6 from the v6 jail to the v4 jail via the host that
performs NAT64:
root@freebsd:~ # ipfw show
00100 2 72 setfib 1 ip4 from 198.51.100.4/30 to any
00200 2 72 allow ip4 from 198.51.100.4/30 to any
00300 2 112 setfib 1 ip6 from 2001:db8:64:64::/96 to
2001:db8::/64,2001:db8:1000::/64
00400 2 112 allow ip6 from 2001:db8:64:64::/96 to
2001:db8::/64,2001:db8:1000::/64
00500 1 56 nat64lsn magic ip6 from 2001:db8::/64,2001:db8:1000::/64
to 2001:db8:64:64::/96 // Alias 6-to-4
00600 1 36 nat64lsn magic ip4 from any to 198.51.100.4/30 // De-alias
4-to-6
00700 71 7780 allow ip from any to any
65535 26 2752 deny ip from any to any
root@freebsd:~ # ipfw nat64lsn magic show
nat64lsn magic prefix4 198.51.100.4/30 prefix6 2001:db8:64:64::/96 log
The equivalent counters in the non-working case would be 0 for rules 300
and 400, but 100 and 200 would be non-zero.
--
John W. O'Brien
OpenPGP keys:
0x33C4D64B895DBF3B
signature.asc
Description: OpenPGP digital signature
