# Remote CPEs not sending Inform/Connecting (Local CPEs work fine)

**URL:** <https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296>\
**Category:** Help\
**Created:** [January 13, 2026, 2:37pm UTC](https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296 "2026-01-13T14:37:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![netcom](https://avatars.discourse-cdn.com/v4/letter/n/a6a055/32.png) [@netcom](https://forum.genieacs.com/u/netcom)\
**Post date:** [January 13, 2026, 2:37pm UTC](https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296/1 "2026-01-13T14:37:16Z")

</div>

Hello everyone

I successfully create a GenieACS server, and everything works perfectly with local CPEs. They connect, receive parameters, and accept commit commands without issues.

However, I am facing a problem when trying to connect a **remote CPE**. It fails to connect to the ACS, and I cannot see any logs regarding these attempts on the server.

**Environment & Topology:**

- **GenieACS Version:** 1.2.13
- **CPE Model:** ZTE 670L, Huawei AX2 and
- **Remote Scenario:** The remote CPE receives an IP via PPPoE and is behind a CGNAT.
- **Network Path:** The server has a direct route to the CPE subnet.

**Troubleshooting steps taken:**

1. **L3 Reachability:** The CPE can Ping the GenieACS server IP, and the Server can Ping the CPE.
2. **L4 Reachability:** I performed a TCP connection test from the CPE network to the GenieACS server on port **7547** , and it was successful (Port is open).
3. **Logs:** I checked the GenieACS logs, but there are absolutely no records of the remote CPE trying to initiate a session. I only see logs from my local test CPEs.

**The Question:** Since there is TCP connectivity and no firewall blocking port 7547, is there any specific configuration required for CPEs behind CGNAT or specific routing considerations I might be missing? Why would the server not log the initial handshake attempt?

Any insights would be appreciated!

---

<div class="post-metadata">

**Author:** ![dustin](https://avatars.discourse-cdn.com/v4/letter/d/5daacb/32.png) [@dustin](https://forum.genieacs.com/u/dustin)\
**Post date:** [January 14, 2026, 12:47pm UTC](https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296/2 "2026-01-14T12:47:24Z")

</div>

Are the local CPEs and remote CPEs the same model and firmware?

DR.

---

<div class="post-metadata">

**Author:** ![bajojoba](https://avatars.discourse-cdn.com/v4/letter/b/b9e5f3/32.png) [@bajojoba](https://forum.genieacs.com/u/bajojoba)\
**Post date:** [January 27, 2026, 8:10am UTC](https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296/3 "2026-01-27T08:10:09Z")

</div>

I would check (if you can) if the remote CPE has the right ACS URL set. If you’re on a hosted network they could use their DHCP server to set ACS URL and CPE will accept the one set on the DHCP server. Check if you can acquire logs from the CPE, those should be useful. Because you have already checked the IP connectivity this is the first thing that comes to my mind.

The other one would be that the TR069 client on the CPE is running on a different IP interface and therefore it doesn’t have access to the ACS.

CGNAT doesn’t affect connectivity from the CPE to the ACS. While CGNAT could affect the ConnectionRequest method, but this is not your case.

---

<div class="post-metadata">

**Author:** ![mayo1606](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.genieacs.com/mayo1606/32/2697_2.png) [@mayo1606](https://forum.genieacs.com/u/mayo1606)\
**Post date:** [February 2, 2026, 12:56pm UTC](https://forum.genieacs.com/t/remote-cpes-not-sending-inform-connecting-local-cpes-work-fine/7296/4 "2026-02-02T12:56:04Z")

</div>

Hi @netcom,

1. **TR-069 WAN / Interface**

- Confirm the CPE has **at least one WAN with TR069 enabled** and that this same WAN has:

1. **TR-069 settings on the CPE**

- Verify the TR-069 tab is correct: **ACS URL + username + password** (same as the local working CPEs).

- Confirm protocol/port match (http/https and port).

1. **Force frequent informs + capture on the ACS**

- Set Inform Interval temporarily to **10 seconds**.

- On the GenieACS server run:

```auto
sudo tcpdump -ni any dst port 7547

```

- Do you see packets arriving from the remote CPE IP? (yes/no + a short snippet)

1. **CWMP logs on the server**

- During the test, check logs:

```auto
tail -f /var/log/genieacs/genieacs-cwmp-access.log

```

(or share your cwmp log file path if you use file logs)

1. **Confirm the CWMP service is listening on 7547**

```auto
sudo ss -lntp | grep ':7547'

```

(or)

```auto
sudo netstat -plnt | grep ':7547'

```

If **tcpdump shows nothing** , the remote CPE is not reaching the ACS (wrong WAN binding / wrong URL / DNS / routing).  
If **tcpdump shows traffic but no CWMP logs** , then the issue is on the server side (listener/bind/proxy).

Post the outputs/snippets for the 5 checks and we can narrow it down quickly.
