I've got 2 VLANs on my router - one that uses pihole and one that doesn't. Each VLAN is associated with a physical ethernet port on the router, e.g. VLAN1 (no pihole) maps to eth port 1, VLAN2 (with pihole) maps to eth2.
I have some devices that are physically connected to the router's eth1 port due to how my house is cabled, but I want them to be in VLAN2 so they'll use pihole. Is this possible? It seems like it won't be (e.g. if I just create a static DHCP reservation) because those devices will still be in the VLAN1 network, just with a network address in a different subnet. But maybe someone knows a workaround so I can get this working?
The device I want to move is a TV, so wireless isn't an option due to bandwidth.
Also for security. I've got some untrusted devices so VLAN2 with pihole is intended to be segregated away from the other trusted devices in VLAN1. I'd like to keep both subnets separate.
Having said that, I don't mind packets going from VLAN1 -> VLAN2, but not the reverse (to prevent untrusted devices performing network reconnaisance).
Actually, I can configure a custom DNS server for the TV so it'd be sufficient to set up an iptables rule to forward packets on port 53 from VLAN1 -> VLAN2 to access pihole...
In future I may route traffic for VLAN2 (pihole) over a VPN. So although I could create an iptables rule for this initial task, it would be useful to know the answer to my original question, about whether there's a way to somehow migrate a device physically connected to one OpenWRT interface to another one.
Short answer, no, for any OS, the general rule of one IPv41 subnet and broadcast domain per (virtual) interface holds. Violating that is possible, but generally unwise.
[Edit: It's really the opposite that is important -- each subnet should only be on one interface. There are use cases for multiple addresses in non-overlapping subnets on a single interface.]
I'm assuming that you're using "VLAN" to mean "subnet", especially as a device like a consumer TV is unlikely to be VLAN-aware. VLANs allow multiple packets streams to be sent on a single Ethernet cable. However, the devices at each end need to understand and respect VLAN tagging (802.1q). These are generally managed switches or "trusted" computers/servers that can be configured manually with VLAN tagging.
When a "normal" consumer device is plugged into a cable that carries VLAN-tagged packet streams, it will send out an untagged DHCP request. It will either be rejected at the switch or interface, or assigned to the PVID for that port for a VLAN, then routed by the switch fabric or interface. In general that means that DHCP can't "assign" a VLAN for a device.
1 IPv6 is a bit different here, but the concept that a given link-local subnet is always and only accessed through one interface still holds.
I'm using VLAN to refer to the VLANs I created under the "Network->Switch" tab of the OpenWRT web UI (which do correspond to subnets via OpenWRT's interfaces). To create each subnet I assigned a different port on my router to each VLAN and then created interfaces for each one (not sure if that's the best way but it works).
There are VLANs and then there are VLANs -- The ones configured by the LuCI page "wire up" the CPU, switch, and physical ports. If they are "untagged" for the cable port (which I am guessing they are), the VLAN tag is stripped off and they become "plain" Ethernet packets on the cable.
An inexpensive "managed" switch would be a "clean" way to split the TV off1. You could run both "trusted" and "untrusted" tagged VLANs over a single cable from your router to the switch. Then plug in whatever you need to the remote switch, after configuring its remaining ports for the selected VLAN, untagged.
1 Even a spare old router running OpenWrt with at least three physical ports could work as a managed switch.
-- The ones configured by the LuCI page "wire up" the CPU, switch, and physical ports. If they are "untagged" for the cable port (which I am guessing they are), the VLAN tag is stripped off and they become "plain" Ethernet packets on the cable.