The network part is pretty straightforwads, here is the scenario we are testing:
ACS Server:
eth0: public interface (firewall restricted, https proxy, allows informs from specific remote networks where we manage only the CPE, also NBI/Admin)
eth1: private cpe management (not routed, restricted for only ACS FS/CWMP)
CPE:
wan0: public interface (firewall restricted, outbound only, currently allows ACS for testing)
wan1: private cpe management (not routed, restricted for only ACS/FS/CWMP)
The idea with the private subnet for ACS is just to simplify security mangement the ACS communications. Elimination of public cwmp/stund listeners across a variety of acs clients is the goal, with the objective of resolving lots of potential resource exhaustion / DoS scenarios on the public listeners for cwmp/stund, particularily with odm-managed bcm/busybox stacks.
In the case where CPEs with a private ACS interface choose to use their routed public interface for the ConnectionRequestURL, they have no knowledge of the ACS server public IP, so the assumption is that they tell the ACS server their CRA URL based on their own interface configuration.
In our case, we would assume the buggy/misconfigured client advertises the ConnectionRequestURL based on enumeration of the interfaces the tr69 client listens on, and in this case, the public interface is the first one, even though they inform from their second, private network interface.
If this is the case, we might try changing the order, to work around this, while we prod upstream to correct.
Some manufactures, even based on the same stack, seem to do this properly, sticking to the private network for Informs and ConnectionRequestURL, even though they have the same basic network configuration. So we have working and non-working scenarios - which is why we originally asked what causes the Ping to show correctly in some cases not realizing the CONNECTION REQUEST were actually using the public network.
Our goals in this thread are to
-
rule out any part of the ACS Server setting up the ConnectionRequestURL, which I think we have
-
secondly to point out that the CWMP logging does not take into account the actual IP being used for communication. Normally in a syslog format, is is assumed the ip would match the message header. With GenieACS, it appears that it is coming from something else in the device model or the message body that confuses interpretation of the log.
In our case (substituing public IP for Google) the ConnectionRequestURL is http://8.8.8.8:30005/, but the genieacs-cwmp is logging 10.5.1.203, which is the private listener and inform originator for the CPE.
If support of a multi-homed ACS server or CPE in within scope of GenieACS, tweaking the logs to match the actual IP where the client message originates might be a good improvment for consideration.
If a private network for ACS communication is considered an out of scope model for GenieACS, we should probably give up on trying to take ACS communication out of the public band and find a better way to mitigate risks associated with public interface listeners for acs.