I have an interesting issue with friend’s Allstar node, that has popped up in the last day or two.
He is using Starlink and when connecting to my hub server running on a VPS in a data centre, my hub server is reporting Node xxxxx IP 65.181.22.1xx does not match link IP 65.181.22.2xx. (Hub is running ASL3.)
I do iax2 show registration in CLI and get Perceived IP as 65.181.22.2xx as registered on my friend’s node. Doing dns-query via bash shell also gives the 65.181.22.2xx as the IP. (Friend is running Hamvoip)
I tried sending his node out via a VPN, which gives him a public IP of 203.29.xxx.xxx (instead of the Starlink IP range) and still getting the same IP does not match error message with the 65.181.22.1xx.
I use my friend’s node to connect to a RPI node in my shack and it can connect fine, showing the from IP as either 65.181.22.2xx or the VPN 203.29.xxx.xxx.
So am I thinking right, that my VPS ASL3 hub server thinks my friend’s node should be coming from the 65.181.22.1xx IP, but is seeing the 65.181.22.2xx and the 203.29.xxx.xxx IP’s?
On the VPS ASL3 hub server I have checked & restarted the update node list service, as well as rebooted the VPS completely, with no change. Interestingly my friend’s node is also seeing the same issue with connecting to another local VK6 hub server, which I believe is also running ASL3.
I found some similar posts here on Allstarlink Community, but none of the suggestions seem to fix my friend’s node.
I believe the issue here is the fact that he uses a vpn tunnel to maintain stability through a changing IP…
But the registration is done through the native IP and not the vpn.
So there is a difference in what is in the registered node list and the actual IP at point of connect.
You might search the forum on this.
It has come up before with startlink, or perhaps someone will chime in with a exact remody.
Thank you for your reply. Even without the VPN, there is a mismatch in IP addresses. The VPN was just used to give the node a different path to the internet connection, in case Starlink were doing some unusual routing.
/usr/local/sbin/dns-query , check_reg.sh and mypublicip.sh all report the same IP address, which is different to what the hub node is expecting to see. Have been doing a fair bit of searching on the Allstar Community and Hamvoip lists already for tips to get things working, but so far no luck. When searching for Starlink, also getting many posts for Allstarlink!
I would say that everything is not being tunneled ‘and’ it is doing some unusual routing with what is not being tunneled.
ASL does not do anything to ip from the point of registration except distribute it to other registered nodes.
I found this in a forum search… and likely as far as I can assist.
I only found 3 relevant posts likely because they were not titled well. But there is more in there somewhere.
Starlink uses NAT. Port forwarding is not possible with NAT. For incoming connections you must use a VPN or proxy.
Many of us have set up VPN servers on VPS host providers such as Vultr. A few of us have implemented VPN servers using 44-net address blocks from AMPRNet for ham radio. I wonder if Allstarlink could provide a VPN or proxy service for Allstar nodes similar to what IRLP does for their nodes?
No detailed documentation, but the process has normally been as follows.
Chose a VPS provider that will support BGP and publish AMPR 44-net subnet for you. Vultr.com has been my, and several other hams, choice due to free BGP, ease of setup and previous knowledge of AMPR 44-net addressing.
Register with AMPR.org and request a 44-net subnet address space. They have instructions on their web site.
Submit a request with your VPS provider for using BGP with AMPR address space. There will need to be a LOA shared and approved with AMPR and your provider. AMPR may handle some interaction with the service provider agreement, but you have start the process and approvals. Vultr provides BGP instructions at these links. Configuring BGP on Vultr - Vultr.com Log In to your Vultr Account - Vultr.com
After configuring BGP on your VPS host, I suggest installing PIVPN.io . Visit the PIVPN.io web site to see what PIVPN does. It will install on a Debian VPS host as well as RPI despite the name. It installs and manages Openvpn (or WireGuard) VPN server software and makes it easier to manage VPN client files. You will need to make a couple of manual edits to the resulting PIVPN and OpenVPN server configuration to use your 44-net subnet space, since PIVPN install does not ask for your 44-net address space details during setup.
I use the smallest ($5/mo) VPS host on Vultr plus snapshots or automatic backup.
Vultr makes it easy to spin up, test, learn, destroy and finally save and backup a working VPS host.
You may wish to enable and manage a server firewall like ufw. Vultr also provides an optional free firewall feature that runs outside of the VPS host in the Vultr account settings.
If you rollout many VPN clients, watch your network usage on the VPS host. Allstar directory updates and some web admin interfaces (supermon/allmon) can use extra network allocation due to inefficient/chatty network use.
I’m happy to help answer any questions you may have. I’ve helped a couple of hams set up 44-net VPN servers on Vultr. Our ham group provides amateur radio VPN/proxy services for north Texas SKYWARN RoIP nodes including Allstar, IRLP and EchoLink.
And I will note that the result is from a hamvoip system and many of us are not aware of the differences in how this might be handled.
It is a hamvoip registration into the asl network.
One might also ask if registration happens before the vpn is established at a minimum.
Maybe the issue here could be with the DNS for .nodes.allstarlink.org not updating, which is where ASL3 might be getting its information.
/var/lib/asterisk/rpt_extnodes has the correct IP (when I switch between Starlink and VPN), but doing a DNS lookup for nodes.allstarlink.org, doesn’t appear to be up to date.
Starlink is only used for outgoing connections, not incoming, so not an issue.
Doing IAX2 Show Registry under CLI shows registration success with Allstarlink.org servers and current (correct) IP, not the IP ASL3 is expecting to see.
Many thanks Mike and have done the asl3-update-nodelist on the ASL3 hub, without success.
I changed the node_lookup_method in rpt.conf from “both” to “file” on the ASL3 hub and have success. So tending to point to a DNS update isn’t occurring with nodes.allstarlink.org.
ASL3 is a VPS in a data centre, so hopefully they are fibre and not cell carrier!
Worth mentioning you should do a apt update and apt upgrade to be sure the asl software is up to date. It seems to me there was a change in one of the updates that pertained to DNS.
But I don’t remember and cant hurt. A restart if it takes any.
Hi N8EI, the ASL3 hub is 51077 and the friend’s node attempting to connect to the hub is 580040. Using file lookup only works, using “both” has the issue.
Can you try back to “both” now? There was a DNS service issue and the zone was stale. I’ve fixed the glitch. I’m working on an entirely new overhaul to the DNS system which should resolve some of these glitchy issues with bad data (not your data) that causes hiccups.
Just back home again and switched back to “both” and all working normally again, node 580040 is able to connect directly again. Much appreciated and glad it was a simple fix in the end!
