FAQ : Connectivity (Tunnels and Subnets) : Transit / I have some other tunnels and now it doesn't workTransit / I have some other tunnels and now it doesn't workWhen you have multiple tunnels or upstreams, that is including mechanisms like 6to4 and Teredo, then you should make care that you properly apply source routing. When you don't do this, packets sourcing from a different prefix than what has been assigned to you by SixXS will be sent from your host to the SixXS PoP, which will drop that packet as the source address does not match the address that has been assigned to you. Some PoPs send an ICMPv6 "Administratively Prohibited" message back in this case. We are not willing to haul other AS'es traffic over our tunnels to you, nor do we accept it from you. We refuse to route your other network space over our infrastructure. It is not the fact that you should not use your tunnel, but that when you use it, that you route the correct space, which is the prefix you got delegated from the PoP for that tunnel. Make sure that when you have a subnet that you nullroute this block. This avoids sending traffic destined to unrouted blocks in your subnet back up your tunnel. These packets would then be sourced out of the external address space. On a Linux system one could use something similar to:
ip6tables -A FORWARD -o ${TUNNEL} -s ${SUBNET} -j ACCEPT
ip6tables -A FORWARD -o ${TUNNEL} -s ff00::/8 -j ACCEPT
ip6tables -A FORWARD -o ${TUNNEL} -j LOG
ip6tables -A FORWARD -o ${TUNNEL} -j DROP
BSD example using pf (Packet Filter):
block return in log-all quick on ! ${TUNNEL} inet6 from ! ${SUBNET} to any
This will only allow packets going outbound sourced from your subnet. Anything else will be logged and then dropped. Similar things can also be accomplished on the various BSD's and other systems. Also see: |