|
No, it doesn't. Devices are not "attached" to routers in any meaningful way - it is an entirely "stateless" (a term that has specific meaning in data networking) paradigm. Routers don't need to "know" about devices up/downstream of them, it's all about the addresses on the packets...
A router processes network traffic packet by packet, it will simply examine any incoming (or outgoing) packet, determine which port it need to egress through to get to it's destination, then examine things like any Access Control Lists (ACL) and things like firewall rules to determine whether the packet is allowed to proceed.
It's a bit like to posties working in a sorting office, they don't need to have any knowledge of the goegraphy of the world, they just need to read the addresses on the mail and chuck it in the correct bin to move it towards it's destination.
There are (of course) a few caveats and exceptions: For example uPNP includes a mechanism that allowed clients on the LAN side of you firewall to dynamically request ports to be open, but this wouldn't work "the other way around" - clients on the "outside" of the firewall cannot get ports opened.
Also, it's possibly a device connects inbound on one port, then the target device established a "new" connection "in the other direction" using different ports - which succeeds because SOHO routers have a particularly lapse default state of "allow everything outbound."
If I were testing such things, I'd want to attach an ethernet switch upstream of you router's WAN port, connect a laptop and use that to perform testing. Often you can telnet to the target on the requisite port and see what the response it, though whether that works depends somewhat on the port and protocol.
I would then disable all the rules and introduce them one by one testing each one as we go until we get the functionality required.
Better kit might also allow the ability to "log" rule usage so that you can examine the system logs to determine whether a rule being triggered or not. |
|