The NS#24 and NS#25 errors mean that an attempt was made to create a connection, but a detected network variable leak was caused by the use of broadcast addressing on another device. A network variable leak means that update messages for the network variable may be received by connections and devices that it is not intended to (the NV update would "leak" to another device).
Izot Net Server and LNS attempt to avoid this problem by the appropriate allocation of network variable selectors. However, some connection intersections are not possible when broadcast addressing is in use. One solution for this problem is to use aliases for unicast connections, instead of using multicast connections, or to stop using broadcast.
Please note that LonMaker Turbo and IZOT CT use automatic smart connections which can lead to subnet broadcast messages without the user realising. Please see p120-122 of the respective user's guide for a flowchart describing which connection template is used by default.
Below is a simple example to explain a NV leak. All functional blocks belong to different devices. DI-1 is connected to DO-1 and DO-2. DI-2 is only connected to DO-2. If you try to change these connections to use broadcast, it will raise an error. This is because all NVs share the same selector. If the connection was created using broadcast, DO-1 will also receive the update from DI-2 even though they are not connected. This is the leak, and this is why LNS does not allow it.