On my first go at mesh I was using Linksys equipment with the BBHN platform. In that setup I had a node at my home configured as a mesh gateway and had developed a series of IP tables in the firewall.user that allowed me to forward ports to a remote node at my repeater site in support of my IRLP node and also facilitating remote access to my repeater controller. My script was as follows:
#AI6BX-2 Node Port Monitor (loaded in firewall.user at home node - Mesh Gateway)
iptables -A input_wan -p tcp --dport 8088 -j ACCEPT
iptables -t nat -A prerouting_wan -p tcp --dport 8088 -j DNAT --to 10.36.188.90:8088 (IP of IRLP on node at repeater site
iptables -A forwarding_wan -p tcp --dport 8088 -d 10.80.3.81 -j ACCEPT
iptables -t nat -A postrouting_wan -p tcp -d 10.36.188.90 -j SNAT -dport 8088 --to-source 10.68.151.139 (WAN IP of remote node)
I have tried loading this same file into the Nanostation M2 running the latest version of AREDN with no luck. Even more interesting is the file is erased each time I reboot the node.
Is there a different place this file should be loaded or is there a better way to accomplish this task on the AREDN platform? I use this not only for the IRLP link but also as a VNC link to a PC located at the repeater site. The reason for this is obvious for the IRLP link and is also needed as it gives me remote access to the site when traveling and away from direct mesh access.
Any help is greatly appreciated.
Keith
#AI6BX-2 Node Port Monitor (loaded in firewall.user at home node - Mesh Gateway)
iptables -A input_wan -p tcp --dport 8088 -j ACCEPT
iptables -t nat -A prerouting_wan -p tcp --dport 8088 -j DNAT --to 10.36.188.90:8088 (IP of IRLP on node at repeater site
iptables -A forwarding_wan -p tcp --dport 8088 -d 10.80.3.81 -j ACCEPT
iptables -t nat -A postrouting_wan -p tcp -d 10.36.188.90 -j SNAT -dport 8088 --to-source 10.68.151.139 (WAN IP of remote node)
I have tried loading this same file into the Nanostation M2 running the latest version of AREDN with no luck. Even more interesting is the file is erased each time I reboot the node.
Is there a different place this file should be loaded or is there a better way to accomplish this task on the AREDN platform? I use this not only for the IRLP link but also as a VNC link to a PC located at the repeater site. The reason for this is obvious for the IRLP link and is also needed as it gives me remote access to the site when traveling and away from direct mesh access.
Any help is greatly appreciated.
Keith
I've removed my post as it uses a hack that is no longer needed.
In 3.16.1.0 the custom firewall rules is now different and handled in an improved way. Rather than trying to keep firewall rules merged and working in a single config file--error prone and very manual--with rules coming from various packages, custom changes, and from release to release, there is now a way to have the rules in a unique file for each need.
If you are doing this, please review the directory "/etc/local/mesh-firewall". Note for the general reader, this is getting into advanced things and proceeding without having familiarity with linux and iptables may be painful (to you and your neighbors). Also, these rules will only work when the gateway is advertised, which should be coordinated with your local meshers. I've been meaning to find the time to work up rules when the gateway is not advertised.
Here is a preferred set of rules and example script, below.
Joe AE6XE
------------------------------59-custom-remote-forwards -------------------------
#!/bin/sh
#
# Custom internet port forwards to remote nodes
#
# upload this file to the mesh node gateway to /etc/local/mesh-firewall/
## This directory includes shell scripts that will be auto executed each time the firewall is reloaded
## Some variables are set in the environment to make checks easier.
## Files should follow the ##-name structure and be marked executable. ( chmod 755 <filename> )
## This directory is NOT saved during an OTA Upgrade
# These rules are uploaded to the gateway mesh node and only work when the gateway is advertised
# When not advertised as a gateway, complicated connection tagging and policy route tracking is needed TBD
# Example forwarding traffic to host AA6AA-NSM2 with the following IP addresses
# AA6AA-NSM2's wifi IP Address = 10.10.138.7
# Self Gateway Wifi IP Address = 10.34.163.239
# Self Gateway DtDlink IP Address = 10.35.163.239
# incoming WAN port 8081 is forward to AA6AA-NSM2 port 8080
# Edit and copy the following 3 lines for each forward entry
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 8081 -j DNAT --to 10.10.138.7:8080 -m comment --comment "AA6AA-NSM2"
iptables -t nat -A zone_wifi_postrouting -p tcp -m tcp -d 10.10.138.7/32 -j SNAT --dport 8080 --to-source 10.34.163.239 -m comment --comment "AA6AA-NSM2"
iptables -t nat -A zone_dtdlink_postrouting -p tcp -m tcp -d 10.10.138.7/32 -j SNAT --dport 8080 --to-source 10.35.163.239 -m comment --comment "AA6AA-NSM2"
-----------------------------------------------------------------------
Joe,
Thank you for the sample script. Following is what I put together with no luck. Your model is definitely different than what I had built with the old Linksys nodes especially as there was no entry for the MeshGateway DtDlink.
#!/bin/sh
#
# Custom internet port forwards to remote nodes
#
# upload this file to the mesh node gateway to /etc/local/mesh-firewall/
## This directory includes shell scripts that will be auto executed each time the firewall is reloaded
## Some variables are set in the environment to make checks easier.
## Files should follow the ##-name structure and be marked executable. ( chmod 755 <filename> )
## This directory is NOT saved during an OTA Upgrade
# These rules are uploaded to the gateway mesh node and only work when the gateway is advertised
# When not advertised as a gateway, complicated connection tagging and policy route tracking is needed TBD
#AI6BX-2-Home “mesh gateway” WAN IP 10.74.0.106
#AI6BX-2-Home “mesh gateway” DtD IP link from OSLR 10.75.0.106
#AI6BX-6-Link “destination node” WAN IP 10.68.151.139
#AI6BX-6-Link DHCP lease 10.36.188.90 IRLP / 10.36.188.92 target hostPC .89 node
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 50 -j DNAT --to 10.68.151.139:50 -m comment --comment “AI6BX-6-Link”
iptables -t nat -A zone_wifi_postrouting -p tcp -m tcp -d 10.68.151.139/32 -j SNAT --dport 50 --to-source 10.74.0.106 -m comment --comment "AI6BX-2-Home”
iptables -t nat -A zone_dtdlink_postrouting -p tcp -m tcp -d 10.68.151.139/32 -j SNAT --dport 50 --to-source 10.75.0.106 -m comment --comment "AI6BX-6-Link”
I saved this script as 02-wanwall in the mesh-firewall directory and then rebooted the node with no luck when accessing from the Internet. I know the fowarding on the ISP router is working as I can access the node through the forwarding set up there.
With this failure, I tried modifying one of the original scripts I had written that worked for the Linksys nodes and loaded it to the 02-wanwall file created. Following is what I used on this attempt:
#Next Attempt - Old script modified
#Mesh Mail
iptables -A input_wan -p tcp --dport 50 -j ACCEPT
iptables -t nat -A prerouting_wan -p tcp --dport 50 -j DNAT --to 10.36.188.92
iptables -A forwarding_wan -p tcp --dport 50 -d 10.36.188.92 -j ACCEPT
iptables -t nat -A postrouting_wan -p tcp -d 10.36.188.92 -j SNAT -dport 50 --to-source 10.68.151.139
Again, no luck. I have been successful with this in the past both with Mesh nodes and dd-wrt access points so am more than just a little perplexed. Do you see anything obvious here that I have missed? Am I correct in assuming the previous directories and files names used in the past, etc/confg firewall.user are no longer used?
Thank you for any assistance you can provide.
Keith - AI6BX
I'm not entirely sure of the specifics in your configuration. If I take a best guess at rewriting the original linksys rules you posted, I think this is what it needs to be. You had port '50' in your testing, but here's the linksys example of forwarding port '8088':
# IRLP IP address we are forwarding the traffic to is 10.36.188.90
# gateway mesh node WIFI IP address is 10.74.0.106 (the --to-source 10.x.x.x is the gateway 'source' address of the packet going to the Destination IRLP linux host, so this IRLP host knows what IP address to send the packets back to )
# gateway mesh node DtDLink IP address is 10.75.0.106
iptables -t nat -A zone_wan_prerouting -p tcp -m tcp --dport 8088 -j DNAT --to 10.36.188.90:8080 -m comment --comment “AI6BX-IRLP”
iptables -t nat -A zone_wifi_postrouting -p tcp -m tcp -d 10.36.188.90/32 -j SNAT --dport 8088 --to-source 10.74.0.106 -m comment --comment "AI6BX-IRLP”
iptables -t nat -A zone_dtdlink_postrouting -p tcp -m tcp -d 10.36.188.90/32 -j SNAT --dport 8088 --to-source 10.75.0.106 -m comment --comment "AI6BX-IRLP”
The linksys "input" rule shouldn't be needed to do a port forward (input chains are for traffic intending to reach a program running on the gateway node).
The linksys "forwarding_wan" rule seems odd (the IP address used), but no equivalent rule is needed--there are default rules that already ACCEPT all port forwards (ctstate DNAT) from WAN->WIFI and WAN->DtDlink interfaces going through the gateway node.
Note, the /etc/firewall.user is still there. But still 1 file to munge all the firewall rules together. /etc/local/mesh-firewall/* is exactly the same thing, just separating the firewall rules by purpose into individual files. You could have a file for IRLP, another for a video ipcam, etc. Be sure to "chmod 755 /etc/local/mesh-firewall/02-wanwall" after copying the file to this location.
Joe AE6XE
have you had any luck integrating any of the old Linksys BBHN nodes to the AREDN network. I do have one link I would like to keep in the mix as the user has a pretty elaborate set up at his QTH and is not real inclined to replace all the nodes. The main link node is about 25 feet from my Rocket on the repeater tower so I would love to do a DtD link if possible. I seem to see mixed reviews on this around the AREDN and BBHN sites. Any tips/guidance would be great.
Keith
If not already, see coverage map link hidden at the very bottom:
https://sites.google.com/site/orangecountymeshorganization/orange-county...
Joe AE6XE
Hi Joe:
Would this example still work if tunnels are in the mix as well? This sounds like something I am trying to do:
https://www.arednmesh.org/content/port-forward-wan-remote-node-lan
But I think I am running into problem with tunnels in the mix.
Matt, KB9OIV
I was thinking of putting a rocket with a sector or dish pointed in the direction of Pleasant's Pk. I have to do a little more modeling and save a couple bucks for the equipment before pulling the trigger. Right now I am setting a a hop to CSUSB to gain coverage in San Bernardino in support of their Cyber Security Program. I have a very interested faculty member there that I am working with.
Back to the port forwarding on my mesh up here. I have had great luck with all the forwards for the mesh email server, chat server, zone minder, and a couple other devices but still seem to be getting hung with the IRLP and Echolink portion. I can make the connection with the IRLP reflectors but seem to be blocked on the incoming data stream back so I get no received audio and the Echolink will not negoitiate so I am hazarding a guess that something is hanging with the UDP port protocol. Am I missing a line of code for bi-directional packet handling?
Thanks!
Keith
I'm waiting on a shipment of a 4-pack of reflectors to pair with NanoStations: .http://www.kpperformance.ca/ubiquiti-m-series-radio-reflector-dish-ld-36... I'll be looking to do distance testing. The cost of this antenna + Nanostation M5 will be $150 or less (ignoring that they only sell these in 4-packs for the moment). It should beat a Nanobridge M5, and come closer in gain to the 2x pricing of a Rocket w/ RocketDish. I want to test these devices side by side. If you have a good spot to set a tripod with line-of-sight to Pleasants Pk in your area or QTH, we should get together. Let me know if this is of interest <callsign> @ arrl.net.
In regards to the firewall rules. I've not setup IRLP before, but I'd assume all these ports may need forwarded:
- 2074 through 2093 UDP - IRLP Audio (bi-directional UDP)
- 15425, 15426, 15427 IRLP Control/Update Ports - TCP
The forward rules would be setup and can put in a port range in one rule. So for UDP protocol rules:iptables -t nat -A zone_wan_prerouting -p udp -m udp --dport 2074:2093 -j DNAT --to 10.68.151.139:2074-2093 -m comment --comment “AI6BX IRLP Audio Streams”
iptables -t nat -A zone_wifi_postrouting -p udp -m udp -d 10.68.151.139/32 -j SNAT --dport 2074:2093 --to-source 10.74.0.106 -m comment --comment "AI6BX IRLP Audio Streams”
iptables -t nat -A zone_dtdlink_postrouting -p udp -m udp -d 10.68.151.139/32 -j SNAT --dport 2074:2093 --to-source 10.75.0.106 -m comment --comment "AI6BX IRLP Audio Streams”
Do the 3 TCP ports in a similar way, but this may be one direction--only needed if this is an incoming connection to the mesh.
Joe AE6XE
iptables -t nat -A zone_wan_prerouting -p udp -m udp --dport 2092 -j DNAT --to 10.36.188.90:2092 -m comment --comment “AI6BX-IRLP Traffic”
iptables -t nat -A zone_wifi_postrouting -p udp -m udp -d 10.36.188.90/32 -j SNAT --dport 2092 --to-source 10.74.0.106 -m comment --comment "AI6BX-IRLP Traffic”
iptables -t nat -A zone_dtdlink_postrouting -p udp -m udp -d 10.36.188.90/32 -j SNAT --dport 2092 --to-source 10.75.0.106 -m comment --comment "AI6BX-IRLP Traffic”
http://www.irlp.net/ts.html
An SNAT fakes out the IRLP local repeater computer to send a reply packet back to the mesh gateway directly, then the gateway plugs back in the IRLP reflector internet address to go back round trip. The break down is that IRLP computer then tries to open up a new audio stream back to the gateway which goes into a black hole, because this new connection never has awareness of the real address of the IRLP reflector on the internet.
SNAT rules become necessary when there are multiple internet gateways and things start breaking as traffic comes in one and tries to go back out another gateway--this is a security concern and if traffic patterns don't match up these connections can be (should be) blocked. The SNAT ensures the traffic comming in to the mesh always goes back out the same gateway. In this case there's only one gateway so is not and issue.
A complete bullet proof solution will require tracking helper rules in the gateway firewall and a smart gateway functionality across the mesh network. We'll cross that bridge if/when we get to it...
Joe AE6XE
This particular configuration must have had IP validation turned off as it was sending new connections with packets to the "spoofed" IP address (and in our case this was a black hole). The irlp test script has opportunity to detect and report unexpected IP addresses--it may or may not be a problem, but worth showing a warning. Disabling IP address validation (or not) paired with only DNAT for a single gateway network is sufficient.
For a multiple gateway mesh network, there is risk this will still fail (wrong gateway is picked by OLSR to route through) and more connection tracking (TBD), with SNAT/DNAT rules, and disable IP address validation in IRLP will be necessary. Rule of thumb for now on a multiple gateway mesh network: treat it like a single gateway mesh and make sure the IRLP device always has shortest path and is routing through the one gateway with the DNAT forwarding rules.