diff --git a/Frequently-Asked-Questions.md b/Frequently-Asked-Questions.md
index 2c9f3f6..e1bd99c 100644
--- a/Frequently-Asked-Questions.md
+++ b/Frequently-Asked-Questions.md
@@ -10,7 +10,7 @@ Most likely this is because of a slightly too high (or missing) MTU setting on t
 Setting the MTU higher than the physical medium causes IP to fragment each inner packet into several outer packets and reassemble them at the receiving side. This has the advantage that VpnCloud has to process less packets and therefore uses less CPU (most of it will be memcpy) and has less context switches. It will also save some bytes on the wire as less bytes are used for VpnCloud headers and UDP headers and only a small additional IP fragmentation header is added. I think in total that is the 2% you are seeing.
 The downside is that if one of the outer packets gets lost on the wire the whole inner packet is lost. If your MTU is is 40 times higher than normal, 40 outer packets will be sent for one inner packet. So your packet loss rate will be about 40 times higher than normal (e.g. 4.1% instead of 0.1%). It will also influence your delay distribution negatively. 
 If the delay distribution and the loss ratio matters to you, this is a bad idea. If your line is pretty good and you just care about throughput, I think it makes sense to increase the MTU.
-([Full thread in #2](../../issues/2))
+([Full thread in #2](../issues/2))
 
 
 ##### Does VpnCloud support IP multicast?
@@ -19,10 +19,10 @@ VpnCloud has no special support for multicast and I did not test any multicast s
 1) If you use a TAP device, IP multicast should be mapped to ethernet broadcast and just work (although being a little bit inefficient)
 2) If you use a TUN device with the default router mode IP multicast packets should be dropped as no node claims the IP multicast region.
 3) If you use a TUN device with the learning switch mode, the multicast packets should be broadcast and multicast should just work (although being a little bit inefficient)
-Other VPN software either does not implement multicast (like VpnCloud currently) or cheats by broadcasting it. Proper multicast support is somewhat complicated as several control protocols for IPv4 and IPv6 have to implemented. ([Full thread in #12](../../issues/12))
+Other VPN software either does not implement multicast (like VpnCloud currently) or cheats by broadcasting it. Proper multicast support is somewhat complicated as several control protocols for IPv4 and IPv6 have to implemented. ([Full thread in #12](../issues/12))
 
 
 ##### What does this "non-native forwarding mode" mean?
 
 There are two device types TUN and TAP and the only difference between them is that TUN transports IP packets and TAP transports Ethernet frames.
-All the rest is about how VpnCloud decides where packets/frames should be sent to. In routed mode each node claims one or more address regions by prefix and all the nodes match against those prefixes. In switch mode, nodes learn addresses by looking at the source addresses and broadcast for unknown addresses. Routed mode is native to TUN devices and switched mode is native to TAP devices but there is no reason not to use switched mode for TUN devices. ([Full thread in #12](../../issues/12))
+All the rest is about how VpnCloud decides where packets/frames should be sent to. In routed mode each node claims one or more address regions by prefix and all the nodes match against those prefixes. In switch mode, nodes learn addresses by looking at the source addresses and broadcast for unknown addresses. Routed mode is native to TUN devices and switched mode is native to TAP devices but there is no reason not to use switched mode for TUN devices. ([Full thread in #12](../issues/12))