NAT64: IPv4 Ping Response Timeout

[maxminard]

Hello,

We are currently setting up NAT64 for our BR implementation, and all IPv4 ping requests coming from our OTBR (and attached Thread devices) to external IPv4 networks are timing out:

> ping 8.8.8.8
Pinging synthesized IPv6 address: fd97:4e6d:f78:2:0:0:808:808
1 packets transmitted, 0 packets received. Packet loss = 100.0%.
Done

We've followed this guide: https://openthread.io/codelabs/openthread-border-router-nat64#2 and I believe our NAT64 prefix is setup correctly:

> nat64 state
PrefixManager: Active
Translator: Active
Done

> netdata show
Prefixes:
fd07:c98e:8a6:1::/64 paos low 8000
Routes:
fd45:4468:e7e5:1::/64 s med 8000
2600:1700:19e1:a100::/64 s med 8000
fd97:4e6d:f78:2:0:0::/96 sn low a400
::/0 s med a400
Services:
44970 5d fd0426377902588896cf005e134e3f0ad11f s 8000
44970 5d fd0426377902588839e59cb1f050b873d11f s a400
Contexts:
fd07:c98e:8a6:1::/64 1 c
Commissioning:
56711 - - -
Done

Resolving the IPv4 address doesn't seem to work either and also times out:

> dns resolve4 example.com
DNS response for example.com. - fd97:4e6d:f78:2:0:0:5db8:d822 TTL:11372 
Done

> dns resolve4 example.com 8.8.8.8
Synthesized IPv6 DNS server address: fd97:4e6d:f78:2:0:0:808:808
DNS response for example.com. - 
Error 28: ResponseTimeout

> dns config 
Server: [2001:4860:4860:0:0:0:0:8888]:53
ResponseTimeout: 6000 ms
MaxTxAttempts: 3
RecursionDesired: yes
ServiceMode: srv_txt_opt
Nat64Mode: allow
Done

The tcpdump on our OTBR shows the request going out, and I've disabled the firewall to eliminate any possibilities of the packet being blocked. Does anyone know the possible reason for these timeouts?

Side Note: Is the OPENTHREAD_POSIX_CONFIG_NAT64_AIL_PREFIX_ENABLE compiler flag required to be enabled for NAT64? We currently can't enable it because we're building for Android and lack certain GNU extensions required by the functions enabled by that flag, and we receive compiler errors.

Thanks

[maxminard]

Update: I'm pinging the IPv4 address from one OTBR to another (using ot-ctl), and checking the tcpdump of each. The receiving device gets the request from the MAC address assigned to the sending OTBR, however it's sending the response to a MAC address assigned to my wifi router instead of the original OTBR device. When pinging directly over wlan0, the ping response is sent back to the original OTBR device. For some reason, when the ping is given over ot0, it's redirecting the response. Not sure why or how to fix this though

[kaizirlewagen]

I have currently the same problem, with tcpdump i see the icmp is incoming but the target is unreachable.

# tcpdump -i wpan0
[ 1201.836731] device wpan0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wpan0, link-type RAW (Raw IP), snapshot length 262144 bytes
06:59:48.489301 IP6 fe80::f005:9cc9:8add:e3d4.19788 > ip6-allnodes.19788: UDP, length 43
06:59:48.805208 IP 192.168.255.254 > 192.168.100.174: ICMP echo request, id 6, seq 6, length 16
06:59:48.805421 IP 192.168.100.34 > 192.168.255.254: ICMP 192.168.100.174 protocol 1 port 48964 unreachable, length 44

I add tayga and here i can dump this:

# tcpdump -i tayga-nat64
[ 1875.815304] device tayga-nat64 entered promiscuous mode
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tayga-nat64, link-type RAW (Raw IP), snapshot length 262144 bytes
07:40:09.382789 IP 192.168.100.34 > 192.168.255.254: ICMP dns.google protocol 1 port 36624 unreachable, length 44

At both it looks like the back route on Openwrt is missing. Has someone a working solution on Openwrt for this?

[maxminard]

Forgot to post the solution, but what fixed our issue was to add iptable masquerade configs. In our case, the wifi router was receiving and sending out the request, but it didn't know where to send the response since the openthread ipv4 source address 192.168.255.254 wasn't advertised to it. Masquerading this source address will just use the outgoing interface address (wlan0), so the router knew where to send the response.
iptables -t nat -A PREROUTING -i wpan0 -j MARK --set-mark 0x1001
iptables -t nat -A POSTROUTING -m mark --mark 0x1001 -j MASQUERADE
or
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

[kaizirlewagen]

Thx, i found it also. For Openwrt this settings also must be set:

iptables -t mangle -A PREROUTING -i wpan0 -j MARK --set-mark 0x1001
iptables -t nat -A POSTROUTING -m mark --mark 0x1001 -j MASQUERADE

iptables -t filter -A FORWARD -o br-lan -j ACCEPT
iptables -t filter -A FORWARD -i br-lan -j ACCEPT

uci set firewall.@zone[0].device='wpan0'
uci set firewall.@zone[1].device='wpan0'