Why doesn't this /120 ipv6 subnet route?

Question

I think I am missing a very simple detail, and an answer to my question already exists, but I don't know what words to use to search, so with apologies, I ask this question:

In my Linux VPS host I am assigned the ipv6 address 2001:db8:X:Y::25:785c/112 on interface eth0; I want to subnet this into two /120 subnets, one for use on the VPS host and the other routed via VPN to another site via interface tuns0. The problem is that pings from the other remote office are not routed to my VPS provider and onto the internet; they reach the VPS host through the VPN tunnel, but the VPS host seems to fail to resolve the router's MAC address because it asks the question "Neighbor Solicitation for 2001:db8:X:Y::1" with the ?wrong? source and/or destination address.

The questions

1. How does the Linux kernel decide what source address to use on the local eth0 when sending Neighbor Solicitation on behalf of the remote office?
2. What did I miss when I set up this subnet?

My configuration

The interfaces are:

# ip -6 addr list eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2001:db8:X:Y::25:785c/120 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3cff:fe2e:4906/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

# ip -6 addr list tuns0
85: tuns0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1423 state UNKNOWN qlen 100
    inet6 2001:db8:X:Y::25:61/120 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2de4:df93:3c60:d6f6/64 scope link flags 800
       valid_lft forever preferred_lft forever

The remote office is assigned the address 2001:db8:X:Y:25:1060/120

The routing table is:

# ip -6 route list
unreachable ::/96 dev lo metric 1024 error -113 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 error -113 pref medium
unreachable 2002:a00::/24 dev lo metric 1024 error -113 pref medium
unreachable 2002:7f00::/24 dev lo metric 1024 error -113 pref medium
unreachable 2002:a9fe::/32 dev lo metric 1024 error -113 pref medium
unreachable 2002:ac10::/28 dev lo metric 1024 error -113 pref medium
unreachable 2002:c0a8::/32 dev lo metric 1024 error -113 pref medium
unreachable 2002:e000::/19 dev lo metric 1024 error -113 pref medium
2001:db8:X:Y::1 dev eth0 proto static metric 100 pref medium
2001:db8:X:Y::25:1000/120 dev tuns0 metric 1024 pref medium
2001:db8:X:Y::25:7800/120 dev eth0 proto kernel metric 256 pref medium
unreachable 3ffe:ffff::/32 dev lo metric 1024 error -113 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev tuns0 proto kernel metric 256 pref medium
default via 2001:db8:X:Y::1 dev eth0 proto static metric 100 pref medium

Kernel forwarding is enabled:

# sysctl net.ipv6.conf.{eth0,tuns0}.forwarding
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.tuns0.forwarding = 1

Firewall:

# ip6tables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      *      tuns0   ::/0                 ::/0
 3307  344K ACCEPT     all      tuns0  *       ::/0                 ::/0
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    3   216 ACCEPT     icmpv6    eth0   *       ::/0                 ::/0                 ipv6-icmp !type 128 code 0

The symptoms

When pinging from the remote office to a public ip, this happens:

# ping6 -c 1 2606:4700::6810:85e5
PING 2606:4700::6810:85e5(2606:4700::6810:85e5) 56 data bytes

--- 2606:4700::6810:85e5 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

The wireshark trace on the VPS host shows:

Capturing on 'eth0'
  1 0.000000000 fe80::216:3cff:fe2e:4906 -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::1 from 00:16:3c:2e:49:06
  2 1.001850169 fe80::216:3cff:fe2e:4906 -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::1 from 00:16:3c:2e:49:06
  3 2.003817526 fe80::216:3cff:fe2e:4906 -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::1 from 00:16:3c:2e:49:06

  4 3.005863618 2001:db8:X:Y::25:785c -> ff02::1:ff25:1060 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::25:1060 from 00:16:3c:2e:49:06
  5 4.007810968 2001:db8:X:Y::25:785c -> ff02::1:ff25:1060 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::25:1060 from 00:16:3c:2e:49:06
  6 5.009819429 2001:db8:X:Y::25:785c -> ff02::1:ff25:1060 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::25:1060 from 00:16:3c:2e:49:06

I note two kinds of discoveries in this trace, and the VPS provider's router never responds; based on the successful trace below, I think the kernel should have used the tuple "2001:db8:X:Y::25:785c -> ff02::1:ff00:1" for its NS requests. I would love an explanation as to why it chose the addresses it did.

When I ping from the Linux host, the Neighbour Discovery requests are different, the router responds, and the ping succeeds:

Capturing on 'eth0'
  1 0.000000000 2001:db8:X:Y::25:785c -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation for 2001:db8:X:Y::1 from 00:16:3c:2e:49:06
  2 0.001160390 2001:db8:X:Y::1 -> 2001:db8:X:Y::25:785c ICMPv6 86 Neighbor Advertisement 2001:db8:X:Y::1 (rtr, sol, ovr) is at 74:8e:f8:71:a3:00
  3 0.001180977 2001:db8:X:Y::25:785c -> 2606:4700::6810:85e5 ICMPv6 118 Echo (ping) request id=0x5033, seq=1, hop limit=0
  4 0.002499763 2606:4700::6810:85e5 -> 2001:db8:X:Y::25:785c ICMPv6 118 Echo (ping) reply id=0x5033, seq=1, hop limit=0 (request in 3)

Answer 1

Answering my own question as I figured out the issue.

The VPS provider connects my VPS to a virtual ethernet network and the VPS relies on Network Discovery Protocol to find the router. A similar configuration was documented in this blog which was very useful; the term "NDP proxy" is the word I didn't know as the relevant term to google.

Solution

1. The kernel needs to respond to NS queries on the eth0 interface for IPs it knows how to route on other interfaces:

net.ipv6.conf.eth0.proxy_ndp = 1

2. Individual IPs that the kernel is to respond for must be configured with:

ip -6 neigh add proxy 2001:db8:X:Y::25:1060 dev eth0

3. If the VPS is KVM, a solution like ndpresponder is essential, because by default some KVM hypervisors are configured to drop link-local Neighbour Discovery Advertisements, which causes the router to never receive these proxied responses. This program sends the advertisement responses from the global unicast address instead, so they are not dropped by the KVM hypervisor. When using ndpresponder, proxy_ndp features are not used.

Thank you @u1686_grawity for the help. It turns out it's not the size of the IP that matters, but how you use it.