# Post forwading and AT&T

**URL:** <https://community.allstarlink.org/t/post-forwading-and-at-t/19835>\
**Category:** AllStarLink\
**Created:** [January 5, 2023, 9:24pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835 "2023-01-05T21:24:47Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![WG4USA](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wg4usa/32/4266_2.png) [@WG4USA](https://community.allstarlink.org/u/WG4USA)\
**Post date:** [January 5, 2023, 9:24pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/1 "2023-01-05T21:24:47Z")

</div>

I finally got AllStar installed,

HamVoIP Firmware - RPi2-3-4 Version 1.7-03

HamVOip AllStar - Asterik 1.4.23-pre-voip-V1.7.1-04

I can dial everything locally, and I get good tones, etc.

BUT I have AT&T and I’m having issues with their firewall/router, I think. I have port 4569 port forwarded to the RPI4

As per attached pic, I can dial out, but I never connect to said node.

Any other suggestions?

---

<div class="post-metadata">

**Author:** ![AG2AA](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/a/d9b06d/32.png) [@AG2AA](https://community.allstarlink.org/u/AG2AA)\
**Post date:** [January 6, 2023, 10:52am UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/2 "2023-01-06T10:52:47Z")

</div>

Hi Rod. I don’t see your attachment. I had a similar issue with an AT&T wireless hotspot from netgear. I was not able to get it resolved as there are too many NATs (network address translations) between your node and the outside world. Someone with better networking skills than I may be able to offer some suggestions similar to these from the hamvoip site [https://hamvoip.org/howto/Configuration\_of\_a\_Reverse\_Tunnel.pdf](https://hamvoip.org/howto/Configuration_of_a_Reverse_Tunnel.pdf)

hope this helps - I never got around to trying it…

---

<div class="post-metadata">

**Author:** ![WG4USA](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wg4usa/32/4266_2.png) [@WG4USA](https://community.allstarlink.org/u/WG4USA)\
**Post date:** [January 6, 2023, 2:28pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/3 "2023-01-06T14:28:27Z")

</div>

That’s weird. I know I attached it.

Thank you for replying. Seems what I did have setup is working. I was just attempting to dialing a node that was offline

---

<div class="post-metadata">

**Author:** ![AG2AA](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/a/d9b06d/32.png) [@AG2AA](https://community.allstarlink.org/u/AG2AA)\
**Post date:** [January 6, 2023, 7:47pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/4 "2023-01-06T19:47:01Z")

</div>

well since you did have it working, what was the trick? was it a wireless AT&T or like a home connection? If you figured out the wireless NAT, I’d love to know.

---

<div class="post-metadata">

**Author:** ![WG4USA](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wg4usa/32/4266_2.png) [@WG4USA](https://community.allstarlink.org/u/WG4USA)\
**Post date:** [January 7, 2023, 11:28am UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/5 "2023-01-07T11:28:43Z")

</div>

wifi is dhcp, could not get a static IP for it.

Port forwardng , i used this as a template

[https://www.att.com/support/article/u-verse-high-speed-internet/KM1215101](https://www.att.com/support/article/u-verse-high-speed-internet/KM1215101)

---

<div class="post-metadata">

**Author:** ![AG2AA](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/a/d9b06d/32.png) [@AG2AA](https://community.allstarlink.org/u/AG2AA)\
**Post date:** [November 2, 2026, 5:44pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/6 "2026-11-02T17:44:45Z")

</div>

It has to do with convincing debian to use IPv4 instead of IPv6 and using an IAX registration instead of http. I can now make outgoing connections just fine using the htspot but incoming still won't work because of the CGNAT. Here's the session synopsis from ChatGPT.

AllStarLink IAX Registration: IPv6 Timeout and IPv4 Preference  
Workaround

Field report: November 1, 2026 | Node: 419736 (HT-Portable-Node) | Platform: ASL3 on Debian | Network:  
T-Mobile cellular hotspot, carrier-grade NAT (CGNAT)

Summary  
A portable ASL3 node configured for IAX registration timed out when Asterisk resolved the AllStarLink registration hostname to an IPv6 destination. Temporarily substituting a DNS-resolved IPv4 server address immediately produced a successful registration, and the node successfully initiated an outbound AllStarLink connection. The hostname was then restored and Debian address-selection precedence adjusted to prefer IPv4. Following a reboot, registration and outbound linking both succeeded. This is a single field observation, not a claim of general IPv6 incompatibility or long-term reliability.

Objective and environment  
Use the AllStarLink documentation procedure "Using IAX Registration Instead of HTTP Registration" for a portable node operating behind T-Mobile CGNAT. The operational requirement was successful IAX registration and outbound-initiated node connections; unsolicited inbound connections were not required or tested.

Documentation: [IAX-Based Registration - AllStarLink Manual](https://allstarlink.github.io/adv-topics/iaxreg/)

Observed failure  
DNS returned both IPv4 A and IPv6 AAAA records for [register.allstarlink.org](http://register.allstarlink.org). The Asterisk CLI showed an IPv6 registration destination and a timeout:  
HT-Portable-Node\*CLI\> iax2 show registry  
Host: [2607:7700:0:57::3415:a9c5]:4569  
Username: 419736  
Perceived:  
Refresh: 60  
State: Timeout

This established that Asterisk was attempting registration via IPv6. It did not independently establish why the IPv6 attempt timed out.

Controlled IPv4 test  
A DNS-resolved IPv4 address for the same registration hostname (52.21.169.197) was temporarily used as the destination in the existing register =\> entry in /etc/asterisk/iax.conf, preserving the existing credentials. After restarting Asterisk, the registry showed:  
Host: 52.21.169.197:4569  
Username: 419736  
Perceived: 172.56.7.109:62158  
Refresh: 180  
State: Registered

The perceived address and translated UDP source port were consistent with NAT traversal. An outbound connection to another AllStarLink node was also successful. This strongly implicated IPv6 destination selection in the earlier registration failure.

Persistent configuration change  
The original registration hostname was restored in iax.conf to avoid reliance on a fixed server IP. The following address-selection precedence entry was added or uncommented in /etc/gai.conf:

precedence ::ffff:0:0/96 100

This requests preference for IPv4-mapped addresses in applications that follow the system address-selection policy; it does not disable IPv6. After a full reboot, IAX registration succeeded and the node again initiated an outbound connection successfully. The exact post-reboot registration destination was not recorded, so the evidence supports the practical workaround but does not independently confirm which address family Asterisk used after reboot.

Verification and limitations  
Verified: dual-stack DNS answers; initial IPv6 registration timeout; successful registration using a temporary IPv4 destination; successful outbound linking; successful registration and outbound linking after restoring the hostname, changing gai.conf, and rebooting.

Not verified: repeated reconnects across hotspot IP changes; long-term stability; inbound initiation through CGNAT; whether the gai.conf policy is consistently honored across all Asterisk/ASL3 builds; root cause of the IPv6 timeout.

Suggested wiki troubleshooting note  
If an ASL3 node using IAX registration shows Timeout and iax2 show registry displays a bracketed IPv6  
registration host, check both A and AAAA DNS results. As a diagnostic, temporarily test a current IPv4 address resolved for the registration hostname (do not treat it as a permanent endpoint). If registration succeeds, restore the hostname and consider the IPv4 precedence entry in /etc/gai.conf, followed by a reboot and another registry/linking test. Document that this is an observed workaround, not a universal fix.

---

<div class="post-metadata">

**Author:** ![WA3WCO](https://community.allstarlink.org/user_avatar/community.allstarlink.org/wa3wco/32/3123_2.png) [@WA3WCO](https://community.allstarlink.org/u/WA3WCO)\
**Post date:** [November 2, 2026, 6:26pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/7 "2026-11-02T18:26:27Z")

</div>

The issue with your ASL3 node registering using an IPv6 address should now be fixed. For a short time we had inadvertently added an AAAA (IPv6) record for the  
"[register.allstarlink.org](http://register.allstarlink.org)" servers when only the A (IPv4) record should have been present.

Changes to your `/etc/gai.conf` file should no longer be needed.

**Update** : It looks like I misunderstood some internal communications and only A records should have been present for "[register.allstarlink.org](http://register.allstarlink.org)". Please see @N8EI's question below.

---

<div class="post-metadata">

**Author:** ![N8EI](https://community.allstarlink.org/user_avatar/community.allstarlink.org/n8ei/32/4254_2.png) [@N8EI](https://community.allstarlink.org/u/N8EI)\
**Post date:** [November 2, 2026, 7:34pm UTC](https://community.allstarlink.org/t/post-forwading-and-at-t/19835/8 "2026-11-02T19:34:14Z")

</div>

The host `register.allstarlink.org` should never have returned an AAAA record. What's the output of `dig +short register.allstarlink.org aaaa` reporting on your Linux OS?
