I searched around the forum and could not find any discussion of this issue so here goes:
I set up a WAN connection from my Ubiquiti node through a VLAN switch. (You can see my network diagram in the networks forum)
I plugged the WAN output of the switch into a slot on my main router to connect to the internet and it worked well!
So what's the problem?
I discovered that this gives access to my LAN from the mesh, which is both a security issue and a routing issue, since I'm sure someone else will have 192.168.0.x on their LAN.
I discovered this while setting up a VOIP and discovered I had connections that I shouldn't have.
I verified this with a traceroute and by shutting off the WAN connection in the node.
I can solve the security issue by plugging the WAN from the node in up stream of may main router. But it still leaves a routable path that could cause an IP conflict.
Others may not have the luxury of multiple routers.
Is this new? Is there something I should have done? Narrow down the WAN Netmask?
Discussion?
did you enable "mesh gateway"? if so, that is the expected behavior. That is one reason I DON'T recommend enabling the mesh gateway option.
I had seen the discussion about what might be accessed on the web over a gateway being an issue but not that your LAN could be accessed or the potential for an IP conflict.
If you let your mesh gateway node get is IP from the internet router via DHCP, it likely got a mask that includes everything on your LAN. You've got a couple of options:
1. Setup a DMZ port on your internet router that isolates the mesh from your LAN.
2. Set the IP on your mesh gateway node manually and use a smaller subnet mask. Any traffic for the 192.x space that isn't in that mask will hit your internet router anyway, which will toss it or pass it. If it passes it, your other nodes on the LAN won't try to route back through the router for a local address, so you've essentially isolated that way. You're still relying on configuring on that node to protect you, but if you're the only one doing the config, that's the same as #1. I wouldn't recommend this solution.
3. Move the mesh gateway up to another router, like you suggested.
I'd recommend #1. Turing on the mesh gateway flag is very useful - but it has to be done with the understanding of what you've accomplished, as you've just discovered!
I had set the WAN IP as static with a netmask of 255.255.255.0.
The gateway is 192.168.0.1 and the WAN is 192.168.0.2 (and 192.168.0.3 on another node)
I tried changing the netmask (on the node WAN) to 255.255.255.248 but that had no effect.
I poked around in the node looking at routes and found that I can add a command:
"route add -net 192.168.0.0 netmask 255.255.255.0 dev eth0.1 reject"
Now any packets to my local subnet are rejected as unreachable but internet packets are passed through to the gateway.
However, this only works until the node is rebooted!
If you want to use a mask, you'd need to use something that doesn't include the node you don't want to have access to. Changing it to 248 in the last octet still would include 1,2,3,4,5, and 6 as hosts. If you wanted to restrict it to just the two, use 252 which puts 1 and 2 only in the same subnet (in your example). But this is a hack, and wouldn't think this would be a long term solution.
The gateway advertisement enables a 'default route' to the foreign network by design. In this case, the router/switch of the foreign network then uses it's routing configuration to forward the packet. The mesh has no idea what this foreign network is and does not 'advertise' any service or machine that may exist on that foreign network. The netowrk could be your home network, could be directly on your ISP cable modem, etc. The mesh only knows that if the hostname or IP address is unknown on the mesh, then send it to this foreign network (via the gateway on the mesh that has lowest ETX cost to get to).
There is no practical way for the mesh to pre-define and know what traffic to exclude and block from sending to this foreign network. The current AREDN image has no existing 'setup' way to further restrict this traffic, and something only a linux netfilter person could do under the hood. I'd recommend looking at the home network's router--may have features to also let one block this traffic, e.g. Don't let traffic from the mesh on 192.168.1.105 access any other 192.168.1.x address. Additionally, don't allow part 97 rules to be violated, etc.
Joe AE6XE
Here's the route status after the command above. The only anomaly is my reject route destination (second from the bottom) appears to be applicable to all interfaces even though I told it eth0.1. (Flag =! means reject)
I am satisfied with this solution. I just need to include it in the node startup procedure. What/where is that?
root@N8JJ-M5-BVRCRK:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth0.1
10.0.0.0 * 255.0.0.0 U 0 0 0 eth0.2
10.0.0.0 * 255.0.0.0 U 0 0 0 wlan0
10.81.226.168 * 255.255.255.248 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 ! 0 0 0 *
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0.1
Well that was ugly. This is easier to read.
N8JJ, we're getting into power-user and custom settings under the hood in AREDN that has potential to impact the node's compatibility with all the features, so not recommend. If you shoot me an email to callsign at soara.org, let's further discuss.
Joe AE6XE
Ideally if your worried about access to your local lan you should set up a DMZ lan on your home network and plug AREDN wan into it instead (many routers support a DMZ port which is a secure isolated network)
WAN GW is generally though something that should be turned on only if one truly understands the security implications of sharing a network access (I brought this up a few times back when I use to contribute to BBHN)
In addition I want to point out the following policy for the future (taken from the about us page) incase someone else comes across what they feel may be a security flaw in the future in order to allow the AREDN Security Team a chance to resolve the issues before public disclosure (sounds like this one isn't an issue and was just a configuration issue, but still it started out as a claim of security flaw)
AREDN™ Responsible Disclosure Policy
The members of the AREDN™ team believe in the responsible disclosure of security vulnerabilities present in the software. To further the goal of responsible disclosure we request those persons who believe they may have discovered a security vulnerability please contact securityteam@aredn.org and work with us to ensure that the vulnerabilities are patched prior to public disclosure.
Furthermore we understand that other organizations may be developing firmware based on the solutions we have published. To that end the AREDN™ group has created a security program for such organizations to be informed of discovered vulnerabilities and provide them the ability to secure their offerings prior to the public disclosure of such vulnerabilities. To apply to our security program please contact securityteam@aredn.org
Depending on what you've got on your LAN, you could alternatively have each of those devices protect itself instead of relying on a firewall router to do so. That's what I do, because all our important machines run Linux or OSX and I keep an iptables/ipfw configuration on each one. I treat 10.0.0.0/8 as an external network, i.e., you can't do anything from it that you can't already do from the wider Internet.
You wouldn't want to do this if you run Windows or have embedded devices that can't be secured.
Networks are designed to provide connectivity, so they can't really be blamed for doing their job. If security is needed, I recommend doing it with individualized packet filters rather than by imposing architectural features or limitations that make something difficult or impossible to do even if you want to. I'm thinking especially of IP address conflicts due to private address reuse, and (above all) NATs. This will become very important with IPv6.
I like the 'ip route' command better than 'route' because it's more versatile and I think the output is easier to read. I believe it's implemented in the busybox shell that's part of the firmware. When discussing routing problems be sure to include your mesh routing table and policy rules, i.e.,
ip route list
ip route list table 30 # I put an entry in /etc/iproute2/rt_tables so I can call this "mesh"
ip rule list