In a similar vein what about nftables that has a rule that packets to a first port will be dropped unless a request packet has been received on a second port optionally with a specific identifier read from the request packet. A bit like knocking on a specific window and optionally showing your face before the porter opens the main door?
The problem isn’t to get in, it is to get out.
If you have a commonly known communication port open, like udp 1194 for example and the bots finds it, well they do find it because they only pings important registerd ports.
Then they just want to wreck havoc and drowns a home router with packages for 30min.
When they do that more and more times per day it becomes a pretty big problem sooner or later because everything is just fine on the inside of the firewall but nothin gets in or out to the internet.
If they get 10 reply packets and then nothing for 6 seconds, and then 1 reply packet, and then nothing for 6 seconds, and 1 more... It seems unlikely that they'll flood your router with tens of megabits per second of packets, which is kind of minimum bandwidth most people have.
Everything is always expected to happen so fast…
In real life this is a process that grows over months and up to a year when the bots have finally found a valuable target.
well the point is they won't think you're so valuable if they can't get you to reply except sporadically.
I've had an ssh available router protected by something like this for a decade, so far no massive DDOS floods or anything like that.
+1; when you are already in the "cross-hairs" of a sufficiently motivated adversary things are different, but to avoid the run-of-the-mill opportunistic attacks, "you do not need to run faster than the lion, as long as you are not the slowest in the group running away", meaning a small speed-bump might all that is required to make deeper attacks not worthwhile...
3 Likes
Hi,
not really sure this is the right place to ask my question, I am a bit a a loss.
I recently upgraded my router to the latest stable release and I now also have firewall4. In the past I was using fw3 combined with the ipset package for which I wrote a couple of specific rules.
I have been reading the fw4 documentation, but I cannot find anything about ipset support.
Also I've tried installing the ipset package again, but that fails with a version conflict on the kernel (I'm running ACWifidude's custom build for Netgear R7800).
So currently I'm running my firewall without all my custom rules using ipset and I don't have a clue on how to fix this 
Does anyone have any tips or tricks for me on how to get this up & running again ?
Thanks for your help in advance.
How about here:
https://wiki.nftables.org/wiki-nftables/index.php/Sets
And here:
https://wiki.nftables.org/wiki-nftables/index.php/Moving_from_ipset_to_nftables
Hi Lynx,
thanks for your reply, actually I didn't have a look at these links yet (mainly searched the openwrt pages).
But having read these I'm still not sure how to correctly configure my firewall using fw4.
In my /etc/config/firewall file I now have this for example:
config ipset
option name 'unassigned_ips'
option match 'src_ip'
option enabled '1'
option storage 'bitmap'
option iprange '192.168.5.0-192.168.5.255'
option entry '192.168.5.200-192.168.5.249'
config rule
option src 'lan'
option ipset 'unassigned_ips'
option target 'REJECT'
option name 'reject-unassigned-forward'
option proto 'all'
option dest 'wan'
And in the past this was translated (by LUCI ?) into rules for iptables/ipset.
Now with the 22.03 release these are also somehow interpreted and configured for nftables, if I look at the firewall status page of my router I see this.
But this rule isn't working, ip's in the range .200 till .249 should have been blocked from accessing the wan, but that's no longer working.
I have a hard time matching the two links you posted to whatever I need to change in my /etc/config/firewall, any clue on how to proceed on this ?
1 Like
Please post the output of fw4 print to see how the set was declared/translated.
Ah, that is probably a useful command 
First I get a couple of error messages about the ipset's I define, for example:
Section @ipset[6] (unassigned_ips) option 'storage' is not supported by fw4
Section @ipset[6] (unassigned_ips) option 'iprange' is not supported by fw4
Then I see the sets being defined as follows:
set unassigned_ips {
type ipv4_addr
elements = {
192.168.5.200,
}
}
So it looks like only the first ip-address is actually used as part of the set.
Then the rules are defined as follows (removed couple of rules not related to 'unassigned'):
chain forward_lan {
meta nfproto ipv4 ip saddr @unassigned_ips counter jump reject_to_wan comment "!fw4: reject-unassigned-forward"
}
So I guess now I at least need to update my /etc/config/firewall and remove the unsupported options 'storage' and 'range', and then figure out how to tell fw4 to create an ipset containing all ip-adresses between .200 and .249.
Then looking at Sets - nftables wiki I'm wondering on how to do that.
A step forward, but still not sure about the solution 
You should specify a CIDR block, but that is a difficult IP range to convert to a CIDR (at least it is for me with only 1 cup of coffee so far).
You can also use the loadfile syntax to populate the set from a file.
1 Like
I circumvented my problem by not using ipsets anymore.
Compared to my previous setup I now just modify the rules to have specific source addresses with a netmask, e.g. I changed the rule posted above to:
config rule
option src 'lan'
option src_ip '192.168.5.224/27'
option target 'REJECT'
option name 'reject-unassigned-forward'
option proto 'all'
option dest 'wan'
That seems to work and this doesn't rely on ipsets.
The only sad thing now is that I need to renumber al my ipsets so they match with a specific number of bits in the netmask. Previously I could just use ranges of ip-numbers, e.g. x.x.x.200-x.x.x.249 where I now need to align these with a netmask, e.g. x.x.x.192/27 and x.x.x.224/27.
It's workable just a little less flexible.
Any suggestions on why a port might not open correctly over ipv6, but the same port opens correctly for IP4?
You’re doing it wrong or putting it in the wrong place. Hard to tell from the example you gave. 
There’s this useful tip from @InkblotAdmirer earlier in the thread for debugging.
1 Like
Yea, i can see your thoughts being a possibility especially the "putting it in the wrong place" statement. I can see how the rule list is set up how easy it would be to confuse placement.
I am assuming if i was using the webui to open the port, then it should in theory be placing the rule in the correct spot. This is using the nftable layout.
Why don’t you show us the rule from /etc/config/firewall and the resulting rule from nft list ruleset? I don’t think the LuCI interface is geared toward IPv6 port forwards (NAT6). You might need to manually insert a family option in your rule.
As per my original question, I am merely trying to open a port. It is intended to access a local service on the router over ipv6. Wan side. So i used the webui to set up such a rule on firewall traffic page. I chose ipv6 as the family.
The problem is, even after opening the port, it is not visibly open. I run a scanner on the port and it comes back unreachable.