Skip to content
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

Closed
n4tqu opened this issue Mar 27, 2019 · 8 comments
Closed

Preventing LAN devices from accessing WAN doesn't work completely #26

n4tqu opened this issue Mar 27, 2019 · 8 comments
Labels
bug Something isn't working

Comments

@n4tqu
Copy link

n4tqu commented Mar 27, 2019

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

@ae6xe
Copy link
Contributor

ae6xe commented Mar 27, 2019

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?

@dman776
Copy link
Contributor

dman776 commented Mar 28, 2019 via email

@n4tqu
Copy link
Author

n4tqu commented Mar 29, 2019

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?

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.

@ae6xe
Copy link
Contributor

ae6xe commented Mar 29, 2019

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.

@n4tqu
Copy link
Author

n4tqu commented Mar 29, 2019

Taking this idea a step further one could implement an option to grant a per MAC address reservation (LAN device) with WAN access.

@K6AH
Copy link

K6AH commented Apr 17, 2019

I'd be in favor of renaming it back to Disable Default Route and use the documentation to explain what that really means.

@r1de
Copy link
Contributor

r1de commented Apr 18, 2019

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".
I guess that would also mean, we'll need a new checkbox then that turns on/off a new firewall rule.
edit to add
But then how would this play along with aredn/aredn_ar71xx#214? (if both were to be implemented)

@WZ0C
Copy link

WZ0C commented Aug 9, 2022

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".

@aanon4 aanon4 closed this as completed Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

7 participants