You are here

Port Forwarding from WAN to LAN on remote node

23 posts / 0 new
Last post
Ai6bx
Port Forwarding from WAN to LAN on remote node
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
kg9dw
kg9dw's picture
*REMOVED*
*REMOVED*

I've removed my post as it uses a hack that is no longer needed. 
AE6XE
AE6XE's picture
custom firewall handling and
custom firewall handling and forwarding to remote nodes

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"
-----------------------------------------------------------------------
Ai6bx
Gave it a go with no luck

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

AE6XE
AE6XE's picture
Keith, 
Keith, 

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

 
K5DLQ
K5DLQ's picture
also, you must either reboot
also, you must either reboot or restart the firewall to pick up new changes in that directory.
Ai6bx
Yep
Yep, I have been doing that each time as it was always standard with the Linksys stuff.

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.
K5DLQ
K5DLQ's picture
You can absolutely link AREDN
You can absolutely link AREDN and BBHN nodes with DtdLinking.  The only issue, is enabling dtdlink on Linksys nodes.  It's off by default due to some hardware flaws/incompatibilities with certain devices.  Search the forums here for details.
 
Ai6bx
Thank you
Thank you, Joe. I will give this a go tonight and wee what results I get.

Keith
Ai6bx
Thank you, Joe!
everything is working flawlessly now. Next step getting linked to Pleasant Peak.
AE6XE
AE6XE's picture
Looks like your QTH is 32.6
Looks like your QTH is 32.6 miles out from Pleasants Pk.   What antenna-device are you planning to use?    With the 5Ghz sector antenna specs, this band has the narrowest beam width of 4 degrees vertical.  At the 4000' height, and if I did the trig right, this means the 6dB coverage limits are at ~7 miles closest and ~22 miles farthest +/- the down-tilt error.   W6RYO in Rancho Cucamonga is using a ~27dBi AirGrid at ~25 miles and maintaining 100% LQ/NLQ.   The radio mobile coverage map is also showing some blockage in your QTH area.  Do you have visual line-of-sight?   

If not already, see coverage map link hidden at the very bottom:
https://sites.google.com/site/orangecountymeshorganization/orange-county...

Joe AE6XE
 
KB9OIV
Hi Joe:
Hi Joe:

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

Ai6bx
Couple more questions
Joe,

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
AE6XE
AE6XE's picture
Keith,
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
Ai6bx
A thought
Is it possible I have something set wrong in my Netgear switch? WAN is in 5 and my node with the firewall script is in 1. Ports 2-4 have my RASPBX, phone, and a mesh AP respectively.
AE6XE
AE6XE's picture
If just the IRLP traffic that
If just the IRLP traffic that isn't working through the switch, and there is other traffic going though,  then I'd suspect the issue is the firewall rules.
Ai6bx
I have a very similar script in place
I had modified your earlier template for the UDP as follows with entries for 2074-93 as well as 15425-27

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”

 
kg9dw
kg9dw's picture
what's failing?
When you run the irlp test script, what comes up as failing?

http://www.irlp.net/ts.html

 
AE6XE
AE6XE's picture
Problem solved
Keith and I wrestled this issue to the ground and have a live deployment now.    Long story short, the IRLP application is written such that an "SNAT" rule in the firewall rules will break it.  We are only using the DNAT rule at this point.  

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

 
K5DLQ
K5DLQ's picture
good work Joe!  
good work Joe!
 
AE6XE
AE6XE's picture
Unfortunately, the irlp test
Unfortunately, the irlp test script passed and does not identify this particular incompatible setting through a NAT firewall.   Would be good if someone posted this thread URL back to the IRLP developers to have awareness of.  symptoms are that audio only goes one direction and not the other--the direction appeared to depend on which side of the fence initiated the connection.
kg9dw
kg9dw's picture
Stick a post-it on your
Stick a post-it on your virtual memory board that if you try to do SNAT/DNAT with svxlink and Echolink it will not work by default. The application does an IP address validation against a central directory to prevent spoofing. You have to route the real IP address to the host, or you have to change some of the config to disable the IP address validation. 
AE6XE
AE6XE's picture
This particular configuration

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.
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer