GL-BE9300 (Flint 3) domain issue

When connected to Ethernet, my server’s domain becomes inaccessible(only locally accesible), but it works when connected to Wi-Fi.

/etc/init.d/qca-nss-ecm stop into ssh is a workaround.

Hello,

I would like to clarify these:

  1. Is the server installed on the LAN? And create rule of port forwarding and enable DDNS?

  2. In a WAN (Internet), can not access this server through the DDNS domain?

  3. Can WiFi client access the server through a domain? Can LAN wired client access the server through a domain?

Hi,

  1. The server is connected to the LAN. Port forwarding is set up, and a DDNS provided by my ISP is configured.

  2. I can access the server using the DDNS domain on my phone over mobile data.

  3. When my laptop is connected via WiFi, I can access the domain. However, when using a wired LAN connection, I’m unable to access the server through the domain.

Hi,

Thanks for the reply.

Regarding the 3, if /etc/init.d/qca-nss-ecm stop, the laptop which using a wired LAN connection, will be able to access the server through the domain?

Please assist us to do a compare test, laptop using a wired LAN connection:

  1. if /etc/init.d/qca-nss-ecm start, in laptop (Win CMD or Unix Terminal):
    nslookup [your domain]
  2. if /etc/init.d/qca-nss-ecm stop, in laptop (Win CMD or Unix Terminal):
    nslookup [your domain]

I would like to know what the difference is of this domain resolution.

I chose, in my case, Option A below which works for me (I have >1GBs WAN throughput)

Hardware GL-BE9300 (Flint 3)
Firmware 4.5.15 r22468-2004ee9 (Jun 2025)
Setup

  • NGINX reverse-proxy on LAN (192.168.0.56)
  • WAN port connected to eth1 and configured as WAN (the primary eth0 WAN Port DOES NOT negotiate correctly at 2.5G from my VM Modem 5, and therefore doesnt work in my case! Known issue, GliNet are aware.)

Symptom

  • Port-forwards (80/443) work fine from the Internet.
  • From the LAN, browsing to https://<public-IP> or the DDNS host-name hangs at TLS.
  • GL.iNet support confirmed: with Qualcomm NSS hardware-acceleration ON, some return packets bypass nftables, so hair-pin NAT never completes.

With NSS disabled, WAN-LAN routing drops to ≈ 800–950 Mb/s on current firmware according to several user iperf tests; enabling NSS restores full multi-gig throughput.

Fix A – keep acceleration ON (best for >1 Gb s WAN)

  1. SSH to the router
  2. Add a static A-record for each host-name so LAN devices go straight to the reverse-proxy’s LAN IP (NGINX, which in my case is 192.168.0.56):
# one line per domain → LAN-IP
uci add_list dhcp.@dnsmasq[0].address='/example1.ddns.net/192.168.0.56'
uci add_list dhcp.@dnsmasq[0].address='/example2.ddns.net/192.168.0.56'
uci add_list dhcp.@dnsmasq[0].address='/example3.ddns.net/192.168.0.56'

uci commit dhcp
/etc/init.d/dnsmasq restart
  1. On a LAN PC run
    ipconfig /flushdnsnslookup example1.ddns.net
    ➜ should now return 192.168.0.56.
  2. Browse to the site → loads instantly with the correct certificate.

If it doesn’t work:

  • re-check that nslookup shows the LAN IP.
  • run /etc/init.d/dnsmasq restart once more.

Fix B – turn acceleration OFF (quick fallback)

  • GUI Network → Firewall → Global Settings → untick Hardware acceleration (NSS) → Save & Apply
  • CLI (test) /etc/init.d/qca-nss-ecm stop

Reflection works immediately, but WAN throughput 'possibly' caps at ~0.9 Gb s


Summary

  • Need full >1 Gbs? Keep NSS ON and add the three DNS overrides (Fix A).
  • Happy to lose a little speed? Disable NSS and forget the overrides (Fix B).
  • Both methods survive reboots and can be reversed in seconds.
1 Like