AT&Ts CGNAT is messing this up.
It’s presenting a different IP address in HTTP registration than it uses for outbound “other things” like IAX2/UDP.
This is rendering HTTP registration useless in this case.
It’s this well known? and does it come up often?
I guess I can just fallback to IAX registration.
This also seems to indicate that IAX registration needs to stick around and not go away?
CGNAT and “providers” dumbing down and stupidifying Internet connections really sucks.
This is a dynamic AT&T IP address so I really don’t mind sharing it.
I also verified outside of Allstarlink that AT&T wireless is indeed presenting different IP addresses
public facing if the traffic is HTTP (port 80) or something else.
[2025-02-08 01:23:54.483] WARNING[106917][C-00000da5]: app_rpt.c:6098 parse_caller: Node 272981 IP 107.122.241.137 does not match link IP 107.122.244.178!!
Yep, this is really bad with T-Mobile as well. For my part, I use a self-hosted Wireguard VPN, with a client on the node, so my IP address is always the same. This works with both IAX and HTTP registration, and also, with appropriate firewall configuration, allows incoming connections with CG NAT as well.
You could use 44net if you don’t want to host a service yourself, but I already had the infrastructure in place, so decided to use it.
Even if you fall back to IAX registration, sometimes, IP addresses on mobile providers change frequently enough that establishing connections to some nodes is problematic.
There’s a whole page written about this in the manual.
I’ll second that–I have a mobile node that connects to my OnStar 4G LTE service and has similar issues. I setup a hub node on a virtual machine that brokers all of my connections to the outside world, and leverage WireGuard with all of my other nodes to connect to the hub. I also forwarded firewall ports for Cockpit (even though I don’t use it, really), Asterisk Manager for allmon3 access, and other tweaks to make control from the hub easy. A challenge, for sure–good luck, hope you find a workable solution, @n8lbv.
As ASL evolves, we will have rethink how registration happens and connections are granted. Right now, the protocol is so old it’s using IAX2 without any of the later security features. Everything depends on alignment of IP address. That process doesn’t scale in the modern Internet, nor will it work AT ALL with IPv6. Both because IPv6 itself needs to be supported and because one of the features of IPv6 is that your receiving IPv6 address and your sending IPv6 addresses are different.
However before any of that work can start, we need the majority of people on the modern, current platform because improvements to the registration and linking logic are not going to be backwards-compatible in a lot of cases.
This works on TMobile 5g home router using http reg. I have my vps linked out to my repeater.
do you have any instructions on where one could roll their own wireguard VPN?
Super easy.
This is a little older, but still applies: How to Build Your Own Wireguard VPN in Five Minutes
IAX registration is the only real solution for now.
Easy for me, I’m a network guy-
But not easy for my users or people getting started with ASL3.
All of the suggested solutions here so far are not really “easy” solutions. They all require some expertise and they all require a 3rd party hosted additional paid service in the cloud or a VPS to be able to tunnel back to your mobile location.
Indeed ZeroTeir or any of these are cool solutions but not easy out of the box solutions.
I have to agree with @n8lbv on this. I have a mountaintop site running ASL3 server with a T-Mobile modem, hosting 4 nodes, and most of the time now I can’t connect back to any Allstar Nodes on the network. If I ssh to one of my other nodes at another location and view the incoming connection, it rejects the connection from any node at the T-Mobile site with the last octect in the IP showing a stale address. This mismatch of IP’s causes the rejection, yet a ping between nodes shows correct IP’s all the way around. So why Allstar is not getting updated IP’s in a timely manner, I don’t know. I really want HTTP registrations to work, I’ve tried both File and/or DNS lookup combinations, no luck. True these other Allstar nodes are a mix of legacy Allstar and Hamvoip, but none the less. So it looks like I’m going to have to revert to ALS3 IAX registration for now. Will switch back if this ever gets working and really appreciate the Allstar team’s work in this direction.
This is just an early-on thought really-
But I wonder if HTTP reg. could be done on a set of alternate ports and if that would fix anything-
If the client is not using port 80 maybe this will bypass the transparent HTTP proxies that are being forced by provider may get bypassed easily.
I think the point that @DavidKG5RDF was trying to make is that if you want capabilities to make direct inbound connections to your node behind a CGNAT of some type, you’re going to need a hosted server somewhere to do this. Localxpose is one service but it could also be a reverse tunnel to a home router, vps, or whatever. I personally like Tailscale, especially with multiple NAT’d remote nodes. However I have been experiencing issues with remote nodes local address being reported back to Allstar instead of the public IP, and that mismatch causing the same issues as Allstar DNS mismatch. I’ve tried masquerading the local IP but not much luck. Then of course the remote node could always be a private node connecting out to a hub node somewhere, and that being the advertised address on the network for users. I think I’m going to start a Tailscale/Zerotier discussion to see who has had 100% success with Allstar inbound and what configurations they have found work well on the ExitNode back to the Allstar Node.
For what it’s worth, I have yet to have the node report it’s IP rather than the one through which it tunnels through my self-hosted Wireguard. Tailscale also uses Wireguard, but I’m not using Tailscale in this case.
The client is sending all it’s internet traffic through the VPN, which is forwarding IAX2 and Echolink ports to the node. I can even use IAX registration on a mobile hotspot reliably this way.
I have deployed a few clients on a couple of VPN setups like this. Some on Starlink, some on T-Mobile and Verizon.
In my own personal case, where my remote base lives, there is a fiber ISP that does CG-NAT, for some reason, so I’m using it on that as well.
When setting up my Wireguard servers on a Debian 12 VPS, I used PiVPN to make configuration management easier, and built firewall rules to allow incoming connections using iptables. If I were to do it again, I’d probably use ufw instead of iptables, just because it’s a little easier to understand.
https://www.pivpn.io/
Using a remote node to handle your traffic is also a good approach, particularly if you want to handle inbound connections. While you can do this successfully using a VPN and a mobile hotspot, it’s less than ideal when you’re traveling between towers, trying to host connections or maintain existing ones as your signal jumps around, latency spikes all over the place, etc. With another node in a data center or back home providing connectivity, the higher tier node is doing most of the work, and your mobile client, the weakest link, won’t screw up other connections.
I’d say, for the best experience, doing both of these things is the way to go. Maintain a connection to your remote node through a VPN with a static IP address on the client, so that never changes, , then send your traffic through the larger node rather than connecting directly to nodes from your mobile hotspot, even with a VPN, especially if you’re on the move. This is maybe less important if you’re on a fixed 5g connection at home with a decent signal and good throughput most of the time. You can even use a private node on the VPN rather than having two public nodes connecting to each other if you never want or need to make a direct connection to a node outside of your control through your VPN/mobile hotspot.
If you want to seamlessly tunnel AllStarLink v3 through a wireguard (or any) type of tunnel, you have to route all UDP packets for your IAX port and outbound HTTP on ports 80 and 443. The IP address your HTTP-based registration call comes from is your public IP address that will be used in the database. If your HTTP and UDP packets don’t have the same egress IP address, it’ll never work. If you have to have outbound HTTP outbound not through your tunnel, then you’ll have to use IAX-based registration. There’s no way around it - that’s how the protocol works today.
@N2DYI Patrick has some good remarks and yes, with a mobile node bouncing all over the place, an outbound connection to a proxy or “hub” node will offer some stability (as should a VPN connection I would imagine). @N8EI that makes sense however we are experiencing the infamous T-Mobile HTTP proxy and cacheing on those ports and that might be another reason the remote node is seeing a different IP? I switched back to IAX for the node directory, but what is stil not working is node status which appears to still be going out over HTTP. The status updates are all getting rejected by Allstarlink.org so I had to disable that in rpt.conf.