ipv6 ping host got destination host unreachable until run tcpdump

Question

At first (all computer booted) when I ping the gateway (linux computer, two network cards(one is usb)) from a windows computer, I got: "Destination host unreachable", but when I run "tcpdump -i LANINTERFACE ip6" on the gateway, the ping got reply from gateway, what's wrong with my network, any ideas?
The gateway and windows computer use static ipv6 address.

ipv6 configuration for gateway:

# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: enp0s29f0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::1111/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe53:4458/64 scope link
       valid_lft forever preferred_lft forever
5: enp2s0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::3333/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:d3ff:feb3:34a5/64 scope link
       valid_lft forever preferred_lft forever

On Windows Computers(Use the following IPv6 address,static):

IPv6 address: 2001:XXX:YYYY:ZZZZ:WWWW::6666
Subnet prefix length: 64
Default Gateway: 2001:XXX:YYYY:ZZZZ:WWWW::1111

Linux gateway route table:

# ip -6 route
2001:XXX:YYYY:ZZZZ::/64 dev enp0s29f0u2  proto kernel  metric 256
2001:XXX:YYYY:ZZZZ::/64 dev enp2s0  proto kernel  metric 256
fe80::/64 dev enp0s29f0u2  proto kernel  metric 256
fe80::/64 dev enp2s0  proto kernel  metric 256
ff00::/8 dev enp0s29f0u2  metric 256
ff00::/8 dev enp2s0  metric 256
default via fe80::1614:4bff:fe60:63eb dev enp2s0  metric 5

I got one linux box as router(enp2s0,enp0s29f0u2), and others are windows computers. The 'Wan' connected to linux box adapter enp2s0, and enp0s29f0u2 connected to a wireless router(switch mode (dhcp off)), all windows pc connected to wireless router.

Answer 1

There is one obvious mistake in the configuration of your gateway. Both interfaces have been configured with the same /64.

In a correct configuration you use the link prefix you got from your provider on the WAN interface, and you use the routed prefix you got from your provider on the LAN interface. If the routed prefix is shorter than a /64 (which it is supposed to be), then you can pick any /64 out of that /48 for your LAN. For example if your provider gave you routed prefix 2001:db8:1234::/48, your LAN prefix could be 2001:db8:1234::/64, 2001:db8:1234:ffff::/64, 2001:db8:1234:babe::/48, or any of the 65533 other possibilities.

What happens when you run tcpdump is that it (by default) turns the network interface into promiscuous mode, which means the hardware will start accepting Ethernet frames even if they were not send to the MAC address of that network interface.

It is not obvious how those two could possibly be connected. But it is possible to formulate a hypothesis which can then be tested.

It may be that upon receiving neighbor discovery requests, the gateway responds with the MAC address of the other interface. This is at least a plausible behavior considering that both interfaces are configured with the same /64. But as packets are send to that other MAC address, the network interface will drop them until the network interface is switched into promiscuous mode.

There is a number of things you can do to test this hypothesis:

• Run tcpdump without promiscuous mode (-p switch). If tcpdump helps in promiscuous mode but not otherwise, we have confirmed that promiscuous mode makes a difference.
• Observe what MAC address is sent in neighbor discovery replies and compare that to the two network interfaces.
• Observe the destination MAC address on packets send to the IP address to see which MAC address they are sent to (this can be done using Ethereal or tcpdump in promiscuous mode).
• Reconfigure the interface which was configured with incorrect network prefix to see if it helps.