6to4 Tunnel - RB send packets for LAN to the internet

Hi,

i discovered a strange behavior with my IPv6 setup.
The IPv6 connectivity is established via 6to4 tunnel. It worked well for a long time, but now there is a problem with the address routing: The RB sends packets for my internal subnet through the 6to4 Tunnel :open_mouth:
I don’t know why. Maybe someone can give me a quick advice.
All firewall rules are deactivated, but even this do not help :frowning:

Here is the configuration:

>ipv6 address print
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local 
 #    ADDRESS                                     FROM-... INTERFACE        ADV
 0  G ;;; 6to4public
      2002:592:a630::1/16                                  6to4-iface       no 
 1  G ;;; 6to4subnet
      2002:592:a630:2::1/64                                bridge1          yes
 2 DL fe80::20c:42ff:fe65:d45c/64                          wlan1            no 
 3 DL fe80::20c:42ff:fea8:ce37/64                          bridge1          no 
 4 DL fe80::20c:42ff:fea8:ce2f/64                          ether1           no



>ipv6 route print
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 X S  ::/0                     6to4-iface                      1
 1 A S  2000::/3                 6to4-iface                      1
 2 ADC  2002::/16                6to4-iface                      0
 3 ADC  2002:592:a630:2::/64     bridge1                         0

Traceroute to one of the clients (provided via stateless autoconfiguration). Packets for the client address are send through the 6to4 tunnel -Why ???

 tool traceroute 2002:592:a630:2:3e07:54ff:fe4d:b10c
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 2002:c058:6301::1                  0%    1  11.8ms    11.8    11.8    11.8       0       
 2 2002:592:a630::1                   0%    1  12.2ms    12.2    12.2    12.2       0       
 3 2002:c058:6301::1                  0%    1  23.7ms    23.7    23.7    23.7       0       
 4 2002:592:a630::1                   0%    1    24ms      24      24      24       0       
 5 2002:c058:6301::1                  0%    1  35.6ms    35.6    35.6    35.6       0       
 6 2002:592:a630::1                   0%    1    36ms      36      36      36       0       
 7 2002:c058:6301::1                  0%    1  49.6ms    49.6    49.6    49.6       0       
 8 2002:592:a630::1                   0%    1    48ms      48      48      48       0       
 9 2002:c058:6301::1                  0%    1  67.8ms    67.8    67.8    67.8       0       
10 2002:592:a630::1                   0%    1  59.9ms    59.9    59.9    59.9       0       
11 2002:c058:6301::1                  0%    1    72ms      72      72      72       0       
12 2002:592:a630::1                   0%    1  71.8ms    71.8    71.8    71.8       0       
13                                  100%    1 timeout                                       
14 2002:592:a630::1                   0%    1  86.1ms    86.1    86.1    86.1       0       
15 2002:c058:6301::1                  0%    1  95.9ms    95.9    95.9    95.9       0       
16 2002:592:a630::1                   0%    1 105.5ms   105.5   105.5   105.5       0       
17                                    0%    1     0ms                                 TRUNCATED

UPDATE:
Looks like the RB ignores the /64 route. Changing the /16 Prefix to /64 and deactivating the 2000::/3 route, result in timeouts for the trace.

Got it.
Since 2012 the linux kernel support mutiple routes for ipv6 or something like that. For this reason the /16 subnet is used to determine the interface for my IPv6 prefix. Obviously IPv6 routing is a little bit different to IPv4…

Anyway. I deactivated the IPv6 adress on the 6to4 Interface and it works :slight_smile:

Hint: The wiki entry for ā€œSetting up an IPv6 tunnel via 6to4ā€ (http://wiki.mikrotik.com/wiki/Setting_up_an_IPv6_tunnel_via_6to4) do not work for me, because there is a /3 subnet on the 6to4 interface. This configuration will cause the same problem as my /16 subnet :frowning: