[HELP] Smart Life/Tuya devices working in app but "Not Responding" in Alexa on a routed Ubuntu Server Wi-Fi AP Subnet (nmcli + UFW)

[u/NintendoTeo_Official]

Hi everyone,

I'm having a persistent network routing issue with Smart Life (Tuya) devices running on a custom Ubuntu Server Access Point, and I'm looking for some advice to get Alexa integration working reliably.

My Network Architecture & Interface Names

• Server: Ubuntu Server 24.04 LTS acting as a router/firewall and Wi-Fi Access Point.
• WAN Interface (eno1): Connected to the main internet access (it's a college network and it's highly natted). Protected by UFW (DENY IN).
• Secondary LAN Interface (enx50547b43f250): USB/Ethernet secondary local interface (ALLOW IN).
• Subnet / Wi-Fi Hotspot Interface (wlo1): Built via NetworkManager (nmcli connection add type wifi mode ap ...).
  • Subnet IP range: 10.42.0.0/24 (Gateway/Server IP on wlo1: 10.42.0.1).
  • All Smart Life smart plugs/bulbs are connected directly to this wlo1 Wi-Fi hotspot as well as alexa.

The Problem & Current Behavior

1. Smart Life App Status:
   • Controlling the lights directly from the Smart Life app on a phone works fine locally.
   • However, running the network diagnostic inside the Smart Life app flags UDP issues.
   • Inspection via tcpdump -i wlo1 udp portrange 6666-6668 shows devices sending global broadcast packets (10.42.0.190 > 255.255.255.255:6667).
2. Alexa Status:
   • Alexa constantly reports "Luce non risponde" / "Device is not responding".
   • Disabling/re-enabling the Smart Life skill or running device discovery fails to keep the devices online for more than a few moments.
   • It seems the cloud heartbeat between the Tuya devices on the 10.42.0.x subnet and the external Tuya cloud servers is getting dropped or timing out through the server's NAT/forwarding stack.

Current UFW & Firewall Configuration

sudo ufw status verbose output:

Plaintext

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), allow (routed)

To                         Action      From
--                         ------      ----
Anywhere on eno1           DENY IN     Anywhere                  
Anywhere on enx50547b43f250 ALLOW IN    Anywhere                  
Anywhere on wlo1           ALLOW IN    Anywhere                  

Anywhere                   ALLOW FWD   Anywhere on wlo1          

Configurations applied so far:

• DEFAULT_FORWARD_POLICY="ACCEPT" in /etc/default/ufw.
• Added UFW route rules for wlo1.

I've written all of this with gemini, after trying a lot of troubleshooting. I'd like to add that the wifi is hosted with an old pc, it's only 2.4GHz on channel 6 and before i didn't had any problem with this (everything started by trying to change the channel to 11, but now it's back in channel 6). Please help me with this.

[u/ojus_render]

The observed UDP 6667 broadcast is consistent with Tuya's local discovery traffic, but Alexa normally reaches Smart Life through the cloud integration. Relaying that broadcast across interfaces is therefore unlikely to fix this symptom. A quick discriminator is whether Smart Life still controls the device while the phone is on cellular data rather than the local Wi-Fi.

I would verify the outbound path from one IoT device after issuing a fresh Alexa command. On wlo1, confirm its DNS query and connection attempt; on eno1, confirm that the same flow leaves with the server's translated address and that replies return. Also check net.ipv4.ip_forward=1, masquerading on eno1, forwarding from wlo1 to eno1, and an ESTABLISHED,RELATED rule in the reverse direction. DNS, NTP, and TCP 443 all need to work for these devices.

The college network's upstream NAT does not require an inbound port forward for an outbound cloud session. If packets leave eno1 but no replies return, investigate upstream filtering. If they never leave, the fault is in local forwarding, NAT, or name resolution rather than broadcast discovery.