You are here

When can I "Allow others to use my WAN"

10 posts / 0 new
Last post
AC0WN's picture
When can I "Allow others to use my WAN"

I am sure this subject has been discussed more than once, and it is quite possible there are opposing points of view, but I request respectfully that those with more knowledge and experience than I shed some light on the matter.

The question: When is it legal and acceptable amateur radio practice to engage the "Allow others to use my WAN" switch when the network you are connected to is using RF links on the amateur radio portion of a band?

Example 1: Network A has one or more nodes that have engaged their WAN gateway. Network B uses RF links on an amateur radio frequency. Can Network B maintain a tunnel to Network A without breaking FCC regulations or proper amateur radio practice?

Example 2: Network A has one or more nodes that have engaged their WAN gateway. Network B has NO RF links on amateur radio frequencies. Can Network B maintain a tunnel to Network A without breaking FCC regulations or proper amateur radio practice?

Any and all responses will be sincerely appreciated.

Many thanks & 73,
julie mcgrew


As long as the traffic passing over the RF link is not encrypted, and not of business nature. But how to trust your users are following the regulation?? If you have the time to analyze captured traffic and hunt down offenders, set up Wireshark and a mirrored port in between your AREDN node and your internet connection. Otherwise, you will need a firewall or proxy, filtering both outbound and inbound traffic to only allow unencrypted traffic, whitelisted sites, etc. 

On your second scenario, if Im understanding correctly, the traffic between network A and network B is not going over RF at any point. So none of this applies in this case. But you are still liable for what it is being done with your internet connection. Furthermore, most ISPs will throw a fit if they find out you are sharing your connection outside your premises. 


K5DLQ's picture
If you want fine-grained

If you want fine-grained control over WAN access, leave the checkbox UNCHECKED and install a SOCKS Proxy server somewhere and attach it to the LAN port of any node that had internet access via VLAN1.  (with UNCHECKED "allow others to use my WAN" checkbox).   Then, you can only allow certain machines/pc's access since they need to specify the proxy server address in order to get "out" to the WAN.

Raspberry Pi install tutorial:


Raspberry Pi Docker container:


AC0WN's picture
Thank you and please allow me to clairify.

Thank you to both KX5DX and K5DLQ for your comments.  This is great information and much appreciated;  however in reviewing the comments it is clear that I have poorly framed my question and I apologize for that short coming.

I have no desire to allow others access to my WAN.  I was merely referring to the name of the switch on the Basic Setup page.

Our situation is as follows:  We have a AREDN network that uses RF links on amateur radio frequencies.  We do NOT allow use of the “Allow others to use my WAN” switch as we prefer to keep all encrypted / internet traffic off our network.  We would like to tunnel to other networks to explore, learn, and share the AREDN experience but in doing so we are finding that many of these other networks do allow use of the WAN switch.  Our concern is does the process of tunneling to these networks compromise our goal of keeping encrypted / internet traffic off our local network?  If the answer is “yes” then is there a way for us to firewall the tunnel connection in such a manner as to prevent encrypted / internet traffic from entering our network while allowing our users an opportunity to experience the other network’s services?

Hopefully I’ve made my inquiry clear and would very much appreciate any ideas on how we might accomplish this goal.

julie mcgrew

kg6wxc's picture
Policy Routing

You can do this, it's not all that straightforward tho.
The trick is really to just "cut off" the offending packets at some point on your network, preferably right near the "edge" where the route is coming in.
Then, even though there *is* a route to the internet, that OLSR is propagating, no one can use it.
Firewall in/out rules and whitelists are only going to cause more headache...

I would try to explain more, but I am not sure I even should. messing with the routing tables can bring chaos to your entire network.
Unless you understand what you are doing, it can be kind of weird.

In a Cisco environment, we

In a Cisco environment, we could implement a access control list only allowing traffic to the entire /8 subnet, with the implicit deny rule blocking everything else. Then point this ACL to the tunnel interface of the node establishing the tunnel, in the inbound direction. But I have no idea how to do this on an AREDN node.

Daryl, is there a way to kill the default route redistribution from within OLSR? 


AE6XE's picture
There is a way to remove the

There is a way to remove the routing information such that a node will not have knowledge to pass traffic to the internet (the default route).  This can be done on any mesh node, not necessarily on a gateway node.   See this post:

See this enhancement request:


Use traceroute to

Use traceroute to find the node where traffic is exiting into the Internet.

You could try contacting the node owner and ask if they have a valid reason to advertise their WAN all over the mesh, and hopefully they just turn it off.  This could also be a administrative headache, as may have random nodes advertising their WAN from time to time.

AC0WN's picture
Thank you All

Thank you all for your suggestions.  Clearly I have waded into the deep end of the pool.  :)

I will study the options presented and experiment with applying them to our network.  So many opportunities to learn.

Many thanks,
julie mcgrew

K6AH's picture


The development team discussed this issue at our last teleconference.  There is an installable package for the AREDN software called "blockknownencryption" that is designed to prevent any traffic to be passed on "known" encryption ports.  If fact, on first boot of a node there are instructions on installing this package.  There are, however, two caveats to using it.  :

  1. It doesn't prevent encrypted traffic on other than know ports... but it does keep honest people honest.
  2. We aren't aware of anyone currently using this feature and it hasn't been rigorously tested.  Joe did look through the code and feels it should work, but we would appreciate any feedback if you decide to use it.  If you run into any difficulty with it, it can be uninstalled easily.

Andre, K6AH

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer