On 26.06.2019 14:23, Patrick M. Hausen wrote: > Hi all, > >> Am 26.06.2019 um 12:28 schrieb Andrey V. Elsukov <bu7c...@yandex.ru>: >> >> On 26.06.2019 13:10, Patrick M. Hausen wrote: >>> tcpdump will take some more time, currently we do not have /dev/bpf in >>> these jails. >> >> So, nat64_direct_output didn't help? >> Does `ipfw nat64lsn NAT64 list states` shows correct addresses? > > No, it didn’t. Yes, the IPv4 addresses shown are the external addresses > of these „gate64“ jails. > > See: > > 13:06:28.205602 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) > 2a00:b580:8000:12:40f9:d4:cd11:d68c > 64:ff9b::9765:7085: [icmp6 sum ok] > ICMP6, echo request, seq 0 > 13:06:28.205611 IP (tos 0x0, ttl 63, id 25804, offset 0, flags [DF], proto > ICMP (1), length 36) > 217.29.40.145 > 151.101.112.133: ICMP echo request, id 1024, seq 0, > length 16 > 13:06:28.207853 IP (tos 0x0, ttl 58, id 53557, offset 0, flags [none], proto > ICMP (1), length 36) > 151.101.112.133 > 217.29.40.145: ICMP echo reply, id 1024, seq 0, length > 16 > 13:06:28.207861 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 16) > d91d:2891::9765:7085 > 2a00:b580:8000:12:40f9:d4:cd11:d68c: [icmp6 sum ok] > ICMP6, echo reply, seq 0 > 13:06:29.268095 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) > 2a00:b580:8000:12:40f9:d4:cd11:d68c > 64:ff9b::9765:7085: [icmp6 sum ok] > ICMP6, echo request, seq 1 > 13:06:29.268106 IP (tos 0x0, ttl 63, id 18866, offset 0, flags [DF], proto > ICMP (1), length 36) > 217.29.40.145 > 151.101.112.133: ICMP echo request, id 1024, seq 1, > length 16 > 13:06:29.270335 IP (tos 0x0, ttl 58, id 53653, offset 0, flags [none], proto > ICMP (1), length 36) > 151.101.112.133 > 217.29.40.145: ICMP echo reply, id 1024, seq 1, length > 16 > 13:06:29.270340 IP6 (hlim 57, next-header ICMPv6 (58) payload length: 16) > d91d:2891::9765:7085 > 2a00:b580:8000:12:40f9:d4:cd11:d68c: [icmp6 sum ok] > ICMP6, echo reply, seq 1 > > So the IPv4 echo and reply exchange looks good. Then the packet is > forwarded to IPv6 with an entirely bogus (AFAIK) IPv6 source address. > > Interestingly the host portion of the address that should be nat64 is > identical, > but the prefix - where does it get that idea?
Thanks, it is very useful. Due to the code difference between head/ and stable/11 there were some partial MFCs, and r334836 seems has missing part of code. Can you try this patch? -- WBR, Andrey V. Elsukov
Index: sys/netpfil/ipfw/nat64/nat64lsn.c =================================================================== --- sys/netpfil/ipfw/nat64/nat64lsn.c (revision 349408) +++ sys/netpfil/ipfw/nat64/nat64lsn.c (working copy) @@ -408,6 +408,7 @@ nat64lsn_translate4(struct nat64lsn_cfg *cfg, cons } else logdata = NULL; + src6 = cfg->base.plat_prefix; nat64_embed_ip4(&src6, cfg->base.plat_plen, htonl(f_id->src_ip)); ret = nat64_do_handle_ip4(*pm, &src6, &nh->addr, lport, &cfg->base, logdata);
signature.asc
Description: OpenPGP digital signature
