The drop invalid rule should only apply to outgoing traffic imho, otherwise a lot of legitimate inbound traffic is dropped.
Can you try this rule instead and see if you still reproduce the leak?
iptables -t nat -A zone_wan_postrouting -m conntrack --ctstate INVALID -j DROP
Correction:
iptables -t filter -A zone_wan_dest_ACCEPT -m conntrack --ctstate INVALID -j DROP
Shows leakage (and fortunately quite immediate; GMT+1):
12:48:10.225137 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 184019810, ack 3923615243, win 16361, length 0
12:48:10.630523 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 0, ack 1, win 16361, length 0
12:48:11.441749 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 0, ack 1, win 16361, length 0
12:48:13.048601 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 0, ack 1, win 16361, length 0
12:48:16.262225 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 0, ack 1, win 16361, length 0
12:48:22.673872 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [F.], seq 0, ack 1, win 16361, length 0
12:48:35.481631 IP 10.0.0.48.49187 > 216.55.137.169.80: Flags [R.], seq 1, ack 1, win 0, length 0
12:48:48.742433 IP 10.0.0.48.49189 > 23.42.27.27.80: Flags [R.], seq 637184114, ack 2983779411, win 0, length 0
Was the rule reached? Can you check iptables --nvL zone_wan_dest_ACCEPT ?
I checked that the rule was added, yes. But, you wrote -A zone_wan_dest_ACCEPT. Shouldn't that be -I instead of -A to inject before the default ACCEPT?
With -I and after a quick test iptables -nvL zone_wan_dest_ACCEPT shows
Chain zone_wan_dest_ACCEPT (2 references)
pkts bytes target prot opt in out source destination
42 1680 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID
783 50041 ACCEPT all -- * eth0.2 0.0.0.0/0 0.0.0.0/0 /* !fw3 */
And no leakage 
i also use this on public/private borders:
#!/bin/sh
# take care of no-internet routeable addresses
mode=blackhole
mode=unreachable
ip route add $mode 0.0.0.0/8 metric 999
ip route add $mode 10.0.0.0/8 metric 999
ip route add $mode 100.64.0.0/10 metric 999
ip route add $mode 127.0.0.0/8 metric 999
ip route add $mode 169.254.0.0/16 metric 999
ip route add $mode 172.16.0.0/12 metric 999
ip route add $mode 192.0.0.0/24 metric 999
ip route add $mode 192.0.2.0/24 metric 999
ip route add $mode 192.168.0.0/16 metric 999
ip route add $mode 198.18.0.0/15 metric 999
ip route add $mode 198.51.100.0/24 metric 999
ip route add $mode 203.0.113.0/24 metric 999
ip route add $mode 224.0.0.0/4 metric 999
ip route add $mode 240.0.0.0/4 metric 999Perfect. I'll see if we can add this to the firewall program then. The idea is to emit this rule only for zones with masquerading enabled to avoid affecting unrelated/unmasked traffic.
Where do I put this?
Do I still need this if I use bcp38?
That looks pretty much like a manual implementation of the bcp38 package (with some additional blocks added to the list).
About those additional addresses, is there any reason why aren't they included in bcp38?
Somehow I can't figure out why this address is added:
ip route add $mode 192.0.2.0/24 metric 999
even though this address is already there:
ip route add $mode 192.0.0.0/24 metric 999
you can put it in rc.local (should be persistent) or in '/etc/hotplug.d/iface/' ...
it's not quite bcp38 in that it doesn't care about src addresses, but i makes sure that
traffic destined to unused private nets/bogos does not get to your upstream default router.
the list is from: http://www.team-cymru.org/bogon-bit-notation.html
Perfect. I'll see if we can add this to the firewall program then. The idea is to emit this rule only for zones with masquerading enabled to avoid affecting unrelated/unmasked traffic.
jow, does it mean you will update one of these packages:
..with this rule:
iptables -t filter -I zone_wan_dest_ACCEPT -m conntrack --ctstate INVALID -j DROP
And what do you expect the timeframe to be? 
When can one expect the firmware package to be updated too?
Sorry for the novice question
Was this fixed with LEDE 17.01.1 ? Is that LEDE version good to use v4?
AFAIK, no.
Just add the rule mentioned below to /etc/firewall.user file...
iptables -t filter -I zone_wan_dest_ACCEPT -m conntrack --ctstate INVALID -j DROP
...and after that either reboot the router or issue service firewall restart command. Now you're good to go.
Is this fixed in master somehow?