ping6 request from client to NAT64 server not forwarded to nat64 interface

[rohit7855]

Hi,

Consider me a novice to ipv6 domain. I have prepared RHEL based DNS64 / NAT64 server using ecdysis solution.
DNS64 and NAT64 works perfectly fine for ping6 request to ipv4 only sites, when the ping6 is generated on machine hosting DNS64 / NAT64 but not if the ping6 is generated from client machine ( 64 bit freeBsd) using DNS64 / NAT64 sever.

My objective is to use use this machine as DNS64 / NAT64 server for different client machines.

1.  Following is the config of machine hosting DNS64 / NAT64 :

[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:50:56:A9:33:52 
          inet addr:10.217.71.140  Bcast:10.217.71.255  Mask:255.255.248.0
          inet6 addr: fe80::250:56ff:fea9:3352/64 Scope:Link
          inet6 addr: 2001:db8:0:f101::3/96 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6951811 errors:0 dropped:0 overruns:0 frame:0
          TX packets:52922 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:622107203 (593.2 MiB)  TX bytes:6799148 (6.4 MiB)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          inet6 addr: 2001:db8:0:f101::21/96 Scope:Global
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1957 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1957 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:283427 (276.7 KiB)  TX bytes:283427 (276.7 KiB)

nat64     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

virbr0    Link encap:Ethernet  HWaddr 52:54:00:0C:5F:30 
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2532 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:119304 (116.5 KiB)


[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# route -n -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
64:ff9b::/96                                ::                                      U     1024   0        0 nat64   
2001:503:ba3e::2:30/128                     2001:503:ba3e::2:30                     UC    0      1        0 eth1   
2001:db8:0:f101::/96                        ::                                      U     256    0        0 eth1   
2001:dc3::35/128                            2001:dc3::35                            UC    0      1        2 eth1   
fe80::/64                                   ::                                      U     256    0        0 eth1   
fe80::/64                                   ::                                      U     256    0        0 virbr0 
::/0                                        ::                                      U     1024   0        0 eth1   
::1/128                                     ::                                      U     0      110       1 lo     
2001:db8:0:f101::/128                       ::                                      U     0      0        1 lo     
2001:db8:0:f101::/128                       ::                                      U     0      0        1 lo     
2001:db8:0:f101::3/128                      ::                                      U     0      3604       1 lo     
2001:db8:0:f101::21/128                     ::                                      U     0      3882       1 lo     
fe80::/128                                  ::                                      U     0      0        1 lo     
fe80::250:56ff:fea9:3352/128                ::                                      U     0      99       1 lo     
ff02::1/128                                 ff02::1                                 UC    0      1        0 eth1   
ff00::/8                                    ::                                      U     256    0        0 eth1   
ff00::/8                                    ::                                      U     256    0        0 virbr0 

[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
10.217.64.0     0.0.0.0         255.255.248.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth1
0.0.0.0         10.217.64.1     0.0.0.0         UG    0      0        0 eth1

2. Following is the nat64_config.sh setting
IPV4_ADDR="10.217.71.140"
PREFIX_ADDR="64:ff9b::"
PREFIX_LEN="96"

3. The ping6 yahoo.com onto server machine itself gets successful
    i) For ping6 -I eth1 yahoo.com
    ii) Following is the tcpdump at eth1 interface
    tcpdump -uvi eth1 icmp6
    11:27:43.719453 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::3 > ff02::1:ff37:48b7: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 64:ff9b::4137:48b7
          source link-address option (1), length 8 (1): 00:50:56:a9:33:52
11:27:43.891464 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::3 > ff02::1:ff00:1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:7fd::1
   iii) Following is the tcpdump at nat64 interface
     tcpdump -nvi nat64 icmp6
tcpdump: WARNING: nat64: no IPv4 address assigned
tcpdump: listening on nat64, link-type RAW (Raw IP), capture size 65535 bytes
11:31:05.949960 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:db8:0:f101::21 > 64:ff9b::4137:4887: [icmp6 sum ok] ICMP6, echo request, length 64, seq 5
11:31:06.205672 IP6 (hlim 235, next-header ICMPv6 (58) payload length: 64) 64:ff9b::4137:4887 > 2001:db8:0:f101::21: [icmp6 sum ok] ICMP6, echo reply, length 64, seq 5


4. Following is the configuration at client machine ( freebsd machine)
   
snpqa-FB# ifconfig
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 18:03:73:f0:f3:cb
        inet 10.217.71.126 netmask 0xfffff800 broadcast 10.217.71.255
        inet6 fe80::1a03:73ff:fef0:f3cb%bce0 prefixlen 64 scopeid 0x1
        inet6 2001:db8:0:f101::2 prefixlen 96
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
bce1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 18:03:73:f0:f3:cd
        media: Ethernet autoselect (none)
        status: no carrier
bce2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 18:03:73:f0:f3:cf
        media: Ethernet autoselect (none)
        status: no carrier
bce3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c01bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 18:03:73:f0:f3:d1
        media: Ethernet autoselect (none)
        status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3<RXCSUM,TXCSUM>
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>

snpqa-FB# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.217.71.140      UGS         0        2   bce0
10.217.64.0/21     link#1             U           1     3072   bce0
snpqa-FB           link#1             UHS         0        0    lo0
10.217.109.54      10.217.64.1        UGHD        1      209   bce0
localhost          link#5             UH          0      214    lo0

Internet6:
Destination        Gateway            Flags      Netif Expire
::                 localhost          UGRS        lo0 =>
default            2001:db8:0:f101::3 UGS        bce0
localhost          localhost          UH          lo0
::ffff:0.0.0.0     localhost          UGRS        lo0
2001:db8:0:f101::  link#1             U          bce0
2001:db8:0:f101::2 link#1             UHS         lo0
fe80::             localhost          UGRS        lo0
fe80::%bce0        link#1             U          bce0
fe80::1a03:73ff:fe link#1             UHS         lo0
fe80::%lo0         link#5             U           lo0
fe80::1%lo0        link#5             UHS         lo0
ff01:1::           fe80::1a03:73ff:fe U          bce0
ff01:5::           localhost          U           lo0
ff02::             localhost          UGRS        lo0
ff02::%bce0        fe80::1a03:73ff:fe U          bce0
ff02::%lo0         localhost          U           lo0

5. ISSUE : ping6 at client machine gets stucked ( no message on console)
   snpqa-FB# ping6 yahoo.com
                   PING6(56=40+8+8 bytes) 2001:db8:0:f101::2 --> 64:ff9b::d1bf:7a46

above message shows that it has successfully resolved the name using DNS64

6. Following is the tcpdump for eth1 interface at DNS64 / NAT64 server machine

[root@csapi-qa-zab-01 ~]# tcpdump -nvi eth1 icmp6
11:39:51.541113 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0
11:39:51.947264 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::baac:6fff:fe83:7fe4 > ff02::1:ff00:3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fec0:0:0:ffff::3
          source link-address option (1), length 8 (1): b8:ac:6f:83:7f:e4
11:39:52.541157 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 1
11:39:52.947223 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::baac:6fff:fe83:7fe4 > ff02::1:ff00:3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fec0:0:0:ffff::3
          source link-address option (1), length 8 (1): b8:ac:6f:83:7f:e4
11:39:53.540129 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 2
11:39:54.540122 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 3
11:39:55.540136 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 4
11:39:56.540151 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 5
11:39:56.540151 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:0:f101::2 > 2001:db8:0:f101::3: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:0:f101::3
          source link-address option (1), length 8 (1): 18:03:73:f0:f3:cb
11:39:56.540206 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) 2001:db8:0:f101::3 > 2001:db8:0:f101::2: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is 2001:db8:0:f101::3, Flags [router, solicited]
11:39:57.540141 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 6
11:39:58.540126 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) 2001:db8:0:f101::2 > 64:ff9b::481e:268c: [icmp6 sum ok] ICMP6, echo request, length 16, seq 7

7. Request not getting forwarded to nat64 interface as tcpdump at nat64 interface doesn'r show up any message

Kindly suggest if I am missing out some route mapping to get the ping6 request from remote machine forwarded to nat64 interface

Regards
Rohit

[kasperd]

Have you enabled forwarding of both IPv4 and IPv6 packets on the NAT64 server?

[rohit7855]

Have you enabled forwarding of both IPv4 and IPv6 packets on the NAT64 server?

Yes ipv6 forwarding is enabled:
Following is the proc/sys file values in NAT64 server machine

[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/all/forwarding
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/all/autoconf
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/eth1/forwarding
1
[root@csapi-qa-zab-01 ~]# cat /proc/sys/net/ipv6/conf/eth1/autoconf
1

[kriteknetworks]

I thought I'd read ping doesnt work when using ecdysis....I went with tayga for nat64 anyway, didnt require kernel modification.

[rohit7855]

I thought I'd read ping doesnt work when using ecdysis....I went with tayga for nat64 anyway, didnt require kernel modification.

ping6 perfectly works with ecdysis because when I am doing ping6 yahoo.com onto server machine hosting DNS64 / NAT64, it gets successfully resolved.

[kasperd]

I just realized you have no public IPv4 address on that machine. Though multiple layers of NAT can work in principle, it is not a good idea to do so. I don't know if that is related to your problem or not. You didn't include the necessary packet dumps to see what happens to the IPv4 packets.

[rohit7855]

I just realized you have no public IPv4 address on that machine. Though multiple layers of NAT can work in principle, it is not a good idea to do so. I don't know if that is related to your problem or not. You didn't include the necessary packet dumps to see what happens to the IPv4 packets.

IPv4 ping command gets succesfully executed:

1. Following is the snapshot of ping yahoo.com from client machine. routing table on client machine is set to forward the IPv4 packet to NAT64/DNS64 server machine as default rule:

snpqa-FB# ping yahoo.com
PING yahoo.com (72.30.38.140): 56 data bytes
92 bytes from 10.217.71.140: Redirect Host(New addr: 10.217.64.1)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0054 01ad   0 0000  3f  01 b8fb 10.217.71.126  72.30.38.140

64 bytes from 72.30.38.140: icmp_seq=0 ttl=44 time=281.713 ms
64 bytes from 72.30.38.140: icmp_seq=1 ttl=44 time=283.519 ms
64 bytes from 72.30.38.140: icmp_seq=2 ttl=44 time=277.960 ms
64 bytes from 72.30.38.140: icmp_seq=3 ttl=44 time=321.895 ms
64 bytes from 72.30.38.140: icmp_seq=4 ttl=44 time=294.657 ms


2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :

[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
    10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
    10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)

[kasperd]

2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :

[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
    10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
    10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)

So the echo requests are translated and send, but you do not receive any reply. Why do you think this is a problem with the NAT64?

You should verify that those echo requests have correct checksums. I don't know if you can do that with tcpdump. You can verify the checksum by writing the full packets to a file with tcpdump (e.g. -s 0 -Uw filename), and then load the file in wireshark (you may need to right click on the checksums to enable verification).

Still the packets are leaving your NAT with private addresses. Do you have another layer of NAT? You are going to get better reliability if you use only one layer of NAT.

[rohit7855]

2. Following is the tcpdump onto server machine eth1 interface for request originating from src as client machine ip :

[root@csapi-qa-zab-01 ecdysis-nf-nat64-20101117]# tcpdump -uvi eth1 src host 10.217.71.126
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:55:41.527133 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.217.71.126 is-at 18:03:73:f0:f3:cb (oui Unknown), length 46
13:55:49.703368 IP (tos 0x0, ttl 64, id 295, offset 0, flags [none], proto UDP (17), length 55)
    10.217.71.126.54901 > 10.217.71.140.domain: 57089+ A? yahoo.com. (27)
13:55:49.703786 IP (tos 0x0, ttl 64, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.703825 IP (tos 0x0, ttl 63, id 296, offset 0, flags [none], proto ICMP (1), length 84)
    10.217.71.126 > ir2.fp.vip.bf1.yahoo.com: ICMP echo request, id 43781, seq 0, length 64
13:55:49.704211 IP (tos 0x0, ttl 64, id 298, offset 0, flags [none], proto UDP (17), length 72)
    10.217.71.126.43800 > 10.217.71.140.domain: 57090+ PTR? 140.71.217.10.in-addr.arpa. (44)
13:56:53.044827 IP (tos 0x0, ttl 64, id 428, offset 0, flags [none], proto UDP (17), length 55)

So the echo requests are translated and send, but you do not receive any reply. Why do you think this is a problem with the NAT64?

You should verify that those echo requests have correct checksums. I don't know if you can do that with tcpdump. You can verify the checksum by writing the full packets to a file with tcpdump (e.g. -s 0 -Uw filename), and then load the file in wireshark (you may need to right click on the checksums to enable verification).

Still the packets are leaving your NAT with private addresses. Do you have another layer of NAT? You are going to get better reliability if you use only one layer of NAT.

In case of Pv4 ping request from client the NAT doesn't comes into picture. As per the server machine IPv4 routing table the IPv4 requests are directly forwarded to gateway machine 10.217.64.1 , bypassing the nat64 interface.
The problem comes for IPv6 ping request from client. As per server machine IPv6 routing table all the the packets with destination 64:ff9b:: should get forwarded to nat64 interface for NAT translation, which is not happening in actual and creating the issue.

[kasperd]

The problem comes for IPv6 ping request from client. As per server machine IPv6 routing table all the the packets with destination 64:ff9b:: should get forwarded to nat64 interface for NAT translation, which is not happening in actual and creating the issue.

According to the tcpdump output you posted, the packet was never send from the client to the server. Instead the client was sending a bogus neighbor solicitation packet asking for the MAC address of 64:ff9b::4137:48b7. That means the routing table on the client must be incorrect.

The routing table you posted from the client is not any use in debugging the problem since all the prefixes are listed without a length. So find a way to view the actual routing table on the client and post that. Then I'll try to explain what is wrong with the routing table.

On a closer look that spurious neighbor solicitation appears to be from the server rather than from the client. That's even more weird. Because that implies the server send the neighbor solicitation without first receiving the packet. Additionally the routing table you posted from the server shouldn't cause this.

The routing table on the server does have a bogus entry

::/0                                        ::                                      U     1024   0        0 eth1   

If that was the one matching the packet, then it would indeed cause the spurious neighbor solicitation because that routing table entry is missing a next hop. However the packet should have matched a different entry in the routing table

64:ff9b::/96                                ::                                      U     1024   0        0 nat64   

And that entry looks correct to me. I'd still fix the incorrect routing table entry.