You are here

Outbound Tunnel Ports?

15 posts / 0 new
Last post
K3GX
Outbound Tunnel Ports?

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
 

AE6XE
AE6XE's picture
The tunnel configuration only

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

K3GX
Thanks Joe. I just installed

Thanks Joe. I just installed the latest nightly build (build 214) just to have the latest and then tried to install the client software by going to the tunnel client and selecting install. After a minute or two, it reported that it failed.  Do I need to downgrade to a stable release, install the tunnel software, and then upgrade again to the nightly build?  The node still runs fine after the install attempt, just no tunnel.

Dave K3GX

AE6XE
AE6XE's picture
Dave, ironically, I just

Dave, ironically, I just installed build 214 on my main home mesh node, currently a 3Ghz NanoStation XM with 32Mb RAM.   It installed the tunnel OK and has a live connection already.   Sorry, if I've lost context with a number of threads I'm bouncing around...  Your node does have an internet connection to access the downloads?  You can browse to an internet website, etc.?

Joe AE6XE

K3GX
No worries. Yes, I have a WAN

No worries. Yes, I have a WAN connection with the firewall in place to block https etc. I'm able to see a list of available packages to download on the administration page, so I should be able to download the tunnel package. I'm running an NSM2 XW. I'm guessing it's a 32Mb unit, but I'm not sure. The main page says flash = 1552 kB, /tmp = 30004 kB, memory = 35640 kB.

Dave K3GX
 

AE6XE
AE6XE's picture
The NSM2 XW is 64Mb RAM.  the

The NSM2 XW is 64Mb RAM.  the value on the status page is showing that you still have ~35Mb free, so no issues on RAM side.     Best to attach a support data download for next step.   The install is issuing these commands, and the support data will show if these packages had been installed or not:

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
 

K3GX
Joe,

Joe,

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
 

W2TTT
W2TTT's picture
https vs. http et al

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

K3GX
Hi Gordon,

Hi Gordon,

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
 

W2TTT
W2TTT's picture
https vs. http et al

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

 

K6AH
K6AH's picture
Logging not normally required

Hi Gordon,

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
 

W2TTT
W2TTT's picture
https vs. http et al

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

 

W2TTT
W2TTT's picture
https vs. http et al

Andre,
Good point, but it is a good practice nonetheless.
73,
Gordon Beattie, W2TTT
201.314.6964
 

AE6XE
AE6XE's picture
So 'you' didn't encrypt the

So 'you' didn't encrypt the traffic/message given to you, only passed the traffic as-is through the mesh network?    Are people also logging such situations on HF when the message given is obscured patient and medical information?     This is a likely scenario in my area as well, so interested in how others are handling this.

W2TTT
W2TTT's picture
https vs. http et al

Joe,
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

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer