MAP-T ICMP failing to be translated to MAP domain

[facboy]

i'm trying to use this through openwrt main with minimal configuration (basically, map package installed and expect ISP DHCP to do the rest).

i had some trouble with the 20 byte overhead but i believe that's sorted. IP4 connectivity seems to work except that no external IP4 addresses can be be pinged, either from clients or from the router itself.

i turned debug up to 5 and every time i try to e.g. ping 1.1.1.1 i see this in the log:

May 21 21:48:25 my-r4s kernel: [96555.777549] nat46_ipv4_input packet
May 21 21:48:25 my-r4s kernel: [96555.777958] nat46_ipv4_input protocol: 1, len: 84, flags: 01
May 21 21:48:25 my-r4s kernel: [96555.778482] ICMP echo request translated into IPv6, id: 3410
May 21 21:48:25 my-r4s kernel: [96555.779026] xlate_map_v4_to_v6: IPv4 address wx.yz.27.159 outside of MAP domain st.uv.160.0/22
May 21 21:48:25 my-r4s kernel: [96555.779860] [nat46] pairs_xlate_v4_to_v6_outer result: src -1 dst 2
May 21 21:48:25 my-r4s kernel: [96555.780430] [nat46] Could not find a translation pair v4->v6
May 21 21:48:25 my-r4s kernel: [96555.780964] [nat46] Could not translate v4->v6

wx.yz.27.159 is the IP4 address seen on the wan interface in e.g. ip address, st.uv.160.0/22 i passed to netifd so presumably is coming back from the ISP DHCP server. i gather from the RFC that ICMP is supposed to be treated slightly differently to other traffic — should the IP4 address be getting translated to the MAP domain?

is this a misconfiguration from the ISP, openwrt, or a bug in nat46?

[ayourtch]

"xlate_map_v4_to_v6: IPv4 address wx.yz.27.159 outside of MAP domain st.uv.160.0/22" - the source address of your packets being sent into the nat46 interface is not corresponding to what has been configured for MAP-T domain IPv4 address, so it is is a correct behaviour for the module to reject such a packet.

The usage of the nat46 module in the MAP-T packet flow on OpenWRT relies on the fact that first the stateful NAT44 on the OpenWRT needs to translate the source address into the IPv4 address and one of the port ranges that are allocated to that CPE, and then bounce the packet to nat46 device on the way out, where it kicks in and converts statelessly the packet into IPv6 one, which is then forwarded out. I suspect in this case the first NAT44 translation is not happening, which leads to the behaviour that you observe. (In my tests which admittedly were quite a few years ago, I remember that to be able to ping from the OpenWRT box itself, I had to have the outside interface not have any IP address, such that the pings from the box were sourced from the inner interface and thus were subject to NAT44).

I can not clarify whether the issue is related to ISP or pure OpenWRT, since it will be depending on the values of "wx", "yz", "st" and "uv", as well as the values supplied by the DHCPv6 during the provisioning (which is hopefully how it gets configured).

AFAIK this module is successfully used in production by at least one ISP, though I they use their own CPE code which may not be the same as OpenWRT:
https://www.ripe.net/media/documents/Richard_Patterson_-_Sky_Italia_and_MAP-T_-_RIPE_Open_House_2021.pdf

https://map46.cisco.com might be a useful to verify/generate the configurations.

[facboy]

thx, that's helpful. as a matter of fact it's Sky UK, and afaik their MAP-T rollout here is based on their earlier one in italy.

the wx.yz (100.yz) is the DHCP address that the DHCP server has allocated to the WAN interface (visible in ip address). st.uv (95.uv) is whatever it has sent back and is being given to nat46 as local.v4, and isn't visible anywhere except in the logs and in nat46 control. so afaik NAT44 is happening because e.g. traffic from clients (and indeed from the box) is being NAT'd to 100.yz which is the external WAN ip as far as the box is concerned. and most (all?) traffic except ICMP is seemingly working.

what is supposed to translate from the WAN ip (100.yz) to the MAP domain (95.uv)?

going to be hard to troubleshoot further now, they've bumped me back to CGNAT now anyway.

[facboy]

ah, looks relevant: openwrt/openwrt#14449

[r-pats]

@facboy The RFC 6598 address you may be receiving via DHCPv4 is unusable. Sadly we still need to rely on DHCPv4 for authentication on ~30% of Openreach's network that doesn't support LDRA. I spoke briefly about this at the last UK IPv6 Council meeting, see this timestamp on this video for more detail.

We don't use traditional CGN, but we may have automatically disabled MAP-T on your line if we detected issues. I can reenable it if you'd like to continue to debug and get it sorted?

[r-pats]

(Expectation is that once DHCPv6 lease is established and MAP-T configured, the DHCPv4 lease should be released)

[hitech95]

@r-pats
A bit OT:
I've discovered a strange issue with UDP traffic in a multiplayer videogame (I'm in ITALY 1:1 port range openwrt stable 23.04).
This is the first game I've found that is completly unable to connect to the game servers and is throwing all sort of non descriptive issues. (cant connect, timeout, etc). BAsically I cannot play multiplayer on that specific game unless I use another internet connection.
I'm still digging into this issue as I'm not 100% sure on where the issue lie.
I've tried to figure out if there was some issue on the nat46 implementation but no visible error is thrown.

Maybe @ayourtch can give me some input on how to properly debug the translation layer.
Setting a log error higher that 2 completly locks the router (its a x86 machine) as it is logging too much traffic to dmesg.

I did a pcap on the port ranges of the game and the traffic is there, it seems with the "correct" replies.
The packet body is a binary format but the packets seems to be coherent with the documentation of the SDK of such game (ack and reply to events).
The error is thrown by the SDK and not the game itself so I think that if I try with another game suing the same multiplayer library the issue might be there.
Unfortunatly I dont have the knowhow on Unity to spin up some tech demo os such SDK to validate if the issue.

[facboy]

@r-pats hmm...tbh i just need the connection working. i'd raised a 'VPN' issue (b/c i need 1:1 mapping i think, i run VPN servers on this router) and when they replied a few hours later saying they'd addressed it, it seemed to put me onto dual stack - it reconnected almost at the exact time the email was sent and went back to a 90 address.

so if things were working correctly the IP4 wan interface should not have had an address at all? it was that private address (in 100.64) being filtered by nat46, but this only seemed to affect ICMP. it didn't seem to affect other IP4 traffic, though i had some MTU problems at first.

[ayourtch]

@hitech95 old TAC wisdom from 25 years ago: “one issue = one case” :-) please move the comment into a new one, and we can ponder over there, and I expect that it may be useful to others as a template.

[facboy]

@r-pats actually it's kinda bugging me, i'd like to help get it working. i do need 1:1 (i believe) because i have VPN servers, so if you put it back to map-t can you ensure it's 1:1? it seems like the proposed map.sh script changes would make it functional so if i got that working locally with ICMP it would be a start.