vvd170501
commented
3 years ago Hi @Mike-Joseph!
You may try using the --ssdpUnicastAddr option (with an address belonging to VLAN B).
With this option enabled, the relay treats SSDP packets almost as you described, except that the source IP of a SSDP response is not modified. This may or may not be an issue, depending on your firewall configuration.
Thanks for a great and straightforward solution to this problem space!
One issue I have, however, is how the responses for SSDP/DIAL are handled. A client on VLAN A (192.168.1.0/24) might multicast an SSDP/DIAL search, with its normal unicast source IP (192.168.1.100:34534 -> 239.255.255.250:1900). The relay retransmits this search as-is and an interested IOT device on VLAN B (192.168.2.0/24) responds from its unicast IP to the original unicast source IP (192.168.2.154:59423 -> 192.168.1.100:34534). The problem is that a stateful firewall handling traffic between the VLANs has not "seen" the original request (because it is not application-aware for SSDP/DIAL) and therefore the response is disallowed unless all traffic is permitted from the IOT VLAN to the client VLAN, but that is not really desirable.
I think this problem could be resolved by changing the relay's behavior with respect to SSDP/DIAL to allow a "proxy" mode in which the relay enqueues the SSDP request and transmits a new request on the forwarding VLANs using its own IP as the source. The relay could forward unicast responses back to the original client's unicast IP. Since SSDP/DIAL responses include the Location field inside the protocol message, the source IP of the reply shouldn't matter to the client. When the client attempts to connect to the IOT device at the Location address, the firewall can see this as an authorized user->IOT connection and track it appropriately.
Thoughts?