I have a Ubiquiti NSM2 connected to the Internet through a Raspberry Pi working as a firewall using iptables to prevent any encrypted traffic between the NSM2 and my router. If I start a tunnel on the node either in client or server mode, I'm assuming it will need some sort of encrypted path between the node's WAN port and the Internet. If so, what port do I need to open up in the NSM2-to-Internet direction? I understand that port 5525 is needed in the Internet-to-NSM2 direction.
Additionally, what happens if my gateway is well protected against encrypted traffic, but then I tunnel into another mesh with a gateway that is not protected? Does that open up our mesh to encrypted traffic?
Thanks,
Dave K3GX
Additionally, what happens if my gateway is well protected against encrypted traffic, but then I tunnel into another mesh with a gateway that is not protected? Does that open up our mesh to encrypted traffic?
Thanks,
Dave K3GX
The tunnel configuration only needs a port forward from your home router and internet on port 5525 to reach the mesh node (incoming connection) for the server side to work. It does not require any other port, e.g. 443.
On the tunnel client end, do not block 5525 from going out to the internet. The same is true for both the client and server tunnel nodes, no other port including 443 is required.
If you have advertised your internet gateway to the local mesh network, then there will not be any traffic that can go from your local mesh network across the tunnel to reach another gateway, that does not block encrypted ports. The OLSR routing will always determine your gateway is a lower cost path and route traffic from your local mesh though your gateway. It would be a longer path to hop though your tunnel to another gateway.
Joe AE6XE
Dave K3GX
Joe AE6XE
Dave K3GX
opkg update
opkg install kmod-tun zlib libopenssl liblzo vtun
What error messages or other behavior occur when you click the install button?
Joe AE6XE
I made a mistake on the iptables - now it's working... Geez, this opens up a whole new world! I was trying to block port 80 on the back end of my home router from the mesh, and mistakenly blocked all port 80 requests from the mesh!
Glad to know it's a 64 Mb unit as well.
Thanks for your willingness to be so responsive on this forum. The amount of time you're spending coding and helping people out certainly stands out!
Dave
Hi Folks!
OK, with the increasingly compelling need for computer security balanced by the regulatory writ of limiting encryption to control functions when using Amateur Radio, I was wondering if anyone has built a protocol gateway for https/http within the firewall on an RPi?
I know some folks will fret over what sites may end up on the Amateur Radio mesh side, but I'm not too worried about those corner cases if they are simply commercial sites. After all, we can use a repeater autopatch to order a pizza, so this issue is more one of the security issues that result from such a gateway. Any thoughts on that?
73,
Gordon, W2TTT
That would actually be very simple (I wouldn't have said that a week ago!). Are you looking to use the RPi as both a firewall and the control computer? In that case, you can allow https or ssh just to the RPi itself but also prevent it from going to the Internet. Alternatively, you could have another IP address on the other side of the firewall from the mesh that is the only destination address where you allow https or ssh.
73, Dave K3GX
Dave,
If I am in sync with the stream of information, then I would think that the mesh side traffic would be http and the Internet side traffic would be https managed through a stateful gateway. This presumes that all systems on the mesh side are as pure as the driven snow. This is a scary assumption, but let's go with it.
The attack vectors are numerous with replay/man in the middle being an obvious one. Another issue is that when supporting public safety agencies, you now have a bunch of vulnerable systems. These two basic scenarios concern me.
I can tell you that we've run encrypted, secure tunnel traffic for public safety operations over our mesh when on operations where we needed to extend the Internet to the officers. We simply log it in case there is an issue later.
Thinking more broadly for day to day mesh operations, why not use modern protocols and simply log them for any regulatory oversight?
Thoughts?
73,
Gordon Beattie W2TTT
201.314.6964
Has a Regional Director deemed the logging to be necessary [ref: §97.309 (b)(3)]? Why go to the trouble unless he/she does?
Andre
Red Cross Director? No contact with them. There was an inquiry asking the League and Red Cross if there was a need to handle HIPA traffic and they concluded that the answer was "No" because that is the answer they wanted. First, as a Red Cross and Sheriff's Dept, Commuications Volunteer (DST & COM-T), I found that response to be blind at best. Maybe for now, it needs to be that way?
73,
Gordon Beattie, W2TTT
Good point, but it is a good practice nonetheless.
73,
Gordon Beattie, W2TTT
201.314.6964
When we see it, we log it. For example, when we originate it, we always log it and/or maintain web browser history or email files for at least a year.
I think we need to keep a low profile on this and not look to ruffle feathers while we focus on providing a secure and stable platform.
I can recall the internal outrage by Baudot RTTY ops when ASCII computer users showed up on the air. We would send ASCII in hexadecimal Baudot with CW Id's and folks were screaming that it was illegal. We countered with observations that RTTY "art" which was often soft porn, wasn't exactly "plain text". :-)
Eventually we could use ASCII, but then folks started in with HDLC wasn't ASCII. The cycle then repeated until rational folks persevered.
73,
Gordon Beattie, W2TTT
201.314.6964