It would be nice to be able to use echolink on my ASL3 node (Rpi 4 + Shari) away from home through my T-mobile phone hotspot but it would need to use an echolink proxy server like the echolink iphone app due to the NAT issues with T-mobile.
Yes, chan_echolink will handle proxy, relay, and direct incoming connections.
Excellent! Thanks Chuck. How does one configure a proxy or relay in the echolink channel driver? I didn’t see anything obvious in the echolink.conf file.
Are you asking if ASL3 will accept connections from a proxy or are you asking if it can act as a proxy? Those are two different things.
If you are asking if an ASL node can login to EchoLink using a proxy or public relay, I don’t think it can, though it can certainly accept connections from other nodes using them, assuming no CG-NAT.
The only way I know to have full EchoLink functionality on CG-NAT with ASL is by using a VPN with appropriate forwarding on the exit node, or by using an ASL node in the cloud, which has no internet restrictions, then making an IAX connection to it from another ASL node, which can be behind CG-NAT.
I have done a few self-hosted Wireguard configurations to allow ASL nodes to accept inbound connections to both ASL and EchoLink, regardless of the connection type. Unfortunately, EchoLink only allows one node per public IP address, so I can only forward one EchoLink host per VPS without buying a bunch of IP addresses. I’m so glad ASL doesn’t have that restriction.
44net now has Wireguard support (still in beta, I think.) I’ve not used it, but I know a few who have, and you can get a small subnet of addresses there for free as an amateur radio operator.
Wireguard is relatively easy to install and configure on Debian.
Thanks Patrick. Was hoping to avoid the VPN route but may need to give in and go that way. I did find a reference to adding the following statement to the echolink.conf file:
proxy=proxy_address:8100:PUBLIC
Tried adding this with a valid public proxy address and restarted Asterisk but it still appears to be registering the node on echolink directly vs through the proxy.
Brent, $11 a year rent a server from racknerd, you can either use openvpn or wireguard. Have your node see that IP address all the time, then your port forwarding issue is solved. VPN is not a bad way to go.
Just a quick update. I did grab an $11/yr VPS (great tip!) with Debian 12 and installed the Wireguard VPN server & UFW firewall on it. Installed the Wireguard client on the ALS3 node (Rpi4+Shari). After much trial and error, finally got it working but had to disable the UFW firewall which was refusing to forward anything even through the proper ports were allowed (mirrored the allowed ports on the ASL3 firewall plus the wireguard port) and ipv4 forwarding was enabled in sysctl.conf. I then decided to try replacing UFW with firewalld to see if I could cut down the wide open VPN traffic. Finally figurred out you not only need to allow the required incoming ports (from the internet) but you also need to explicitely forward them to the Rpi’s VPN address (I suspect there is a way to forward any incoming port that is allowed vs individual port forwarding but I’m new to firewalls and learning as I go). That worked until the power went out and Rpi restarted. Seems there are several services that don’t reliably start over the VPN. Not sure if there is a port I’m missing that is only needed at reboot or if there is a race condition between the VPN getting re-established and the services starting up. Anyone else struggled with this. Thinking I may need to add a travel router to the solution in order to terminate the VPN there vs having the VPN client on the ASL3 node itself but trying to avoid yet another box to drag along. Any suggestions?
Likely the problem was your netfilter rules weren't saved or weren't saved correctly. Depending on exactly what you're doing, you need to be directing certain traffic into the tunnel, likely in the prerouting table so that Echolink traffic goes up your wireguard interface and is the NAT'd at your VPS. Don't try to do your NATing anywhere other than on the public IP of your VPS.
Greetings:
I’ve done a few self-hosted Wireguard configurations lately, both on HamVoIP and ASL3.
My general rule of thumb is to drop everything on the VPS by default, then only allow what you want to be exposed, plus forwarding for those services if they are on the other side of a VPN. I’m currently doing all this with iptables, because that’s what I’m most familiar with.
I haven’t experienced any problems with running services not starting as expected on reboot once a VPN connection is established. Could you elaborate more on that?
I do wonder, though, if a Raspberry Pi without a real time clock has been turned off for a long time, if the VPN connection routing all internet traffic won’t work because the time is significantly off when keys are shared, because the time doesn’t update before attempting to establish a connection. By default, if the Wireguard server endpoint can’t be routed through, traffic doesn’t fall back to anything.
That has potential for breaking things.
wget https://git.io/wireguard -O wireguard-install.sh && bash wireguard-install.sh
That's the script I used to install on Debian 12.
Once you install UFW edit the /etc/default/ufw file.
# The line that reads "DEFAULT_FOWARD_POLICY="DROP" Change the word "DROP" to "ACCEPT" ctrl +x then Y to save and exit
Add the following text to the bottom of etc/ufw/before.rules
# NAT table rules
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# Port Forwardings
-A PREROUTING -p tcp -i eth0 --dport 15426 -j DNAT --to-destination 10.7.0.2
-A PREROUTING -p udp -i eth0 --dport 4569 -j DNAT --to-destination 10.7.0.2
-A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.7.0.2
-A PREROUTING -p udp -i eth0 --dport 51820 -j DNAT --to-destination 10.7.0.2
-A PREROUTING -p udp -i eth0 --dport 44966 -j DNAT --to-destination 10.7.0.2
# Forward traffic through eth0 - Change to match you out-interface
-A POSTROUTING -o eth0 -j SNAT --to-source xxx.xxx.xxx.xxx
# don't delete the 'COMMIT' line or these nat table rules won't
# be processed
COMMIT
The script automatically uses 10.7.0.2 as the LAN IP address for your client.
Use the format for opening whatever ports you want. I use this script because it’s the only one I’ve found that I can build a VPN in less than a minute, and I’ve had no issues with it surviving a reboot, or changing endpoints. By changing endpoints I mean shutting down the node and taking it mobile, putting it on my mobile ISP vs my home ISP.
Wireguard keys are just Curve25519 keys. They are not time-bound keys.
Thanks for the help. Agree with the drop all incoming (from the internet) except the ports needed for IAX2 (4569), cockpit (80, 443, 9090), echolink (5198, 5199) & DVSwitch Mode Switcher (3000).
When the power went out (for ~1hr) and came back on, I could connect cockpit via the VPN but Allstar & Echolink connections (originated from my node) failed and DVSwitch wasn’t running. Debugging I noticed a couple of service starting errors in the cockpit admin portal, I didn’t write down the specifics but one was associated with validating an IP connection, and the other was related to updating the available node file. The one related to validating the IP connection succeeded when I reran it but the node file update failed again. Determined the Allstar registration was pointing to the non-VPN IP address. Traced the DVswitch issue to the Analog & MMDVM services not starting due to a missing dependency. Hence, the concern that the VPN tunnel may not have been up before some of the starting services tried to access the network.
Thanks for the help. If memory serves, I used a different approach to install wireguard but used exactly the recipe you sent to mofify the before.rules file. For some reason it wasn’t forwarding eth0 → wg0 traffic even with the prerouting when UFW was enabled but seemed to work when it was disabled (which seemed to forward everything). Hence the attempt to use firewalld instead of UFW which seems to be working once I added the forwarding equivilents of the PREROUTING statements above.
It took me awhile, but in /etc/default/ufw. Changing the forwarding policy is what made mine work properly
Excellent catch! I didn’t see that in any of the tutorials I looked at and didn’t catch it myself. Very well could have been the key to getting my UFW attempt working.
BTW, another method that seemed to work for me even without an active firewall program was to add the prerouting statements to the Wireguard wgo.conf on the server as postup (and optionally postdown) statements like the following:
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4569 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p udp -i eth0 --dport 5198 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p udp -i eth0 --dport 5199 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3000 -j DNAT --to-destination 10.10.10.2
PostUp = iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 9090 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 4569 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p udp -i eth0 --dport 5198 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p udp -i eth0 --dport 5199 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 3000 -j DNAT --to-destination 10.10.10.2
PostDown = iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 9090 -j DNAT --to-destination 10.10.10.2
Have not been able to repeat the VPN reboot issue after moving the preroutes to wg0 postup’s and disabling firewalld so I think this issue is closed. Thanks for your help everyone!!! Much appreciated.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.