Posted: Wed Jul 27, 2022 15:49 Post subject: [SOLVED]WG Setting "Allow Clients Full LAN Access"
Hi,
it has been a while since I had a closer look into the settings of my WG Endpoint (N66u running as endpoint, connected via LAN towards WWW -- VPS of mine).
It is working like a charm, nothing critical, but I'd like to know more about:
"Allow Clients Full LAN Access"
Since "NAT via tunnel" and "Route All Sources via VPN" are enabled and in addition nothing fancy like PBR or Firewall Marks is enabled... what does the setting do?
Joined: 08 May 2018 Posts: 14125 Location: Texas, USA
Posted: Wed Jul 27, 2022 16:17 Post subject:
I'm willing to bet it is explained in the wireguard guide as that is constantly being updated when changes are implemented. Fact is, you will never stop reading and learning when something is in constant development. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
"This will NAT traffic coming from the WG interface out onto br0 (and all other br interfaces) so that
clients on the LAN can be easily reached as those can have their own firewall blocking non-local
traffic.
Downside is you will lose logging and access control as all traffic now originates from the routers IP
address instead of from the WG interface.
The rule is: iptables -t nat -I POSTROUTING -o br+ -s $(nvram get get oet${i}_ipaddrmask) -j MASQUERADE"
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Wed Jul 27, 2022 17:54 Post subject:
Like @kp69 already said and @the-joker already quoted
VPN clients (the ones which are connected to your router from outside, and when you use your WG as a client that is the server side and all its clients) always have access to your LAN
(of course unless you enabled the Firewall Inbound, which you should in case you are using WG as a Client to a Commercial VPN provider and which is enabled by default)
But the LAN access is not "full" because the source IP is the WG tunnel and many of your LAN clients block anything other than the local subnet.
The prudent thing to do is to tweak the firewall of your local LAN clients to give access to the WG subnet.
Why the prudent thing, because you can differentiate and keep track (and or block) between local clients and WG clients coming from the internet.
But who knows how to tweak the firewall of your Windows client, NAS and other appliances?
Of course we do but that is not everybody so to ease that burden you can NAT traffic coming our of br0 so all traffic also the WG traffic coming from the internet has the local source address of br0 and is accepted everywhere on your local LAN so you now have FULL local LAN access
But as always suggestions to explain things more clearly are welcome.
Writing manuals by the developers who actually make things is usually a bad idea (just like testing).
I just knew the wording on that option would befuddle many ppl. I said at the time, that one is simply NOT intuitive. Who doesn't want FULL LAN access?!
But @egc finally got what he always wanted; the opportunity to explain it.
P.S. Personally I think the ipset domains should be space separated. Easier to read. Leave the formal formatting that requires / to the router.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Jul 27, 2022 19:17 Post subject:
@egc @eibgrad my only interest in the string is to make it self explainable while ensuring that remains a 4 word max label length and depends on words used, cause translations should be in a small very degree a consideration.
Polish tends to be the longest winded so far, Fan off (small two words) those alone make a stupid long translation and UI gets to suffer layout breakages when the cekcboxes/radios ahead are concerned.
"Full" is a word that doesn't explain anything IMO. you either have or dont have LAN access as far as I'm concerned no matter the technically accurate ad-nauseam requirements.
@egc @eibgrad my only interest in the string is to make it self explanable while ensureing that remains a 4 word max.
"Full" is a word that doesn't explain anything IMO. you either have or dont have LAN access as far as I'm concerned.
Word count matters. we cant have labels exceeding the current and already extended 19.444em. I could push it to 20em and there after I need to start a wack a mole game.
Oh, I appreciate that. Sometimes it's just NOT possible to express what an option does in a simple, short label. Not unless there's a general knowledge of a given term (e.g., killswitch).
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Jul 27, 2022 19:31 Post subject:
If only it were that easy.
If you need to explain anything, the premise has failed. If it requires thinking, the premise has failed. (consider usability and user experience).
OK since DD-WRT is advanced then users should be of a minimal tech background understanding in any ideal world or RTFM, but sadly, this isn't even the closest to the reality, flashing DD-WRT doesn't make anyone an expert on all things DD-WRT.
So far we have a huge bridge to gap and it falls on the driving force to do the thinking for those who cant or wont to some reasonable extent.
But all is moot, we spend countless hours explaining and supporting the most basic things. Rinse and repeat and repeat the rinse.
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.
Joined: 30 Jun 2014 Posts: 59 Location: California
Posted: Wed Jul 27, 2022 23:39 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.
Excellent point: Don't waste router memory for detailed documentation. Or waste developer effort. Perhaps only the most basic help (enough to get you internet access) needs to be on the router.
Multiple sources of information will always cause problems in the long run. And we certainly don't want to discount or redo any of the recent work improving the wiki. So without knowing anything of the problems involved, I ask if links to relevant sections of the wiki (or even forum stickies?) would be a good option?
Joined: 18 Mar 2014 Posts: 12837 Location: Netherlands
Posted: Thu Jul 28, 2022 6:14 Post subject:
eibgrad wrote:
I just knew the wording on that option would befuddle many ppl. I said at the time, that one is simply NOT intuitive. Who doesn't want FULL LAN access?!
But @egc finally got what he always wanted; the opportunity to explain it.
Indeed we have been discussing it but I do not always listen
(@eibgrad's help and advice has been and is invaluable for me when developing things for DDWRT)
As far as the naming of interface items, I am fine with anything.
When we were discussing the SmartDNS options I added, I already said that I am not a native speaker and open to all suggestions.
eibgrad wrote:
P.S. Personally I think the ipset domains should be space separated. Easier to read. Leave the formal formatting that requires / to the router.
Regardless, an interesting and long time coming addition.
To me it makes the most sense as this is the format of Ipset/DNSMasq (and it is the easiest to implement with the least amount of code).
But thinking about that, probably not many people know this (proof that developers should not make interfaces, not write manuals and should not do the testing (boring))
So I might make it differently
Code:
--ipset=/<domain>[/<domain>...]/<ipset>[,<ipset>...]
Places the resolved IP addresses of queries for one or more domains in the specified Netfilter IP set. If multiple setnames are given, then the addresses are placed in each of them, subject to the limitations of an IP set (IPv4 addresses cannot be stored in an IPv6 IP set and vice versa). Domains and subdomains are matched in the same way as --address. These IP sets must already exist. See ipset(8) for more details.
I understand the underlying implementation requires that type of formatting. But from the user's perspective (i.e., GUI), it's irrelevant. The GUI needs to consider what's best for the user, NOT the developer. Exposing the underlying needs of the system/developer leads to several problems, such as an inconsistency in dealing w/ freeform fields (some require slashes, some require commas, some require spaces, etc.), all depending on the underlying implementation. And if it's done this way for the convenience of the developer, there's a good chance it's NOT going to be validated, which may then cause the underlying service (in this case, DNSMasq) to NOT start!
As far as this issue w/ the labeling, there's no easy solution, since it's impossible to find a good label for every option. Some just beg for further explanation. The real problem here is the overall way the router deals w/ documentation. We basically have to depend on two extremes; either the label OR pointing everyone back to @egc's terrific documentation in the forum (which btw, I believe is one of the reasons there's considerably less questions in the Advanced forum these days; users are finally getting the message). But even so, it would be a lot better if there was a consistent hierarchy of information sources, starting w/ the label, to perhaps a popup bubble, to then the internal/online help system, and finally pointing to the most detailed offline information.
Frankly, I'd like to see the whole Help system removed from the router. I can't recall any other firmware that does this. Might have been cute and practical in the early days, but now the situation has changed dramatically. There's no way the developers can do what they need to do w/ the code *and* keep this updated. As I said, it should be maintainable by the community who has both the time and interest to do so. The fact the Services->VPN page Help system only talks about PPTP just makes it clear it's NOT being maintained anyway.
Finally, let's consider the possibility here of perhaps simply enabling this "FULL Access" feature in the firmware by default and NOT exposing it to the user, esp. if it serves the interest of 99% of users. No OEM would ever offer such an option for these very same reasons of having to explain it. They'd simply implement it, and if they got complaints, they'd say "too bad, we're serving the interest of the many here, NOT all". And for the 1% who do complain, explain the means to undo it (in this case, a firewall deletion rule). Heck, if the user does want to filter access based on knowing the OpenVPN client's assigned IP on the tunnel, they're probably going to do so on the router anyway, before the traffic is even NAT'd! IOW, being able to filter at the target itself is probably a rarity, esp. for anyone depending on the router to support the VPN server rather than the target itself. The biggest complaint is probably going to come from those who don't like the effect it has on any logging performed by the target.
Frankly, I've always considered this same-origin policy that Microsoft introduced a few years ago kind of nutty, esp. when they willingly accept remote, public IPs (i.e., the internet is more trusted than another local IP network). I don't really get the reasoning here.