Dummy Client for Port Forwarding

Hi everyone,
my current setup is: I got 3 VLANs on the internal side and one Uplink. I got 3 ip ranges in different subnets, one is my home network, one is network elements I dont really trust (TV, Playstation) and one is for things I really really distrust (IoT).
Now I have an app (Magic Home) that wants to talk to IoT from the internal LAN. The problem is the way it does it. It has some homemade discovery implemented that just sends a TCP ping to every device and a special port in its own network to discover "smart" devices. Since it is in the internal zone (10.0.0.0/24) and the IoT net is not (192.0.0.0/24) it does not discover the device. Direct communication is possible (but not though the app) though, but only on that port everything else is blocked by iptables.
My initial thought was this: If I can create an IP without a real device (say 10.0.0.240) and use iptables in LuCl (or from command line) to portforward everything from the very port on this ip to the "smart" device on the other segment everything should work.
Is that a good idea? And: is it possible to create a "dummy device" in the router or reroute packets without an actual exisiting client?
I hope that was understandable.
Thanks!

See: https://wiki.openwrt.org/doc/uci/firewall#dnatsnat_redirects_and_forwarding_combination

Thank you for your help. I tried something (I thought of would work) but it did not work.
So I want every member of the zone "lan" to be able to talk to a specific device in "Network" on a special port. It is a classical DNAT from what I understand. IP 10.0.0.51 is unused.
This is what i put into /etc/config/firewall:

    config redirect
        option target 'DNAT'
        option src 'lan'
        option dest 'Network'
        option proto 'tcp'
        option src_dip '10.0.0.51'
        option src_dport '5577'
        option dest_ip '10.0.1.133'
        option dest_port '5577'
        option name 'ESP_Light1'

If I try to telnet directly to that port from my machine (10.0.0.101 to 10.0.1.133) it works, if I try to telnet to the "Dummy IP" 10.0.0.51 (unused, just for redirects) it does not work.
What did I miss?

At times...I've done something unique...

  • I have an Internet-facing server on untrusted VLAN x that I need people to reach on its WAN IP.
  • This is not allowed under general rules (use the internal IP)
  • I use a redirect, that says if I see a LAN IP accessing the port on the WAN IP, CHANGE THE DESTINATION TO its Private IP and place the packet on the originating LAN
  • this causes the packet to route as normal

So you...

  • FIRST, NEED TO CREATE AN INTERFACE ON THE ROUTER (on the same VLAN) THAT WILL RESPOND AS THIS...

See: http://www.tldp.org/LDP/nag/node72.html

While not really answering the direct question asked about a dummy device or port forwarding methods, two other ideas of how to tackle the general issue:

  1. Put the 'bridge'/'controller'/(or whatever it is) device onto the same network as the devices it is trying to control, and adjust your firewall rules to allow inter-VLAN routing for that singular device.

or

  1. Adjust your firewall rules to allow 1-way(-ish) communication across the VLANs, much like how WAN is handled. In essence, any new connections attempted by the untrusted LAN to the trusted on just get dropped (default behavior drop). But hosts on the trusted LAN (including this 'bridge'/'controller'/whatever device) can freely talk to the stuff on the untrusted LAN, and the hosts/devices on the untrusted side can respond to requests coming from the trusted LAN (i.e. allow established and/or related). This is, as mentioned, the nominal operating mode for a basic firewall for a normal WAN+LAN environment.

One you accomplish the dummy interface, you must ALLOW FORWARDING in the Firewall Zone the dummy interface is in and masquerade for (ONLY) that IP when it's destined - to the Magic Home network.

I tried changing the whole network to a class B network so all devices would be in the same network. That went well except it didnt because apparently the discovery algorithm is: Try to connect to every device in your class C network. Even if you're in a class B. How could one even think of this as a proper host discovery and identification algorithm?

Creating a second network interface in LuCl and putting it into the same network as the first one resultet in total loss of internet. So I guess I'm still working on it :wink:

Huh...?

At first you said:

You didn't have a "whole network" in your OP (if you did, you wouldn't have the problem)...so, did you assign this IP range to all local VLANs...or did you reconfigure the router?

You were to make a dummy interface, and place it into the same FIREWALL ZONE as the other Interfaces in LAN...let's be clear, a DUMMY INTERFACE is a special interface in Linux. I want to be certain you didn't add another adapter, VLAN or something.

In this case...you used the word NETWORK twice (I surmise 'physical network' and 'numbered [logical] network,' respectively)...and if I read it right...Yes, this could cause such a "loss of Internet"...why?

...basically (except for Anycast), no two REAL networks can possess the same IP address ranges.

Your most recent post seems as if you gave the same IP to the three internal VLANs. In most general circumstances, that would be an invalid configuration.