Thank you all for the additional information given =)
Appreciated!
The above posted iptables MASQUERADE rule helped me a lot.
Before this my train of thoughts derailed, because of
"ME SET NAT TO YES; WHY NEW SETTING THERE (UGH)!"
Since I was bored: I tcpdumped the setting.
Disabled.jpg shows the IP of my mobile phone 192.168.92.2 (WG client on LTE --> VPS (192.168.92.1) --> N66U Endpoint in my LAN (192.168.92.5 and 192.168.1.2)" doing a ping towards another LAN device of mine: 192.168.1.3
Enabled.jpg does masquerade the source address to the local one 192.168.1.2.
Neat little setting
(Also thank you for marking this as solved!)
Joined: 18 Mar 2014 Posts: 12875 Location: Netherlands
Posted: Thu Jul 28, 2022 13:05 Post subject:
@eibgrad, thanks for your wise words.
I do agree about the formatting, I just finished the parsing of the ipset domains so to allow comma delimited in line with all the other fields (but also space works as delimiter as in most other fields )
About the FULL lan access I agree that making it default is the way to go and yes a better name is welcome.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Jul 28, 2022 14:22 Post subject:
eibgrad wrote:
gin-n-tonic wrote:
Gently remind me why the Help sidebar or more... button cannot be updated with egc's detailed explanation.
Is that kept updated? I thought most of that stopped being updated years ago. A check of Help "more" link on the Services page provides only information on PPTP!
Frankly, seems like it would better to store most of that information OFF the router, and just provide links. Perhaps even links on the labels themselves. Then updates wouldn't have to depend solely on the developers, but the larger community. Or perhaps small bubble popups with short blurbs for less well understood options.
The whole area of documentation could use some serious updating, both the information itself, and how/where it's presented.
I have added new and fixed many of the built in help topics recently, so no, it didnt stop being worked on really.
Problem is the updates are all English only with exception of the German which has also received and started syncing with the English also recently the other languages are a mess and outdated.
But, lets say I add this new string, whos going to read this crap? 1 out of 20 users? less? 1 a user in 15 even less? The reality likely would show if we could do A-B testing that most like no one clicks the help more button. I can make a guess, because Ive added new strings, both to the right menu and to the more link and only 1 user out of everyone has said something and actually reported a bug which was also fixed.
egc wrote:
About the FULL lan access I agree that making it default is the way to go and yes a better name is welcome.
I would just remove the word full from the label, certain words are moot in labels, if the functionality allows LAN access, it allows lan access, by your own explanation its not Full Lan access either, so, to make it simpler, I would not use the word full at all.
We already discussed this before, when a setting relies on another setting or when setting an incompatible setting the relevant option would become disabled/enabled depending on what user is doing, but in order to make this magic happen the issue is that currently the disabling/enabling is done via ID's and one cannot reuse an ID, else it doesn't work (I tried) and also is not fine grained, its just general.
If we could control all options like that, no one would be able to set incompatible nonsense and it would be clear that if something suddenly becomes available/disabled that its either compatible or incompatible.
Just for my clarity, if I am running a WG server but I only want connected clients to be able to access the internet / utilize the router IP, I can uncheck "Allow clients full LAN access," correct?
I've also enabled net isolation for the WG interface in the networking settings.
All is working as expected with those two tweaks to the server setup, but just wanted to make sure I'm not making some giant error. Thanks!
Just for my clarity, if I am running a WG server but I only want connected clients to be able to access the internet / utilize the router IP, I can uncheck "Allow clients full LAN access," correct?
I've also enabled net isolation for the WG interface in the networking settings.
All is working as expected with those two tweaks to the server setup, but just wanted to make sure I'm not making some giant error. Thanks!
This feature was added to DD-WRT at my suggestion, specifically wrt the OpenVPN client, and so I know exactly how it's implemented and for what purpose. I assume the same is true for WG.
This feature has the problem of being poorly named. No one's fault, it's just hard to sum up what it's about in a 2-3 word label. All it does is NAT the inbound traffic from the VPN as it's dropped on the local network (br0) so it *appears* to have originated from the router's LAN ip, rather than the tunnel's IP network. The purpose is to "trick" the target device into believing the client is on its own local IP network (e.g., 192.168.1.1), when in fact it is remote (e.g., 10.8.0.2). This allows the client to get around personal firewalls on target devices that have a same-origin policy (i.e., they insist on NOT allowing access by devices unless they are on the same *private* IP network). Personally, I find this to be a rather silly security measure, introduced by Microsoft years ago, and which others have followed suit. Esp. when it's considered acceptable to entertain public IPs over the internet w/o such concerns!
That's what the "Full" in Full LAN Access means. It's FULL in the sense that OpenVPN/WG clients are NOT denied access due to this silly same-origin policy Microsoft and other have introduced. Again, we get around the issue by this little bit of trickery.
So no one should be under the illusion that this is the same thing as intentionally firewall'ing target devices from VPN clients. By default, we assume such clients are to be trusted just as if they had local access on the private network itself (e.g., 192.168.1.0/24). The fact they have a different IP network (e.g., 10.8.0.0/24) is just incidental; a product of the implementation, NOT as a means of formal isolation. Granted, you *could* create such isolation if you needed it, but that needs to be done irrespective of this GUI setting. IOW, you need to add firewall rules, either on the router, or target devices, to truly manage the access.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Aug 18, 2022 12:28 Post subject:
The technicalities of XYZ feature when labeling must be transparent to user, and such technical explanations must be condensed and refined into a jargon free version that can be added to the DD-WRT sidebar help or more... help page.
On that note this seems enough for the help pages at first glance, feel free to refine it further, I can make the patch when ready ASAP.
Quote:
This allows the client to get around personal firewalls on target devices that have a same-origin policy. The inbound traffic is NATed from the VPN as it flows through the local network interface e.g. br0 to make it appear to have originated from the router's LAN IP, rather than the tunnel's IP network.
So no one should be under the illusion that this is the same thing as intentionally firewall'ing target devices from VPN clients.
Thanks! Doesn't sound like it's relevant for my system so leaving it unchecked. I've taken care of the firewalling through other settings and iptables. Have a good one
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Aug 20, 2022 11:33 Post subject:
the-joker wrote:
Quote:
This allows the client to get around personal firewalls on target devices that have a same-origin policy. The inbound traffic is NATed from the VPN as it flows through the local network interface e.g. br0 to make it appear to have originated from the router's LAN IP, rather than the tunnel's IP network.
Hows that for a start?
Also since this is the explanation, the Label should be something like Same-Origin Policy Override or something to that effect. That's something that explain the option better IMO.
This allows the client to get around personal firewalls on target devices that have a same-origin policy. The inbound traffic is NATed from the VPN as it flows through the local network interface e.g. br0 to make it appear to have originated from the router's LAN IP, rather than the tunnel's IP network.
Hows that for a start?
Also since this is the explanation, the Label should be something like Same-Origin Policy Override or something to that effect. That's something that explain the option better IMO.
Ive added the above help string now to both PPTP.asp and eop-tunnel.asp more or less, can be refined later.
I had suggested "Bypass LAN Same-Origin Policy" (or Policies) previously, which didn't elicit any responses, either positive or negative.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Aug 20, 2022 12:25 Post subject:
"Bypass LAN Same-Origin Policy" is a sound label name, I must have missed your original mention.
I can change it on my next PR
Re: documentation (I mean DD-WRT built in help pages/texts). If no one ever does it, will be out-of-date permanently, Ive updated quite a great deal and added new stuff, why bother you say? Because for that reason precisely, it needs doing and because not many volunteers queuing up I do it. Like anything it takes time before its better.
It beats the wiki (now that is really absurdly out of date) the DD-WRT built in help pages at least must be accurate to whats added no matter new or old.
Problem is like everything else, it takes time and most developers are not fans of writing documentation for what they add.
"Bypass LAN Same-Origin Policy" is a sound label name, I must have missed your original mention.
I can change it on my next PR
Re: documentation (I mean DD-WRT built in help pages/texts). If no one ever does it, will be out-of-date permanently, Ive updated quite a great deal and added new stuff, why bother you say? Because for that reason precisely, it needs doing and because not many volunteers queuing up I do it. Like anything it takes time before its better.
It beats the wiki (now that is really absurdly out of date) the DD-WRT built in help pages at least must be accurate to whats added no matter new or old.
Problem is like everything else, it takes time and most developers are not fans of writing documentation for what they add.
And volunteers, did I mention these illusive creatures? most fearful of terminals and svn/git, and they are hunted to near extinction in their natural habitats
Just noticed it today in the most recent build. Does look kind of nice. And I do think it makes things much clearer. Whether that's clear enough to continue supporting the option in the GUI is yet to be determined. But at least it seems possible now.
