Is it possible to expose one device on a guest subnet to the main subnet?

[thickums_mcgillicudy]

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.

[psherman]

@thickums_mcgillicudy

Is there a way to easily "expose" the one home assistant machine to be reachable on the main network?

Yes... 2 ways you can do this....super easy

1. 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.

[andyboeh]

As a third option, you could also attach your HA instance to both VLANs, it's then reachable by two different IPs.

[thickums_mcgillicudy]

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'

[psherman]

@thickums_mcgillicudy

I had no idea you could do one way access

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)..

[thickums_mcgillicudy]

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.

[psherman]

@thickums_mcgillicudy

This worked perfectly. It's so nice to have something work so easily for once

Awesome! Glad this worked (although I had no doubt it would aside from the potential caveats I mentioned).

@thickums_mcgillicudy

Is there a particular name for this type of "one way" forwarding? Or is there some kind of documentation describing how this works?

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.

@thickums_mcgillicudy

made me think that this was gonna be much harder than the simple forwarding rule.

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.