Hi,

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?

TIA Banjo

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.

Aha! Problem solved. I corrected the firewalld rule for accepting fe::/7 to fe00::/7 and now ND is working properly.

I thought ND used ipv6-icmp, but using a firewalld rule to accept protocol 58 didn't help. It has to be a rule to accept source-addr=fe00::/7

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?

there may be another problem with clients running MS Windows:
https://superuser.com/questions/984502/ ... by-default

posting here for reference.

it may be solved by disabling WoLAN and WoWLAN (if you are not using) because there seems to be no other solution.

set RA delay to 0 (zero)

hello dear mikrotik team

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.

thanks a lot

best regards

set RA delay to 0 (zero)

Hello, I did so but still it is same.

Hello,

I am having the same issue.. can anyone advise pls?