IPv6 Firewall is not blocking

RouterOS General
1

I am confused why my IPv6 Firewall Setup is accepting connections to the router itself.
I only configured on the internal interface an IPv6 Address to advertise it to lan.
The log shows that Policy ID 3 is allowing it. What is here wrong?
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local

ADDRESS FROM-POOL INTERFACE ADVERTISE

0 DL fe80::66d1:54ff:fe62:ea12/64 eth1-A1 no
1 DL fe80::66d1:54ff:fe62:ea14/64 vlan2 no
2 DL fe80::66d1:54ff:fe62:ea14/64 eth3-m-EG no
3 DL fe80::66d1:54ff:fe62:ea13/64 eth2-TMA no
4 DL fe80::c/64 pppoe-TMA no
5 G 2001:beef:200:f00::1/64 TMA eth3-m-EG

Flags: X - disabled, I - invalid, D - dynamic
0 ;;; defconf: accept established,related,untracked
chain=forward action=accept connection-state=established,related log=no log-prefix=“”

1 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid

2 ;;; LAN>WAN
chain=forward action=accept in-interface=eth3-m-EG log=no log-prefix=“”

3 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related log=no log-prefix=“”

4 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid

5 ;;; LAN Input
chain=input action=accept in-interface=eth3-m-EG log=no log-prefix=“”

6 X ;;; defconf: accept ICMPv6
chain=input action=accept protocol=icmpv6 log=no log-prefix=“”

7 ;;; defconf: accept UDP traceroute
chain=input action=accept protocol=udp port=33434-33534

8 ;;; defconf: accept DHCPv6-Client prefix delegation.
chain=input action=accept protocol=udp src-address=fe80::/16 dst-port=546

9 ;;; defconf: drop packets with bad src ipv6
chain=forward action=drop src-address-list=bad_ipv6

10 ;;; defconf: drop packets with bad dst ipv6
chain=forward action=drop dst-address-list=bad_ipv6

11 ;;; defconf: rfc4890 drop hop-limit=1
chain=forward action=drop protocol=icmpv6 hop-limit=equal:1

12 ;;; defconf: accept ICMPv6
chain=forward action=accept protocol=icmpv6

13 ;;; defconf: accept HIP
chain=forward action=accept protocol=139

14 ;;; Drop all packets which are not destined to routes IP address
chain=input action=drop dst-address-type=!local in-interface=pppoe-TMA log=no log-prefix=“”

15 ;;; drop everything
chain=forward action=drop in-interface=pppoe-TMA log=no log-prefix=""Can somebody explain?

2

Rule 3 allows any packet which is part of an established or related packet flow according to connection tracking.
The first packet of connection attempts won’t match this rule, so you may need to dig a little deeper.

What sort of connections are you seeing which are being accepted but shouldn’t?
e.g. Winbox, ssh, http, etc…

If you want to find out which rule is accepting the first packet, you can make a temporary rule like this:
(assuming that your connection attempts are http requests coming from 2001:db8::1234 - change this to the real IPv6 address / protocol / port you’re testing from / to)
/ipv6 firewall filter
add chain=input action=passthrough src-address=2001:db8::1234 protocol=tcp dst-port=80

Then move this rule to the top of the input chain and watch the packets matched counter on the rule as you make your connection tests.
Move the rule further down the chain and test again. Whenever you stop seeing packets counted by the rule, you know that this rule is now after whatever rule is actually accepting the traffic.

3

Thanks for this tip.
I moved this policy below the implicit deny rule but still a match.

Flags: X - disabled, I - invalid, D - dynamic

CHAIN ACTION BYTES PACKETS

15 ;;; drop everything
forward drop 10 607 85
16 input passthrough 240 3[/codebox]

4

update
I deleted the last policy (implicit deny) and created again.
Now portscanners and unwanted traffic is blocked

5

There was probably some criteria in the old “default drop” rule which caused it not to match (like mentioning an in-interface or an address prefix or a connection state, etc)

One thing I did notice is this:

This rule will never match anything because the input chain already implies that the destination address is one of the router’s own addresses (because the input chain applies to traffic TO the router’s control plane itself).

In general a default drop rule should have no match criteria and an action=drop
Any traffic which you want to accept needs to be handled explicitly in some previous rule.