Since the 4.8.2 update, it seems that every time the firewall service is restarted, it re-adds a series of firewall rules regarding VPN DNS leak protection. I was wondering if anyone has any pointers as to where these are coming from? I already have them incorporated into my own rules, and since my router has a scheduled reboot every night, I’d like to stop them constantly regenerating.
Cheers.
Hi
These firewall rules are defined in /usr/bin/rtp2.sh.
If you’d like, you can modify this file to better suit your specific use case.
We strongly recommend making a backup of the file first, so that if anything goes wrong, you can easily restore it and ensure VPN client continues to work properly.
You could also take the file from the read only firstboot partition (factory defaults) 
cp -rf /rom/usr/bin/rtp2.sh /usr/bin/ && chmod +x /usr/bin/rtp2.sh
That will safe you from reseting the full device if the backup also went wrong.
Ah. I was too busy looking at various startup scripts for the firewall service itself; missed that rtp2.sh has an include inside the firewall config. I should’ve slept before posting. Many thanks.
I would suggest not removing the vpnclient include itself from the firewall config. You can comment out the various set_ functions in rtp2.sh for killswitch_dns and route_leak_block etc. which add the firewall & network rules (at the time of writing, for v4.8.2, around lines ~1187 → 1449). This will not remove any existing rules, but be entirely certain that your current configuration works before doing this (and be mindful that it will no longer be there to bail you out if you make future breaking changes to your VPN config).
For low-risk stuff like this, you can block-comment in shell scripts by enclosing them in a dummy comment function,[1] named to your choosing (eg: YOURNAME_COMMENT_DISABLED() { … } ) – and, of course, as per will.qiu, backup first.
Where the worst that would happen if the function was somehow called, is that you'd end up with a few duplicate firewall rules – I would advise not using this method on more consequential code. ↩︎
FYI: The proper way to disable code in a shell script is to just throw # in front of the lines. It'll also appear quite pronounced if using syntax highlighting. A function will not.
What also works, atleast this was before the newer vpn dashboard but I suspect it still works.
Let the rule generate, disable rule in luci inside the traffic rules tab in the firewall section, this prevents it from re-creating and keeps it disabled.
For the firewall zones that can idd be become problematic.
The problem with the edit of the command, is for each firmware update this will be overwritten in the firmware.
You can use /etc/sysupgrade.conf but you will lose track if actually fixes got added to that file.
FYI: The proper way to disable code in a shell script is to just throw
#in front of the lines. It'll also appear quite pronounced if using syntax highlighting. A function will not.
Yes, I am aware, and I suspect most others are too. This is, however, for over 200 lines. That is why I explicitly specified it as a method of block commenting, which is perhaps less well-known, given that shell scripts do not have a built-in method for that. I'm not really here for a pedantic debate on the merits of each method of commenting out shell scripts; rather, I'm simply dropping it as a potentially useful solution to anyone else who comes across this.
Let the rule generate, disable rule in luci inside the traffic rules tab in the firewall section, this prevents it from re-creating and keeps it disabled.
In my experience, that is unfortunately not the case. On reboot, it does re-enable some of these rules on me (I'm not quite sure what the criteria is that's causing it to be inconsistent, but it is at least the same rules every time).
I realise I'll lose this on upgrade, but a one-off at a time when I'll already be inherently logged-in and hands-on is, to me, the more tidy solution.
I think you've mixed your responses.
(If you're block commenting/mangling 100+ lines of a GL firmware stock script that won't be persevered on future firmware updates then you're already doing it wrong. You have a Flint v2; just install pure OWRT.)
this is exactly one of my reasons to go to vanilla OpenWrt.
I'm a big advocate to have GL firmware as less restrictive as possible and also as interopability friendly as possible with OpenWrt, yet it happens which prevent more advanced user custominization.
it was already a bit better (previously they where just iptables etc), but I feel they go downwards again.
-edit-
It's also the annoyance you can get, maybe now it is maybe only this change, but most of the times you keep building more advanced, then this firmware would only be annoying, this also happened with OpenWrt to some extend at a point I wanted my own base configuration burned in, especially for dumbaps that is awesome when reseting back to factory will not have the firewall 
The only scenarios I still use this firmware is for simple scenarios, mostly client scenarios like on a travel router, but the extreme routing and exotic configuration is done on the server which is OpenWrt.
I think you've mixed your responses.
(If you're block commenting/mangling 100+ lines of a GL firmware stock script that won't be persevered on future firmware updates then you're already doing it wrong. You have a Flint v2; just install pure OWRT.)
Or, hear me out: I could do what I’ve already done – which took <2 minutes & works fine – and be sufficiently satisfied at that, since “techno-elitism” and “the approval of children & pedants” aren’t among my list of priorities.
If you had actually stopped to think for a second before rushing to post your “correction”, you might also have realised that this topic is regarding multiple firewall rules in uci format. Which is, somewhat inherently, a lot of lines.
And y’all wonder why folk don’t want to contribute to OSS projects. glhf.
You give bad advice & got called on it. I script using uci batch calls & write in POSIX. There's nothing difficult or impressive about it. If you had actually stopped to think for a second before rushing to post your "workaround", you'd know GL.iNet is closed source firmware, ya'll.
You read the words that I said, even quoted them, and yet still understood them with all the wisdom of a 3-year-old staring at the Mona Lisa. Your reply was, ironically, nothing but elitism and pedantry.
Someone else shared something with me that was helpful for solving my problem. I tried it myself, tested it in a few scenarios, and it worked! I figured I’d share it for anyone else who came along and was in a similar position to me.
You decided to show off your myopic technical knowledge by shouting down someone who was trying to help other folk.
I’m a retired dude screwing around with an all-in-one router at home. Sysadmin I ain’t. There’s a reason I’m not “just” reflashing OpenWRT. To me, and likely most folk using this with its default firmware, we’re here to find something that directly fixes our issue in a way that doesn’t involve “reinstalling your entire router”. How deep down the sysadmin rabbit-hole you are is an irrelevant and frankly cringe-worthy side-show.
I had actually unsubscribed from this topic and was going to leave it be, but then you sent me an actual private message to… insult my avatar and, uh, call me a “punk”? Which is actually a compliment, but nevermind. Either way, utterly unhinged behaviour.
Please grow up. If you’re an actual professional sysadmin, this is an attitude you should’ve left behind a long time ago.
If you think any of this is rooted in either elitism or pedantry then yours is a case of mediocrity.
You don't sign my paychecks & I don't take orders from you.
Do you mean something like this? Or do you mean like this? Perhaps you meant this.
Rationalize it any way you want to protect your frail ego but you still don't know what it is you don't know yet you think you're in some sort of position to be advising others to mangle their firewall — of all things & especially when it's related to VPN functionality — & it is, somehow, some way, to be considered sound reasoning. If you're as old as you claim to be then it might be time to check for early onset.
You didn't "solve" anyone's problem — you created new, critically severe ones.
You may wish to re-read the original post, where I noted, quite specifically, that it was in relation to firewall conditions which already existed in other rules. Nothing has been mangled. You didn’t even stop to check what, exactly, was being commented. Instead, you… sent out another insulting private message lacking any semblance of self-awareness. This is deeply pitiful. I’m going to disengage now.
You've been mentally disengaged for more than a few, it seems.
uci set [...] enabled='0'. Boy, that sure was hard work disabling dat dem dere firewall rule, huh, Cleetus?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
