I have a KVM guest (fedora19) with a virtual NIC bridged to the physical NIC of my hypervisor(also fedora19), and I can’t reliably connect to it from a remote IPv6 subnet routing through my Mikrotik RB750GL RouterOS 6.27.
The 2 interfaces involved in the Mikrotik are a 6to4 tunnel using Hurricane Electric and a routable /48 network bridged over the 4 “local” ports.
If I ping6 the hypervisor from a server on another /48 network in another country (ipv6 firewall rules set to accept each other’s /48 networks on both Mikrotik’s) then I always get a reply.
If I ping6 the KVM guest from the same server, then there are 2 scenarios:
a) if I have done a /ping from the Mikrotik to the KVM guest from the same LAN within the last 10 seconds,
the server at the other end of the WAN gets a reply, and
/ipv6 neighbor print shows the KVM guest as stale or reachable
b) after 10 seconds have expired, or if I haven’t pinged from the local Mikrotik yet,
the server at the other end of the WAN gets an icmp unreachable from HE endpoint, and
/ipv6 neighbor print shows the KVM guest as failed
Why is the Mikrotik flagging the KVM guest as “failed” and is there anyway to override this?
As the KVM guest can route to a virtual network, I have also tried configured radvd on it, and configuring it for IPv6 routing. This makes no difference to the problem, other than that the KVM guest is now "R"outer status=failed instead of just failed.
tcpdump of the local LAN shows all the normal neighbor solicitation, neighbor advertisements, and router advertisments.
I see no reason why the Mikrotik is failing the KVM guest. Anyone got any clues? or further advice on diagnostic techniques?
Are you using the /48 natively, or have you chopped /64 subnets out of it?
(out of curiosity)
This sounds like multicast is not making it from the real world into the hypervisor world - Neighbor Discovery is a multicast ICMPv6 packet. When the guest talks first, the Mikrotik is simply noticing the MAC address of the source, and adding it to the neighbors list. When the cache entry times out, if the Mikrotik (or remote host) try to talk to the guest OS first, the ND packets are not making it to the guest.
Try running tcpdump on the guest OS to confirm that you never see the ND requests.
Otherwise, there might be ICMP filtering going on - make sure ICMP is allowed.
You guessed right I have chopped my /48 into /64 subnets. One subnet for the physical LAN, and another subnet for one of the KVM virtual networks (which isn’t bridged).
In order to get the guest to talk to other hosts on the local LAN I did have to configure firewalld to ACCEPT the local /48 network, so I know it will respond to ND solicitation (To be on the safe side I even added an ACCEPT rule for the remote /48 network) from local servers and directly from the Mikrotik itself. (Also added fe:: and ff:: ACCEPT rules too)
What I don’t understand is why the Mikrotik the ND solicitation/advertisment stuff works fine when the Mikrotik initiates the ping, and yet it doesn’t work when the Mikrotik is routing the ping.
Another odd thing I see in the tcpdump is that the ND solicitation is originating from the hypervisor rather than the Mikrotik. But the hypervisor never has an issue pinging its guest. Also the ND tables on the Mikrotik don’t list the hypervisor as a router, so it doesn’t make sense to redirect the ping via the hypvervisor.
Don’t block ICMPv6.
EDIT: rant removed - just don’t block all ICMP
Make sure nobody’s blocking it and if it still has issues, then you might break out tcpdump to see what’s going on “on the wire” - I had an issue with GNS3 and qemu-host Mikrotiks where 802.1q tags weren’t working. Turns out quemu’s ethernet driver was stripping tags at ingress! Wireshark was instrumental in discovering this.
The first few times I played with IPv6 things were broken until I stopped filtering ICMP.
You should consider not filtering it, or if your goal is to be “unpingable” then just drop pings specifically - you don’t want to drop things like UDP port unreachable messages, or even more importantly in v6: ICMP MTU exceeded messages.
IPv6 does not allow packet fragments, so path mtu discovery is crucial, and discarding ICMP willy-nilly can cause things to break in ways that you might not easily detect.
Blocking pings is not very useful in today’s world anyway IMOHO - botnets use much more sophisticated scanning technology and you can be sure that ping is not something they rely on very much. Why waste time doing a ping when you can just directly scan various services you’re targeting?
winbox accepts 3600 secs as maximum value for reachable time which is 1h.
but you wrote ms (milliseconds) on gui, could you please change it from “ms” to “s” in next update
there is also bug in the underlying logic. after 3600 milliseconds neighbour becomes stale in the list (ipv6->neighbours)
It should’ve been 1 hours. because i set reachable-time=1h in cli. but there is this milisecond bug.
