-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preventing LAN devices from accessing WAN doesn't work completely #26
Comments
This option was previously called "Disable default route". The wording change was an attempt to clarify the intent for the non-IT guru. The original implementation (for years) has not changed. This new wording certainly communicates restrictions that are not imposed. We have 2 options to proceed; A) change the wording to better match what is occurring; B) add the logic that prevents manual circumvention to access from the LAN to a WAN (local or remote). Feedback, preferences anyone? |
I thinks it’s fairly clear in the docs.
https://arednmesh.readthedocs.io/en/stable/arednGettingStarted/advanced_config.html
Perhaps a wording change would help.
Thanks,
Darryl
… On Mar 27, 2019, at 6:31 PM, Joe AE6XE ***@***.***> wrote:
This option was previously called "Disable default route". The wording change was an attempt to clarify the intent for the non-IT guru. The original implementation (for years) has not changed. This new wording certainly communicates restrictions that are not imposed. We have 2 options to proceed; A) change the wording to better match what is occurring; B) add the logic that prevents manual circumvention to access from the LAN to a WAN (local or remote). Feedback, preferences anyone?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
My vote would be for real prevention. I think this is especially important for those just getting into AREDN and utilizing tunnels to explore the capabilities of the system. |
There is a use case where the LAN devices might be adhoc users on mobile device with a voip app. The general scenario is users that are not the node admin. Controlling WAN access would be a desired capability IMO. Another node might give a group of users access to the WAN. Thus it's not an "all or nothing" option for WAN access to be able to manage a limited resource to those with the most need. The prevention would build in security so a savvy user could not circumvent what is intended. |
Taking this idea a step further one could implement an option to grant a per MAC address reservation (LAN device) with WAN access. |
I'd be in favor of renaming it back to Disable Default Route and use the documentation to explain what that really means. |
I'm with Andre on this one, if all the checkbox does is cause dnsmasq to not give out a default route with the leases then name it back to "Disable Default Route". |
It would be preferable for the UI option wording to be for a positive decision rather than a negative decision. That is, "Enable Default Route" rather than "Disable Default Route". A user having to turn something on (the checkbox) to turn off the feature (default route) can lead to confusion, frustration, and misconfiguration. And similarly, "Enable LAN device access to WAN", rather than "Disable LAN device access to WAN". |
I upgraded to 3.19.3.0 today and decided to try the option for "Prevent LAN devices from accessing WAN" and noticed that this does not work as written. An existing LAN device will continue to access the WAN at least until the DHCP lease on the client renews and drops the default route. Also, anyone can add a static route on the LAN device and be capable of accessing the WAN.
I suggest an iptables rule would likely be more appropriate as a preventative measure.
Additionally, checking this box really should not require a restart of the mesh node. I suspect this is done due to limitations of the hardware however.
Steve - N4TQU
The text was updated successfully, but these errors were encountered: