NAT64 return traffic vanishes after successful de-alias

[John W. O'Brien]

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 at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20191214/0a2eb563/attachment.sig>