IPv6 connection tracking weirdness

RouterOS General
1

I recently deployed IPv6 to a network and noticed several of the devices on the LAN didn’t have a proper firewall setup and services were accessible to the internet. I attempted to fix this by adding a filter rule to drop all new incoming non-ICMPv6 connections as follows:

/ipv6 firewall filter add action=drop chain=forward connection-state=new dst-address-list=!exempt-firewall in-interface=ether1 log=yes out-interface=ether2-master protocol=!icmpv6

This does correctly block inbound connections, but I also see instances of regular traffic being dropped as well:

mar/07 14:01:52 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:401c:18::a]:443->[my_prefix:c5de:f2fe:dbee:784b]:56565, len 1240 
mar/07 14:02:20 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:401c:18::a]:443->[my_prefix:c5de:f2fe:dbee:784b]:56565, len 1240 
mar/07 14:28:08 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:4007:17::8]:443->[my_prefix:c5de:f2fe:dbee:784b]:57550, len 1240 
mar/07 14:28:37 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2607:f8b0:4007:17::8]:443->[my_prefix:c5de:f2fe:dbee:784b]:57550, len 1240 
mar/07 14:46:41 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f20d:1c4:face:b00c:0:43fe]:443->[my_prefix:c1a6:42f8:8f1b:d0c6]:56975, len 160 
mar/07 14:46:51 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:110:face:b00c:0:2]:443->[my_prefix:c1a6:42f8:8f1b:d0c6]:56990, len 160 
mar/07 14:47:10 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:1:face:b00c:0:1]:443->[my_prefix:c1a6:42f8:8f1b:d0c6]:56971, len 96 
mar/07 14:47:15 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f20d:1c4:face:b00c:0:43fe]:443->[my_prefix:c1a6:42f8:8f1b:d0c6]:56975, len 96 
mar/07 14:47:24 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:110:face:b00c:0:2]:443->[my_prefix:c1a6:42f8:8f1b:d0c6]:56990, len 96 
mar/07 14:53:45 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK,PSH), [2607:f8b0:4007:80c::2002]:443->[my_prefix:10a7:e1b1:6127:a17b]:63734, len 657 
mar/07 14:53:55 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK,PSH), [2607:f8b0:4007:80c::2002]:443->[my_prefix:10a7:e1b1:6127:a17b]:63734, len 657 
mar/07 14:54:05 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK,PSH), [2607:f8b0:4007:80c::2002]:443->[my_prefix:10a7:e1b1:6127:a17b]:63734, len 657 
mar/07 14:54:15 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK,PSH), [2607:f8b0:4007:80c::2002]:443->[my_prefix:10a7:e1b1:6127:a17b]:63734, len 657 
mar/07 15:02:45 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:110:face:b00c:0:2]:443->[my_prefix:68f6:a452:644:3f3f]:57011, len 96 
mar/07 15:03:05 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:110:face:b00c:0:2]:443->[my_prefix:68f6:a452:644:3f3f]:57014, len 96 
mar/07 15:20:47 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:115:face:b00c:0:3]:443->[my_prefix:5892:488a:488d:625f]:54805, len 96 
mar/07 15:21:11 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:110:face:b00c:0:2]:443->[my_prefix:5892:488a:488d:625f]:54803, len 96 
mar/07 15:21:18 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:1:face:b00c:0:1]:443->[my_prefix:5892:488a:488d:625f]:54806, len 96 
mar/07 15:21:48 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:1:face:b00c:0:1]:443->[my_prefix:5892:488a:488d:625f]:54808, len 96 
mar/07 15:21:50 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:115:face:b00c:0:3]:443->[my_prefix:68f6:a452:644:3f3f]:57035, len 96 
mar/07 15:22:18 firewall,info forward: in:ether1 out:ether2-master, src-mac 00:01:5c:xx:xx:xx, proto TCP (ACK), [2a03:2880:f00d:1:face:b00c:0:1]:443->[my_prefix:68f6:a452:644:3f3f]:57045, len 96

The source IPs are Google and Facebook and from what I can tell these seem to be parts of legitimate connections (ACK and PSH flags). I understand conntrack can terminate a connection tracking entry when it sees a FIN for example, and then you will usually see spurious FIN,ACK packets but in this instance I’m not logging any FINs anywhere and some of the packets are obviously full of data (len 1240 / len 657) so I’m worried that this is actually breaking IPv6 traffic for the clients.

I’m thinking of moving to two separate rules, one to block SYN and one to block new UDP instead, but I’m curious why I’m seeing this in the first place.

2

This has puzzled me too, and all I’ve found out is that disabling IpV6 on the sites involved solves the problem.
I’m no expert in Ipv6, but I added a couple of rules to the forward chain that accepts related and accepted, but that does not work.
Apparently the connection tracking that works so well in IPv4 does not work (or is not implemented) in IPv6.

The result is as I said, that I have to disable IPv6 on certain sites, mostly Google and Facebook, because they are sending RST and ACK packets back that is not getting acknowledged.
I don’t know if there is a standard for connection tracking in IPv6, but if it is, then Mikrotik completely ignores it (like they do with DHCPv6).

One other answer could be that Google and Facebook do send packets with some flags missing, so that they actually is invalid.
I’d love to get more input on this, especially on what the standards are, but the world seem to be silent at the moment.

3

I was googling for “Mikrotik IPv6 not tracked properly” and found this post.

My IPv6 firewall behaviour is similar to the OP even though the rules themselves differ. The point is; it seems there is something wrong with IPv6 connection tracking or there are a whoooole lot of servers (or perhaps routers?) which have a faulty implementation.

4

Surely we’re not the only ones having these issues…?

5

If you look under the raw table you will see there are rules there that by default disabled connection tracking for ipv6. The referenced /ipv6 firewalls connection set enabled= doesn’t exist for me, but if you add rules of higher priority that accepts the traffic before it hits the “no track” action then connection tracking will function as expected.

6

I have looked in WinBox as well as SSH to find this no-track rule in the IPv6 firewall of which you speak.

However, no such rule seems to exist. Am I missing something?

7

I’m having the same issue, did anyone solve this?

8

The default IPv6 firewall setup (as in: default on non-pro MT devices) doesn't have any such problem as described in this thread. So if you have any problems with IPv6 firewall, then make an effort and describe your issues thoroughly (in a new thread).