I used to use this option frequently to force connected devices to use their own separate connection (thru a different device NIC) to the WAN and encourage those devices to use their own separate NIC connections for WAN and eliminate unwanted traffic being sent over/thru the node. Worked great ... until I found that the lack of a default gateway when this option is selected confuses dumber devices like VOIP phones and camera.
The workaround is reserve the LAN DHCP IP on the node for that device and then set that device IP settings to static where default gateway etc can be hard-coded. Obviously, doing so is a kludge.
Is there another way not to advertise the mesh node as the default gateway without totally eliminating the use of a default gateway. Could you please expound upon the intent and usage of this option?
Hope that makes sense, struggling with a very nasty cold here - and my IQ is down 40 pts+. - typos are way up!
TIA,
- Don - AA7AU
(this post was moved from the middle from another topic to start a new topic of discussion here)
You are here
Prevent LAN devices from accessing WAN
Fri, 01/03/2020 - 13:23
#1
AA7AU
Prevent LAN devices from accessing WAN
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Joe AE6XE
I was thinking that selecting this option should force the DHCP handler to issue the DNS and G/W as the node IP rather than the WAN info - it's just a separate NIC but needs the routing info for the mesh side. If that would happen, then attached cameras and voip phones would function properly without needing for me to setup a hard-coded static-IP in each device. I don't want my devices to go looking around promiscuously at some other WAN way down the mesh
I would actually like to see an option to *ignore* other mesh-resident WAN offerings altogether as I don't like getting jerked around by misconfigured distant nodes.
Thanks,
- Don - AA7AU
1) If traffic from my LAN devices and I have a WAN, always route traffic to my WAN (regardless if the WAN is advertised as a gateway or not)
2) If there is a WAN advertised gateway on the mesh, route to neighbor mesh node in the direction of the closest one
The 'default' route, if issued to a LAN device, is issued to the device with the IP address of the node. From my desktop:
10.0.0.0 localnode.local 255.0.0.0 UG 100 0 0 eth0
Turning on this option, my desktop would not have this default entry. OLSR is currently not configured to configure routing tables to a remote WAN across the mesh. The routes (default or otherwise) only know to send traffic to a neighbor node in the direction the traffic needs to get to. There is a plugin in OLSR to route to a defined gateway across the mesh network, to implement, on the backlog list.
Joe AE6XE
Withe the Part 97 issues it sounds as though connecting a WAN to our home routers is more of an issue than not. So I guess I'm confused as to why we have that option I guess. I'm not sure how to ask in a way that would make an aswer clear to me I guess.
My mesh is now connected to my home network via a WAN connection from a MikroTek. But everything I read points to this being a no no. But there is an option to check to prevent LAN connetions to not have WAN access.
I'm sorry but I'm confused by all of this I guess. Read one thread then another and things are said differently etc. My mesh is still in the testing phase and there are no other nodes around me that I have seen so no worries about anyone connecting to me at this time. But what if?
73, Dean, KC2MVB
You may connect to an AREDN mesh network and there may be someone else that has enabled a gateway to the internet. This is often done for various reasons including winlink CMS mail path, echolink and other repeater voice paths, and more. Part 97 rules say "obscure" and "intent" is a factor. Today, ham radio operators transmit HIPA obscured messages from Hospitals on VHF/UHF/HF and accepted. I don't see this any different than if the Red Cross asked me to pass their VPN connection over an AREDN network from Incident to HQ -- passing the message "as is".
IMO part 97 rules need to be modernized to meet the concerns and needs of today's technologies to fulfill the purpose of ham radio so such needs can be served without pushing boundaries or being recliner chair lawyers.
Joe AE6XE
Thanks for the insight. Right now my home computer is connected to my home network via LAN connection and I'll use the wireless network to get into the mesh. That way my computer can still do both as needed. My laptop is currently setup for wireless only so I'm either on my home network or I'm on the mesh.
Now on the flip side I do have the mesh router (MikroTik) connected to the home network via the WAN port. I had the nodes connected so I can put them on the map via the submit data to AREDN. other than that nothing more. I do have Synchronet BBS installed on my Pi now and it seems to be working well on the mesh from what I can tell so far. I've only done a telnet into it and not http just yet as I'm still figuring out some things on that side of it. But I digress.
So it would seem 6 of one and half dozen of another. Since I am not doing WinLink etc. then it would seem I can disconnect the WAN side of it. Although it's nice that the times are accurate now. :) My Pi does connect to my home network though via the wireless so I guess that could be used as an NTP.
OMG so many things / options. Head spins. And I wonder if this is all worth it as I'm it in my county right now. Lots of things to think about!
Thanks again Joe!
Dean KC2MVB