Yikes! - fw3 defaults to allowing NAT forwards

[vevere]

@lleachii

, refrain from placing such rules in the custom area. That area is best used used for rules that can't reduce to UCI syntax.

Hi,
First sorry for my English, it is not my native language.

And, just to be clear, I like a lot OpenWRT despite things I don't like on this distro (nothing can be perfect), I use it directly on my FTTH 300/300mbps line on a x86_64 mini-pc with VLANs, vlan priorisation (necessary because of my ISP), Wireguard, adblock etc .... so it was not easy to make all working

About this subject I can understand the 2 positions.

I'm an IT guy but not (not at all !!) a network's guy (working mostly on servers rooms+vmware+system to make things simple) and not even a security guy. I can't imagine how a "not IT guy" can understand anything about that stuff.

And, for my day to day needs, I almost never understand anything to the OpenWRT documentation when I need it (and when this doc exists and when it is not completly obsolete).

This existing doc it perhaps very well done .... but in my opinion only for those who already know what we are talking about. So it looks like a doc written by ... and for ... those who already know is not very usefull for all the others.

I don't want to blame anybody, writing good docs is almost more difficult that doing the code itself .. and less interesting.

As an exemple (I took the first that came too me, I don't want anyone trying to explain SNAT today to me ... it's just an exemple):

Ok, those who know what is SNAT don't need to read this at all.
But in my case I (really) don't know what is SNAT ... and I simply didn't understand this chapter and what should be the difference(s) between DNAT/SNAT/Masquerading.
I also didn't understand how this can be done differently than manually (SNAT can also be done manually: .... also !

That's the same thing in many many many computer bioses:
Function Foo: yes/no with the comment: Used to enable the Foo fonction clap clap clap, thank you, very usefull

Same thing here (just another exemple, I really don't care about that today):

I have many (really, many) exemples of bad/incomplete/incomprehensible/non-existent doc for OpenWRT and I unfortunatly have no enough time to investigate for each new need.

So, for those who know how things work inside OpenWRT: stop telling us: that's not the good way to do, or, you dindn't understand the way it works, or, you have done a bad choice, or, do your homework before asking .... please just explain and/or redirect the guy wich is asking something to a good piece of documentation, we will be happy to learn how to do that well

because that's simply not so easy, neither it is accessible for everybody.
Many guys (like me, like @stringer ) do a lot of efforts/search to understand these things, to do what they can to have a better router/firewall to protect their home network (many ISP or commercial routers are bad with many backdoors and no security updates, so it is smart to try to replace them with a great piece of software like OpenWRT)

I read really too often replies like I read here from guys who knows to guys who ask ... it is not very kind.
Because many things are not explained about how things work inside OpenWRT. Many things are hidden inside OpenWRT, and these choices were not explained to us.

And for you, those who know, you can't even figure out that it's impossible to find the correct information for those who don't yet know how these things work

Almost all the documentation is done the same way (with short tutorials/exemples about the most common needs/use cases, and .... that's all, no explanation, nothing more) where it should perhaps be better to list/explain all the available functions instead. We (I) have no enough time to go on each package's Github to read all the code to discover wich option/variable do what.

And, as I told early, English is not my native language, I try to make a lot of efforts in this aspects but sometime the documention uses very complexe sentences/words/concepts for many guys (at least for me) and things can be very confusing

Last aspect, the beginning of the firewall doc tells:

... but nowhere .. NOWHERE ... on this doc it is explained how to do that with LUCI ... you can only find how to do that with the configuration files.

Even the most beginning of the firewall configuration doesn't visually match the configuration files organisation if you don't carrefully understand how it works on the files vs how it works on Luci, it is at least very confusing .. and if you don't understand why I'm saying that it is because you already know how it works for too long and so you are not able anymore to understand why it should be hard for some non-already-linux-firewall-aware guys (it is not my config, I took that on Google images):

Just to help to understand what I mean:

• the left and right parts are independant on the firewall file (forwarding between defined zones on the left -- ONE zone configuration on the right) ... not on Luci because on the same line
• the right part (zone configuration) doesn't care about the forwarding destination, it only cares about the source zone defined on the left

.... but, because it is on the same line it is confusing.
A newcomer (like me a short time ago) will naturaly think that the right part is used to configure the left part, but it is not the case

There should be a better solution to display that no ? (just an example, remember)

Regards
Herve

[lleachii]

@vevere

But in my case I (really) don't know what is SNAT

Then why are you looking at it?

Wouldn't you go to a site like this instead of a router manual:

SNAT vs DNAT: Detailed Comparison Table - IP With Ease

@vevere

That's the same thing in many many many computer bioses:
Function Foo: yes/no with the comment: Used to enable the Foo fonction clap clap clap, thank you, very usefull

???

@vevere

Same thing here (just another exemple, I really don't care about that today)

Why do you assume a router manual will tell you these things???

TCP window scale option

You have not once showed an example of an iptables rule you are trying to place into OpenWrt.

@vevere

... but nowhere .. NOWHERE ... on this doc it is explained how to do that with LUCI ... you can only find how to do that with the configuration files.

Did you actually look????

@vevere

Even the most beginning of the firewall configuration doesn't visually match the configuration files organisation if you don't carrefully understand how it works on the files vs how it works on Luci

No, you did not look:

@vevere

.... but, because it is on the same line it is confusing.

Regarding zones:

Recommended firewall settings

First of all, that isn't a LAN to WAN setting of Reject. The enable LAN to WAN is the graphic to the Left of that - under the column "Zone => Forwardings". That entire row is the Zone-based firewall settings for LAN. Each row configures the Zone named on its extreme Left. I believe LAN was accept intra-zone forwarding by default (more on how to find out below). Nonetheless, what you circled is the forwarding of a packet FROM THE LEDE TO ANOTHER ROUTER IN THE SAME ZONE. Most consumers don't use…

@vevere

There should be a better solution to display that no ?

???

@vevere

English, it is not my native language

Welcome to the OpenWrt Project

(If you don't know firewall terms, but are looking at a router's manual in the firewall section...how do you know what you want to configure?)

EDIT: And I digress, I realized you are not the OP.

[vevere]

An ex-boss told me something like that a long time ago:
I you take time to read things more carefully you will write less useless replies (sorry hard to translate and I don't want to offence anybody)

My reply never talked about technical aspects but about how guys reply to others here in this forum and how hard it is to find good or up to date OpenWRT information.

So I was just asking everybody to understand that one guy (here @stringer) created this post to inform about a problem he had (and found a solution for) to help others if they are facing the same problem.

And I just don't really agree with the replies he received.
I have no technical question.

I faced the same kind of replies some weeks ago about IPv6 questions, and because lacks in the OpenWRT documentation it was hard and so I made some errors/mistakes before asking the community, I received not pleasant replies. despite the time I spent to try to understand how to made this well.

So I just wanted to ask "those who know" to be gentle with "those who ask"

That's all
Herve

[lleachii]

@vevere

I faced the same kind of replies some weeks ago about IPv6 questions

I know, I read it and participated. I also wondered why you didn't use the config provided by HE on thier site.

I assumed you knew what you were doing (since you told us what you wanted to do with the prefixes), and choose NOT to read the OpenWrt and HE manual.

[vevere]

that's not the subject here but I wanted to do something that IS NOT REALLY EXPLAINED in the doc.
I started with the openwrt+he doc (and it worked fine) and, after, I had another need (split the 3 prefixes, one from my ISP and the 2 from HE and never give 2 of them to the same downstream interface/network) and it was not easy until someone talked to me about iface aliases that are configurable on the config files (not on luci).

OpenWRT is very powerfull, but it is hard to find the configuration options needed to use this power

it is 5AM here, I have to go to bed
by

[sqwuade]

I run https://www.fail2ban.org/ and it only allows like a given number of attempts to connect before requiring a waiting period. Works for SSH and a lot of other protocols as well. Cheers!

[lleachii]

@sqwuade

and it only allows like a given number of attempts to connect before requiring a waiting period. Works for SSH and a lot of other protocols as well.

For those who may be short on flash space, rules can also be added to OpenWrt, SSH samples below:

# time DROP rule
config rule
	option src 'wan'
	option name 'SSH_CheckDrop'
	option family 'ipv4'
	option proto 'tcp'
	option dest '*'
	option dest_port '22'
	option target 'DROP'
	option extra '--syn -m recent --name ssh --update --seconds 300 --hitcount 5'

# ACCEPT if above DROP criteria not met
config rule
	option target 'ACCEPT'
	option family 'ipv4'
	option proto 'tcp'
	option src 'wan'
	option dest_port '22'
	option extra '--syn -m recent --name ssh --set'
	option name 'SSH_CheckAccept'
	option dest '*'

# this connlimit rule is also an example of applying the rule to a different WAN DST ports than tcp/22
# fix if you will use tcp/22
config redirect
	option target 'DNAT'
	option src 'wan'
	option dest 'lan'
	option proto 'tcp'
	option src_dport 'xxxxxxxx-xxxxxxx'
	option dest_port '22'
	option name 'SSH-ConnectLimit'
	option extra '--syn -m connlimit --connlimit-above 3'

# add here normal port forward(s) from WAN to the `src_dport` listed in connlimit - to SSH server LAN IP/port

Should work for whatever you can configure in proper syntax.

[vgaetera]

It's best to not expose Dropbear/uHTTPd to the internet if you really care about security.
That's because a single critical vulnerability could be enough to grant root privileges to the attacker.