Can you explain forward IPv6 drops go to drop_to_wan?

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi

I added logging to OpenWRT for dropped packet to my router’s IPv4 and the router’s IPv6 address I just added a rule to “drop_from_wan”. Logging works great.

However in order to get logging of dropped packets from the Internet on IPv6 to internal GUA Ipv6 addresses. I needed to add to “drop_to_wan” i.e.

chain drop_to_wan {
iifname { "eth1", "pppoe-wan" } meta l4proto udp log prefix "DROP " # Added rule
iifname { "eth1", "pppoe-wan" } tcp flags & (fin | syn | rst | ack) == syn log prefix "DROP " # Added rule
oifname "pppoe-wan" counter packets 0 bytes 0 drop comment "!fw4: drop wan IPv4/IPv6 traffic" # standard OpenWRT rule
}

This works. But Questions:

Surely this means packets that are blocked from coming in from the Internet are not explicitly dropped? Cause the drop rule here is for pkts oifname of the WAN interface? This is dropping things that shouldn’t be allowed out to the Internet? Not things (which are of more concern) things coming from the Internet?

As in this drop would need to be like my logging rules and have a drop on the iifname of “pppoe-wan” in my case?

Given this is the last rule in forward if “drop_to_wan” this is what this does, but given that dropped forwarded IPv6 packets from the Internet end up here it’s a strange name and usage in forward.

Can someone explain how IPv6 WAN packets destined for an internal GUA are getting dropped and the thinking behind this (surely the plan isn’t to rely on the policy drop just)?

The chain for this is

chain forward {

.
iifname "pppoe-wan" jump forward_wan comment "!fw4: Handle wan IPv4/IPv6 forward traffic"

}

chain forward_wan {
.
jump drop_to_wan
}

chain drop_to_wan {
oifname "pppoe-wan" counter packets 0 bytes 0 drop comment "!fw4: drop wan IPv4/IPv6 traffic"
}

So no I’m really confused. An Ipv6 packet from wan that will be dropped, hits. iifname "pppoe-wan" jump forward_wan (it’s come in pppow-wan after all), then hits “jump drop_to_wan” from forward_wan but never will hit “oifname pppoe-wan” (as it came in “pppoe-wan” and didn’t leave there).

Can someone explain this?

2

Try this https://github.com/openwrt/firewall4/pull/60

3

Thats zone forward ie drop stuff forwarded between multi-wans, then global default {reject) kicks in.

edit

more practical example would be to make 2 lan subnets at home in same zone and easily forward between them.

Actual purpose of dropping is providers with leaky switches where dhcp client would set wan iface to promiscuous mode and firewall happily spoofing "reject" action.

REF https://github.com/openwrt/firewall4/commit/97962771aa3c490d6186e64015f85dd66254fdf0

4

Your default forward policy in the firewall is likely DROP. The wan zone forward policy is also DROP. But as brada4 mentions, the drop_to_wan within forward_wan is meant to control forwarding between multiple interfaces in the wan zone, but you only have one interface, so it doesn't really do much.

The dropping of unwanted forwarded packets from the wan are dropped by the forward chain policy drop. Normal dropped packets would fall straight through drop_to_wan without being touched and get dropped by the forward chain.

Your logging rules you put in drop_to_wan could have more reasonably gone into an include section at the end of forward_wan and avoiding the confusion of drop_to_wan.

5

Ah. I didn’t consider the WAN to WAN case.

Thank you all for clarifying that the drop is supposed to be by the default policy and not an explicit rule in all cases.

6

It is not a specific case: it is tech debt that traffic leaking to our port is acted upon. PROMISC effectively bypasses mac filter in netcard, solution would be something like fib ... local or rp_filter so that fw works independently from traffic being captured or not.