I noticed this firewall rule in a newly flashed lede-17.01 installation
It has no name or other documentation, and I can't find any information on the lede-project.org website.
config rule
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
While we're at it, what's this other unnamed rule?
config rule
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
Those are for IPSec VPN forwarding
Ah. Interesting!
Is there an SCR for adding names to these built-in rules?
[code]config rule
option name 'Allow-ESP-Forward'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-L2TP/IPSec-Forward'
option src 'wan'
option dest 'lan'
option dest_port '500 4500'
option proto 'udp'
option target 'ACCEPT'
[/code]
So were those changes made after the 17.01 release? My build didn't contain the names or the port 4500 change?
No, same here. I added those names and port 4500 when I was adding my custom rules in firewall.
Default firewall rules below
[code]# allow IPsec/ESP and ISAKMP passthrough
config rule
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT[/code]
Ok Cool.
This seems like something that should be properly documented in the default configuration files.
Any reason I shouldn't open a new bug in flyspray, do you think?
amm not a bug and the default rule does the job just fine.
Firewall rules that are installed by default, and provide no documentation as to why it exists, or what benefit it provides a user/admin, is absolutely a bug.
I'd prefer that the bug be fixed with documentation, but removing the undocumented rules would also be acceptable in my opinion.
I'll open a bug in flyspray. Thanks!
Well, the config file has a short header explaining that rule:
# allow IPsec/ESP and ISAKMP passthrough
And the commit history reveals the reasoning for that rule:
"firewall: comply with REC-22, REC-24 of RFC 6092"
https://git.lede-project.org/?p=source.git;a=commitdiff;h=f6abd042c29f5a69d56151f884fbf4f4e834e674;hp=1b6a6abf0439177cba1fdea3ae91a7354fe74841
https://tools.ietf.org/html/rfc6092
REC-22 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of packets, to and from legitimate
node addresses, with an upper-layer protocol of type
"Encapsulating Security Payload (ESP)" [RFC4303] in their
outer IP extension header chain.
REC-24 In their DEFAULT operating mode, IPv6 gateways MUST NOT
prohibit the forwarding of any UDP packets, to and from
legitimate node addresses, with a destination port of 500,
i.e., the port reserved by IANA for the Internet Key Exchange
(IKE) Protocol [RFC5996].
That's great!
However, documentation in the form of # style comments doesn't show up in LUCI.
[quote="jonesmz, post:11, topic:2220"]
However, documentation in the form of # style comments doesn't show up in LUCI.
[/quote]No, it doesn't. (And actually editing the config file with either LuCI or uci removes the # comments from the config file.)
Openwrt & LEDE have always been size-constrained and have tried to store as little as possible in the precious flash memory. So most of the documentation is no included in the flashed firmware. (And note that there are hundreds or thousands of settings included. You shouldn't expect to find docs about all of them to be included in the firmware...)
Bluntly said, you need to trust that the default settings are sensible, but if you want actual proof about that, you need to dig into the source code to see the relevant commits that usually contain explanations about the changes.
What missing documentation? 
It's already clearly written in the default rules what it suppose to do. If you want to know more about the rule just Google it!
And if it's bothering you so much just add the god damn option name line and be done with it.
There are far more important things that needs fixing, I don't think anyone has time for this.
By missing documentation, maybe I should instead be saying
Things that show up by default in LUCI shouldn't be allowed to have no human readable text explaining why it's there
Hnyman kindly indicates that the default # style documentation is:
# allow IPsec/ESP and ISAKMP passthrough
Changing that to
option name 'Allow-ESP-Forward'
and
option name 'Allow-L2TP/IPSec-Forward'
Respectively is a change of (31+38+indentation*2)-50, or an increase of
19 bytes + indentation*2
Surely we can sacrifice that many bytes in the default installer, pre-compression?
As for whether I should just add the "god damn option name line and be done with it"
If everyone just "did the thing and be done with it" on their own without consulting the broader community, there wouldn't be much of a community would there? It may be that you find this to be a trivial non-issue, but I don't. Maybe there are no other people in the LEDE-Project community that care about this, and if that's the case, great, just leave the bug that I opened in flyspray open indefinitely or close it as wont-fix. But surely you at least acknowledge that this is a specific, constrained well defined complaint that can be "fixed" with a 3-5ish line patch?
Perhaps the next time you have to change a default-installed configuration file to add basic information as to what it's even doing, you'll consider fixing it for everyone, instead of only yourself?
@jonesmz is absolutely correct. I don't understand why some people feel the need to make up silly excuses for what is obviously a bug. If you look in that same file, there are many other rules with option name lines (Allow-Ping, Allow-DHCPv6, etc.)
The reason why those two rules don't have names is that they used to be just commented-out examples. They wouldn't show up in LuCI anyway, so there was no need for a name. Later, they were uncommented, and the fact that they didn't have a name was overlooked.
Open a bug, suggest a fix. This is a community-driven project, do you want to be a part of the community or part of the problem? 
Did open a bug.
Did suggest a fix.
Bug got closed as wontfix.
Argued with person who closed the bug, finally got him/her to agree that it was a problem worth fixing.
Fix landed in git a week after my conversation on flyspray.
Not much of a community-driven project if even trivial-to-fix problems get responses such as "I don't think anyone has time for this.", or other comments that dismiss the complaint (too numerous to list, but just read this thread), or the reported bug gets marked as "wontfix".
I'd like to claim the status of "not a moron". I work as a software engineer for a living, I'm not new to submitting bugs to open source projects. Most of the time when I report bugs, I don't get responses anywhere near as hostile as I did in this thread.
Then again, a lot of the time, I just get ignored, which isn't either better or worse. So shrug.