Maybe this is the wrong place to ask but I couldn't find a simple solution for my problem that I think a lot of people here might be familiar with. So I have 2 interfaces on the main router, one for generic usage, and one that's iot. I also have 2 vlans since I have 3 routers but single physical lines to connect to.
The main network is on 192.168.1.x, the iot network is on 192.168.2.x
I have a home assistant machine on 192.168.2.10
I realized to make any changes on any computer/ phone I have, I have to switch to the iot network, then switch back. Is there a way to easily "expose" the one home assistant machine to be reachable on the main network?
So far I've come across VPNs, some cloud offering from home assistant, OSPF or BGP.
Allow the main network to initiate connections the IoT network, but (usually) not the other way around. This would allow any host on the trusted network to connect to any host/device on the IoT network (and those devices can respond accordingly), but you can still prevent those IoT devices from connecting to your main network.
or
2) Allow access from the trusted lan to the single Home Assistant host (and not the rest of the network)... similar to above, this can be a one-way rule, or you can make it so that the HA server can also initiate connections to the main trusted network if that is a desired situation.
How would you like to make it work?
Post your /etc/config/firewall file and we can help you craft a rule that does what you want.
I had no idea you could do one way access, that seems ideal. I'd go with option 1 that way I could connect and fiddle with any conceivable iot device from any trusted computer on the real network.
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan'
config zone
option name 'wan'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
list network 'wan'
list network 'wan6'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config zone
option name 'iot'
option output 'ACCEPT'
option forward 'REJECT'
list network 'iot'
option input 'REJECT'
config forwarding
option src 'iot'
option dest 'wan'
config rule
option src 'iot'
option dest_port '53'
option target 'ACCEPT'
option name 'iot dns'
config rule
list proto 'udp'
option src 'iot'
option dest_port '67'
option target 'ACCEPT'
option name 'iot dns'
Yup... to make sure it is clear, the "one way" is about initiating connections. Obviously the other side needs to be able to respond for a useful connection. But yes, the following forwarding rule will allow you to connect to the IoT network from the LAN network.
config forwarding
option src 'lan'
option dest 'iot'
Note:
some devices only work with mdns or other auto-discovery type techniques that aren't designed to cross subnets -- you can sometimes get these to work using an mdns repeater/reflectors.
there are also some devices that either won't or don't know how to respond to a request from another subnet. the Windows Firewall by default will not allow connections initiated from another subnet, so if things don't work, check the local firewall/configuration settings of the hosts/devices. In some cases, it may not be possible at all (i.e. some really cheap IP cameras, for example)..
This worked perfectly. It's so nice to have something work so easily for once. Is there a particular name for this type of "one way" forwarding? Or is there some kind of documentation describing how this works?
As you said, the fact that the other device still needs to not only listen to but respond back to requests from the trusted subnet made me think that this was gonna be much harder than the simple forwarding rule.
Awesome! Glad this worked (although I had no doubt it would aside from the potential caveats I mentioned).
I don't know if it has any kind of special name... if you read up on the firewall, this is just one of the standard features. This is one of the main reasons why the devices can reach the internet, but the internet cannot reach your devices... The default condition allows forwarding from the lan zone > wan zone. But the reverse is not allowed.
Yeah.... some firewalls require additional rules. For example, doing this on EdgeOS (another routing OS) is still simple, but requires a rule that allows the forwarding from one network to another and then an accompaying rule for "established and related" connections to return. But yeah, on the OpenWrt "zone based firewall" it's really that simple.
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.