IPv6 firewall fails to function.

[Erik Edwards]

RT-AC56R 384.6 (latest for this model at time of posting)
IPv6 firewall on/off switch seems to generate a complete blockage in the "on" position and had none of the rules entered in the GUI. In the "off" position it drops bad packets, but otherwise allows nearly everything through. Anyone have thoughts on this?

 

[RMerlin]

This is how a firewall works. When a firewall is enabled, it will block everything, and you have to create rules to allow explicit traffic.

 

[Erik Edwards]

This is how a firewall works. When a firewall is enabled, it will block everything, and you have to create rules to allow explicit traffic.

Yeah, it should block everything, I understand that. What is broken is the processing of the permitted rules, they are _*completely*_ ignored.

 

[RMerlin]

Yeah, it should block everything, I understand that. What is broken is the processing of the permitted rules, they are _*completely*_ ignored.

Keep in mind that IPv6 is routed, not NATed. When configuring a rule, you must enter the correct destination IP for your device, not the router's IP if the goal is to allow traffic in for a specific device.

 

[Erik Edwards]

Here is the ip6tables -S output when the firewall is "off":
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N NSFW
-N PControls
-N SSHBFP
-N UPNP
-N logaccept
-N logdrop
-A INPUT -i eth0 -p ipv6-crypt -j ACCEPT
-A INPUT -i eth0 -p ipv6-auth -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 4500 --dport 4500 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -m state --state INVALID -j logdrop
-A INPUT -p tcp -m tcp --dport <port priv> -m state --state NEW -j SSHBFP
-A INPUT -p ipv6-nonxt -m length --length 40 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 133 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 141 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 142 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 148 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 149 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 151 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 152 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 153 -j ACCEPT
-A INPUT -j logdrop
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD ! -i br0 -o v6tun0 -j logdrop
-A FORWARD -m state --state INVALID -j logdrop
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -p ipv6-nonxt -m length --length 40 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A OUTPUT -o eth0 -p ipv6-crypt -j ACCEPT
-A OUTPUT -o eth0 -p ipv6-auth -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 4500 --dport 4500 -j ACCEPT
-A PControls -j ACCEPT
-A SSHBFP -m recent --set --name SSH --rsource
-A SSHBFP -m recent --update --seconds 60 --hitcount 4 --name SSH --rsource -j logdrop
-A SSHBFP -j ACCEPT
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP

----------------------------------------------------
Here is the same with the firewall "on":

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N logaccept
-N logdrop
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -i lo -o lo -j ACCEPT
-A logaccept -m state --state NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logaccept -j ACCEPT
-A logdrop -m state --state NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options
-A logdrop -j DROP

---------------------------------------------------
Here are my manually entered rules (with public IPv6 address partially redacted, cut/paste from GUI):

SSH-Alt ::/0 ::/0 <port priv> TCP
DNS ::/0 2001:470<priv>/128 53 BOTH
OpenVPN ::/0 2001:470<priv>/128 <port priv> BOTH
HTTPS ::/0 ::/0 443 TCP
DNSTLS ::/0 2001:470<priv>/128 853 TCP
Mail ::/0 2001:470<priv>/128 25,465,586... TCP

I know the docs say the :: doesn't need the /0, but in previous releases it has been necessary to include it otherwise it assumed a /128 on ::

Its these manually entered rules that are missing.

 

[Erik Edwards]

Keep in mind that IPv6 is routed, not NATed. When configuring a rule, you must enter the correct destination IP for your device, not the router's IP if the goal is to allow traffic in for a specific device.

Any thoughts on the missing rules?

 

[RMerlin]

Works for me. Chances are that one of your rules is invalid. Test loading the config file over SSH, it will tell you which rule is failing.

ip6tables-restore < /tmp/filter_rules_ipv6

 

[Erik Edwards]

Works for me. Chances are that one of your rules is invalid. Test loading the config file over SSH, it will tell you which rule is failing.

ip6tables-restore < /tmp/filter_rules_ipv6

I found the error. No, its not in my rule.

-A FORWARD -m state --state NEW -p tcp -m tcp -s ::/0 -d ::/0/::ffff:ffff:ffff:ffff --dport <port priv> -j ACCEPT

from this rule:
SSH-Alt ::/0 ::/0 <port priv> TCP

 

[RMerlin]

Destination IPs that start with :: are currently considered to be EUI-64 addresses, and get that mask hardcoded. Try specifying :: without the /0 mask.

 

[Erik Edwards]

Destination IPs that start with :: are currently considered to be EUI-64 addresses, and get that mask hardcoded. Try specifying :: without the /0 mask.

That results in (in the /tmp/filter...):

-A FORWARD -m state --state NEW -p tcp -m tcp -s :: -d ::/::ffff:ffff:ffff:ffff --dport <port priv> -j ACCEPT

Which results in (from ip6tables-save):

-A FORWARD -s ::/128 -d ::/::ffff:ffff:ffff:ffff -p tcp -m state --state NEW -m tcp --dport <port priv> -j ACCEPT

The /128 seems to prevent the rule from ever matching. Also the "::/::ffff:ffff:ffff:ffff" looks odd even though it is accepted by the restore process. I thought the IPv6 masks had to start from the MSB and stop with the first 0 (zero), I consider the hard coding to be a less than desirable option as /0 is a legitimate mask for a rule. Is there a specific use for placing all the 1's in the EUI64 space with only leading 0's? Could the "/::ffff:ffff:ffff:ffff" be left off if the rule already includes a user supplied mask?

 

[RMerlin]

The /128 seems to prevent the rule from ever matching. Also the "::/::ffff:ffff:ffff:ffff" looks odd even though it is accepted by the restore process. I thought the IPv6 masks had to start from the MSB and stop with the first 0 (zero), I consider the hard coding to be a less than desirable option as /0 is a legitimate mask for a rule. Is there a specific use for placing all the 1's in the EUI64 space with only leading 0's? Could the "/::ffff:ffff:ffff:ffff" be left off if the rule already includes a user supplied mask?

No idea, that feature was implemented by another developer, back in 2016.

I'll have to evaluate whether I want to keep it "as-is" or not. I'll first need to learn more about it (my knowledge of IPv6 is fairly basic, since my ISP doesn't support it, and isn't expected to support it for years).

 

[RMerlin]

I decided to fix it on both ends.

- Improved EUI64 detection by also checking the third character
- Accept empty local IP as a way to specify "Any IP"