IAX2 registration/connection works via 44Connect, but not through WireGuard VPS

AllStarLink
1

Hello everyone,

I am having a strange networking issue with my AllStarLink node and would appreciate some help.

My node is 44772, running ASL3 / Asterisk 22.9.0 on a Debian-based Mini PC.

I recently moved the network connection to a public-IP VPS using WireGuard.

Network setup

My local Mini PC does not have a public IPv4 address.

The setup is:



AllStar Node 44772
        |
        | WireGuard
        |
VPS: 165.99.219.245 (Public IPv4)
        |
        | Internet
        |
AllStarLink network

The WireGuard tunnel is working correctly.

Mini PC WireGuard IP:



10.66.66.3

VPS WireGuard IP:



10.66.66.1

The VPS has a real public IPv4 address:



165.99.219.245

There is no CGNAT on the VPS, and I have full control over the VPS firewall/NAT.

The strange part

If I use 44Connect/WireGuard directly, the same AllStar node works normally.

IAX2 registration and node connections work through 44Connect.

However, when I route the Mini PC's traffic through my own public VPS using WireGuard, IAX2 registration to the AllStarLink registration server does not complete.

For example:



52.21.169.197:4569
Username: 44772
State: Request Sent / Timeout

What I have already verified

The Mini PC is listening on the expected ports.

For example:



UDP 4569
UDP 5198
UDP 5199

I also have EchoLink running on the same machine.

The VPS has forwarding/NAT enabled and IPv4 forwarding is enabled.

The VPS firewall is not blocking forwarding:



FORWARD policy ACCEPT

UFW is not installed and firewalld is inactive.

I also verified packet flow with tcpdump.

The IAX registration packet leaves the Mini PC and reaches the VPS:



10.66.66.3:4569 → 52.21.169.197:4569

The VPS then sends it to the Internet using:



165.99.219.245:4569 → 52.21.169.197:4569

However, I do not see an IAX registration response coming back from:



52.21.169.197:4569

Incoming IAX traffic is working

Interestingly, incoming IAX traffic from another node does reach my Mini PC through the VPS.

For example, I can see traffic like:



44.27.136.175:4569 → 10.66.66.3:4569
10.66.66.3:4569 → 44.27.136.175:4569

I also successfully established an IAX2 connection with another node:



IAX2/103.72.65.231

iax2 show channels showed an active channel with:



FirstMsg: Tx:NEW
LastMsg:  Rx:ACK
Format:   ulaw

So node-to-node IAX2 traffic can work through the VPS.

EchoLink

EchoLink also initially failed through the VPS, but after forwarding the required UDP ports:



5198/UDP
5199/UDP

EchoLink started working.

So the WireGuard tunnel and general UDP forwarding appear to be working correctly.

AllStar HTTP registration

Interestingly, HTTP registration works.

The node shows:



HTTP registration:
Username: 44772
State: Registered
Perceived: 165.99.219.245:4569

The AllStar node lookup also shows my public IP correctly.

I also tested alternate ports

I found an older AllStarLink Community post where a user solved a similar problem by changing UDP 4569 to another port such as 14569.

I tested this as well.

The Mini PC was changed to listen on:



14569/UDP

and the VPS was configured to forward:



14569 → 10.66.66.3:14569

The port was reachable and I could see UDP traffic through the WireGuard tunnel, but the IAX2 registration server still did not respond.

I eventually restored the node to:



bindport = 4569

Current VPS forwarding

The VPS is currently forwarding the required ports to the Mini PC, including:



UDP 4560-4580 → 10.66.66.3:4569
UDP 5198      → 10.66.66.3:5198
UDP 5199      → 10.66.66.3:5199

TCP 8080      → 10.66.66.3:8080
TCP 16700     → 10.66.66.3:16700
TCP 16701     → 10.66.66.3:16701
TCP 16080     → 10.66.66.3:16080

The VPS is using MASQUERADE for outbound traffic and has:



net.ipv4.ip_forward = 1

My main question

Why would IAX2 registration work immediately when I use 44Connect, but fail when the exact same AllStar node/configuration uses my own public VPS through WireGuard?

Since:

  • the VPS has a real public IPv4,
  • firewall forwarding is ACCEPT,
  • EchoLink works,
  • incoming IAX2 works,
  • outgoing UDP packets reach 52.21.169.197:4569,
  • HTTP registration works,

I am wondering whether there is something specific about IAX2 registration / source port / NAT / AllStar registration server behavior that I am missing.

Could the AllStarLink registration server be treating the VPS public IP differently, or is there a specific NAT/port configuration required when running an AllStar node behind a WireGuard VPS?

Any suggestions on what I should check next would be greatly appreciated.

Thanks!

S21MEV

2

There's nothing special about 44Net Connect that does ASL/IAX special. Paste in your full nftables rules with nft list table ___ ___.

3

Sure. Here is the complete nftables ruleset from my VPS.

The VPS has a public IPv4 address, and I am using WireGuard to connect my ASL node behind NAT.

44Net Connect works correctly with the same ASL node, including IAX2, but when I route the node through this VPS, IAX2 registration to the AllStar registration server times out.

EchoLink and incoming IAX2 traffic through the VPS work, and I can establish IAX2 connections with other nodes, but the IAX2 registration itself does not complete.

Here is the complete nft list ruleset output:



table ip filter {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                ip saddr 10.200.0.2 iifname "wg1" oifname "eth0" tcp sport 8080                                                                              counter packets 162829 bytes 262376385 accept
                ip daddr 10.200.0.2 iifname "eth0" oifname "wg1" tcp dport 8080                                                                              counter packets 35597 bytes 1683119 accept
                iifname "wg0" counter packets 1039 bytes 90476 accept
                oifname "wg0" counter packets 1207 bytes 1018069 accept
        }
}
# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 10.66.66.3 udp dport 4569 counter packets 1 bytes 53 sn                                                                             at to 165.99.219.245:4569
                ip saddr 10.66.66.0/24 oifname "eth0" counter packets 57 bytes 3                                                                             544 masquerade
                ip saddr 10.66.66.3 udp dport 4569 counter packets 0 bytes 0 sna                                                                             t to 165.99.219.245:4569
                ip daddr 10.66.66.3 udp dport 4569 counter packets 6 bytes 346 s                                                                             nat to 10.66.66.1
                oifname "eth0" counter packets 61 bytes 7077 masquerade
                ip daddr 10.200.0.2 oifname "wg1" tcp dport 8080 counter packets                                                                              39 bytes 2164 masquerade
        }

        chain PREROUTING {
                type nat hook prerouting priority dstnat; policy accept;
                iifname "eth0" udp dport 5198 counter packets 3 bytes 534 dnat t                                                                             o 10.66.66.3:5198
                iifname "eth0" udp dport 5199 counter packets 3 bytes 408 dnat t                                                                             o 10.66.66.3:5199
                iifname "eth0" tcp dport 16700 counter packets 0 bytes 0 dnat to                                                                              10.66.66.3:16700
                iifname "eth0" tcp dport 16701 counter packets 0 bytes 0 dnat to                                                                              10.66.66.3:16701
                iifname "eth0" tcp dport 16080 counter packets 2 bytes 328 dnat                                                                              to 10.66.66.3:16080
                iifname "eth0" udp dport 4560-4580 counter packets 111 bytes 140                                                                             63 dnat to 10.66.66.3:4569
                iifname "eth0" tcp dport 80 counter packets 74 bytes 4124 dnat t                                                                             o 10.66.66.3:80
                udp dport 4569 counter packets 1 bytes 53 dnat to 10.66.66.3:456                                                                             9
                ip daddr 165.99.219.245 udp dport 4569 counter packets 0 bytes 0                                                                              dnat to 10.66.66.3:4569
                iifname "eth0" tcp dport 8080 counter packets 48 bytes 2632 dnat                                                                              to 10.200.0.2:8080

Please let me know if you see anything in the NAT/forwarding rules that could affect IAX2 UDP/4569 or the return traffic from the AllStar registration server.

4

I do not see any rules to foward the packets from the vps to the node. you must pass eth0 traffic and port to the node you are using, I have all my nodes running threw my vps without a single hickup.

5

Something to check. What are the address masks on the two 44net addresses? If they are not set correctly, each end will assume the other is on the same LAN and will expect to use ARP to find the others MAC address.