Best way to create an isolated Wireguard network

Installing and Using OpenWrt
1

I'm trying to set up a Wireguard server that relays between clients. However I don't want those clients to have any way to access anything else on the server, especially not LuCI.
I currently have the server relaying fine but I can't stop users from accessing LuCI by entering the server address.

What would be the best way to implement this? Here's my current config if it's of any use:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd74:2a66:cd83::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        option ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.40'
        option gateway '192.168.2.1'
        list dns '192.168.2.1'

config interface 'wireguard'
        option proto 'wireguard'
        option private_key 'xxx'
        option listen_port '51820'
        list addresses '10.0.0.1/24'

config interface 'backup'
        option proto 'static'
        option device 'br-lan'
        option ipaddr '192.168.3.20'
        option netmask '255.255.255.0'

config wireguard_wireguard
        option persistent_keepalive '25'
        option route_allowed_ips '1'
        option description 'me'
        option public_key 'xxx'
        list allowed_ips '10.0.0.2/32'

...more clients defined here...

config interface 'from_wireguard'
        option proto 'static'
        option device 'wireguard'
        option ipaddr '10.0.0.100'
        option netmask '255.255.255.0'

config device
        option name 'wireguard'
        option rpfilter 'strict'



config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'
        list network 'backup'
        list network 'from_wireguard'
        option input 'ACCCEPT'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config zone
        option name 'vpn'
        option input 'REJECT'
        option output 'REJECT'
        option forward 'REJECT'
        list network 'wireguard'
        list device 'wireguard.1'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'
        option enabled '0'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'
        option enabled '0'

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'
        option enabled '0'

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'
        option enabled '0'

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'
        option enabled '0'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'
        option enabled '0'

config rule
        option name 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled '0'

config include
        option path '/etc/firewall.user'


config forwarding
        option src 'lan'
        option dest 'vpn'
2

Put the wg interface into its own zone and use the same settings as the wan zone (namely input = drop or reject). Or you can simply put the wg interface into the wan zone.

1 Like
3

You don't need to declare a network for the wireguard since wireguard will open a virtual device and set its IP directly. The name of that device will be wireguard here, so you should have list device 'wireguard' in the firewall zone.

If a network or device isn't matched in any zone, the default rules at the top of the firewall file apply, which here allow input. It is a good idea to set the defaults to reject input.

1 Like
4

Thanks for your help.

mk24, I tried what you suggested and can't get it to work. This is as far as I have got. VPN works but can still access LuCI.

The IP addresses have changed for other reasons.

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd74:2a66:cd83::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        option ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.40'
        option gateway '192.168.2.1'
        list dns '192.168.2.1'

config interface 'wireguard'
        option proto 'wireguard'
        option private_key 'xxx'
        option listen_port '51820'
        list addresses '10.0.1.250/24'

config interface 'backup'
        option proto 'static'
        option device 'br-lan'
        option ipaddr '192.168.3.20'
        option netmask '255.255.255.0'

config wireguard_wireguard
        option persistent_keepalive '25'
        option route_allowed_ips '1'
        option description 'me'
        option public_key 'xxx'
        list allowed_ips '10.0.1.249/32'

config interface 'from_wireguard'
        option proto 'static'
        option device 'wireguard'
        option netmask '255.255.255.0'
        option ipaddr '10.0.1.250'

config device
        option name 'wireguard'
        option rpfilter 'strict'


config defaults
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option input 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        list network 'lan'
        list network 'backup'
        list network 'from_wireguard'
        list network 'wireguard'
        option output 'REJECT'
        option forward 'REJECT'

config include
        option path '/etc/firewall.user'

config zone
        option name 'wireguard'
        option forward 'REJECT'
        list device 'wireguard'
        option input 'REJECT'
        option output 'REJECT'

config forwarding
        option src 'lan'
        option dest 'wireguard'

config forwarding
        option src 'wireguard'
        option dest 'lan'

One thing that does seem odd is that I need the 'from_wireguard' interface. If I disable this the VPN dies.

5

Your latest example has wireguard in the LAN zone, which is definitely going to allow access to privileged services.

If you want the wireguard peer having access to machines in the LAN network (do you want that?) but not the router itself at 192.168.2.40, you will need a specific rule to block that. Forwarding from vpn to lan means everything in lan unless blocked. To forward from vpn to the Internet via the gateway in LAN you can block all 192.168.2.0, including the gateway, and access to the Internet will still work because the final destination is not in that IP range.

Get rid of from_wireguard and the config device about wireguard. They are not needed. With just the config interface of type wireguard, run an ip addr show and you should see an interface named wireguard with an IP of 10.0.1.250/24. The peer is 10.0.1.249.

Since this machine is not the main router and you're not NATing the wireguard users, the main router needs to have a route back to the VPN tunnel installed. Otherwise attempts to access the Internet will arrive at the main router with a 10.0.1 address, and it will not know how to return them.

1 Like
6

Thanks for your help. Sorry, I misunderstood your previous instructions. As you can tell, I'm not very experienced with this. It's odd - I can pick up a new programming language pretty quickly but for some reason this stuff just makes my head hurt.

If you want the wireguard peer having access to machines in the LAN network (do you want that?)

Definitely not. I left out the other peers because I couldn't be bothered to redact their keys. Basically I want the peers to see each other but nothing else. Maybe I could set up a rule so one peer could have access to LuCI for maintenance purposes but that's it.

For some reason, when I do that Wireguard stops talking. None of the peers can connect.

I'll play around with it a bit more tomorrow. I need food and sleep.

7

Should the remote peers have the ability to access anything that is locally on the network at all? What about the internet? Or is this setup purely acting as a method for multiple remote peers to connect to each other?

The setup is generally pretty simple...

All you need for the WG network is the following:

config interface 'wireguard'
        option proto 'wireguard'
        option private_key 'xxx'
        option listen_port '51820'
        list addresses '10.0.1.250/24'

config wireguard_wireguard
        option persistent_keepalive '25'
        option route_allowed_ips '1'
        option description 'me'
        option public_key 'xxx'
        list allowed_ips '10.0.1.249/32'

... [your other peers]

remove everything else you've defined (the "from_wireguard" interface and the additional wg device definition).

Remove the wireguard (and from_wireguard) network from all firewall zones except for the wireguard zone itself.

On the firewall stuff below...

The "input" option refers to traffic destined for the device running wireguard. If you don't want the devices on that network to be able to access the router (i.e. LuCI, ssh, and any other services), reject is fine (you can always create an additional rule to allow a specific device to have input allowances for admin purposes, if you want).

"forward" controls intra-zone forwarding. This applies when there are multiple networks under one zone... WG actually presents as multiple networks (each peer is its own /32 network) -- so if you want the remote peers to talk to each other, you need this to be accept.

"output" is one part of intra-zone forwarding -- so if the WG peers should be able to connect to any other networks (i.e. to the internet or LAN or whatever), you want that as accept. Otherwise, reject is fine.

then you have the zone forwarding rules... the src defines the side that is allowed to initiate connections (the response is always allowed)... lan > wg means lan can initiate, but not the other way around. You also have a wg > lan forwarding rule, so since you have both, you've enabled either side to initiate connections. However, I think the zone rule "output" = reject may stop that from working.

1 Like
8

Not quite right, fw3 creates a rule whether to allow or not forwarding and wireguard appears as a single interface with /24 prefix as far as firewall is concerned.

[0:0] -A FORWARD -i roadwarrior -m comment --comment "!fw3" -j zone_lan_forward
...
[0:0] -A zone_lan_forward -m comment --comment "!fw3" -j zone_lan_dest_ACCEPT

output is router generated traffic, so I don't think the above statement is correct. I'd suggest to keep output to accept anyway, otherwise one would need to manually allow the necessary flows.

9

On the clients, allowed_ips must be set wide enough to allow from the other clients. On the server you can leave allowed_ips as a /32 since the only packets coming into the server will be from that client.

10

Thanks to all for your replies. @psherman, your explanation of how the rules work has helped a lot. Here's what I've ended up with:

cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd74:2a66:cd83::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        option ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.40'
        option gateway '192.168.2.1'
        list dns '192.168.2.1'

config interface 'wireguard'
        option proto 'wireguard'
        option private_key 'xxx'
        option listen_port '51820'
        list addresses '10.0.1.250/24'

config interface 'backup'
        option proto 'static'
        option device 'br-lan'
        option ipaddr '192.168.3.20'
        option netmask '255.255.255.0'

config wireguard_wireguard
        option persistent_keepalive '25'
        option route_allowed_ips '1'
        option description 'one'
        option public_key 'xxx'
        list allowed_ips '10.0.1.249/32'

config wireguard_wireguard
        option description 'two'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        option public_key 'xxx'
        list allowed_ips '10.0.1.248/32'

config wireguard_wireguard
        option description 'three'
        option persistent_keepalive '25'
        option public_key 'xxx'
        option route_allowed_ips '1'
        list allowed_ips '10.0.1.247/32'
...etc,etc...

config device
        option name 'wireguard'
        option rpfilter 'strict'

cat /etc/config/firewall

config defaults
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option input 'ACCEPT'

config include
        option path '/etc/firewall.user'

config zone
        option name 'vpn'
        list network 'wireguard'
        option input 'REJECT'
        option output 'REJECT'
        option forward 'ACCEPT'

config zone
        option name 'lan'
        option forward 'REJECT'
        option input 'ACCEPT'
        option output 'ACCEPT'
        list network 'backup'
        list network 'lan'

As far as I can tell, it's doing what I want. Clients can see each other but nothing on the server. I'll probably add a rule so one client can see the server for admin purposes.
For future reference I figured out a few things that added a lot to my confusion. The first is that if you make any changes that affect the wireguard network in any way, you have to manually restart that network. 'save and apply' in LuCI is not enough. It appears to even sometimes include changing firewall rules.

The second issue, which may be related to the first is that sometimes if you make changes to the firewall rules they take a while to take effect. For instance a few times I've accidentally made changes that should lock me out completely. After making the changes I was still able to talk to the box for a minute or so before being locked out and having to revert to the serial console to undo the changes.

1 Like
11

Based on experiments I have run in the past, and verified just now, I found that the intra-zone forward rule affects the ability for the remote-connected peers to communicate with each other.

So for this network configuration:

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '8444'
	list addresses '10.91.1.1/24'
	option private_key 'REDACTED'

config wireguard_wg0
	option description 'Peer1'
	option public_key 'REDACTED'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option preshared_key 'REDACTED'
	list allowed_ips '10.91.1.2/32'

config wireguard_wg0
	option description 'Peer2'
	option public_key 'REDACTED'
	option route_allowed_ips '1'
	option persistent_keepalive '25'
	option preshared_key 'REDACTED'
	list allowed_ips '10.91.1.3/32'

and this firewall config:

config zone
	option name 'wg'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option network 'wg0'
	option forward 'REJECT'

config forwarding
	option dest 'wan'
	option src 'wg'

Peer1 and Peer2 cannot communicate with each other.
If I change the intra-zone forward rule to 'ACCEPT', they can connect to each other (no changes were necessary on the remote peers, only the firewall on the OpenWrt WG firewall zone).

So, @trendy - This leads to a question... you said that the firewall treats this as a /24 (based on the top-level interface configuration)... so is this a matter of me incorrectly using the terminology but the peers indeed being treated functionally as separate networks, or is there something else that explains why the remote-peers need the the firewall configured such that forward=accept in order to connect to each other?

1 Like
13

I'm obviously still missing something important about rules. From what I have read, firewall zones are completely isolated from each other unless you specify otherwise. Just for testing purposes I have two zones set up, lan and lan_dhcp, each with their own interface. I want lan to be able to access just the router and lan_dhcp to be completely isolated from everything.

root@VPNBox2:~# cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fdc0:ee5a:70bf::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.2.22'
        option gateway '192.168.2.1'
        list dns '192.168.2.1'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '3 6t'

config interface 'lan_dhcp'
        option proto 'dhcp'
        option device 'br-lan'

root@VPNBox2:~# cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'REJECT'
        option forward 'REJECT'
        option synflood_protect '1'

config include
        option path '/etc/firewall.user'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'REJECT'
        option forward 'REJECT'
        list network 'lan'

config zone
        option name 'lan_dhcp'
        option forward 'REJECT'
        option input 'REJECT'
        option output 'REJECT'
        list network 'lan_dhcp'

I can access the router from both lan and lan_dhcp. What am I missing?

14

They're bridged at the network level (i.e. they both use device br-lan), so they are actually the same network and are not subject to firewall filtering.

What are you trying to achieve with the lan and lan_dhcp networks (they cannot be isolated because they are the same network, but not sure what you're trying to do at a broader scale)?

2 Likes
15

That makes sense. So to get the above example working correctly I should put them on separate VLANs?

One things still puzzles me. At one point while testing the above example I added a Wireguard connection to the mix, so I had the two lan connections plus Wireguard on it's own zone. Somehow I could still access the router via wireguard even with all three zones set to reject in, out and forward. Wireguard had to tunnel via one of those lan connections but surely if they were set to reject it should not have been able to get out. Maybe it had something to do with the fact that Wireguard was up before I changed the lan zones to reject?

I'm not really trying to achieve anything with this example other than getting an understanding of how this all works. I can't find any sort of tutorials or examples that actually show where the data flows. There are plenty of tutorials that say if you want to do X, use these settings but they don't describe the overall architecture. This side of networking seems to be filled with special cases.

While I am very grateful for your help, trying things out then failing and having to ask is a very slow and frustrating way to learn.

This all started as part of a much bigger project. I waaaay under quoted for this part of the job. I allowed 2 days but somehow I've lost a whole week messing about with OpenWRT. You could probably have the whole job sorted in an hour or two. It's reached the stage where I no longer care about the time. I refuse to let a piece of software beat me!

This system is running quite a few router boxes. Here's one example:

Wireless client as a way for the Wireguard tunnel to get out.
LTE if wireless is not available on that site.
Wireless client that is a connection to a control system's wifi. I'm only interested in one fixed IP on that control system. Other clients on that network should not be able to see into the router.
Forward that control system IP to a different IP on the Wireguard network.
Wireless master that bridges the control system's wifi. I'm only actually interested in that one IP so this could be a full bridge or just forward the IP and have a separate DHCP server. The control system has weak wifi so sometimes we need an extender.

16

define "access" -- could you access via ping? ssh? LuCI web interface?

It would be good to see the latest complete config files to be able to review and comment on this part.

What is "this' in "how all this works"? Firewall? VLANs? something else?

for this, either put them on a different VLAN relative to the system that should have administrative access, or set input=reject and then create a new rule to allow the single desired admin system access. This is assuming that the router you are referring to is the OpenWrt router that you are currently working with. If it is an upstream device, that's a different process.

1 Like
17

I stand corrected. The firewall indeed will block them because they come out of the same zone. I got confused with the route_allowed_ips, but this seems to not make any difference eventually.

1 Like
18

All of the above. When I first set this config up I created the two lan zones then added the wireguard zone. Initially everything was set to accept. Basically I was working on the principal of let everything through initially then lock down until it stops working. Baby steps to get a feel for how the system behaves. Once I had HTTP access on all three I started locking them down in LuCI, one setting at a time. For instance set lan_dhcp input to reject, save and apply and see what effect it has if any. Rinse and repeat. Eventually I ended up with all set to reject and still had http/ssh access via wireguard, which should not have worked. lan was locked out on both lan devices.

After doing some more tests I think I have found the root of my frustration. 'Save and accept' implies that your changes will now take effect. This is not the case. Some firewall settings do take effect but others don't. I replicated my above test this morning. I loaded the backup I made when I started with all set to 'acccept'. Instead of doing one at a time I set all to reject, clicked 'save and apply' and still had http + ssh access over lan and wireguard. So basically I had the same settings as before but with different results.

I'm normally pretty good at figuring out how things work but this inconsistent behaviour really messed me up. Every time I thought I had a handle on what was happening it did something different. It's pretty much impossible to figure out what is happening if the same settings have different effects at different times.

Having realized 'save and apply' was not doing what I thought it did, I connected via ssh and issued 'service network restart'. Boom, I'm now locked out as expected. The moral of the story seems to be when testing and experimenting, restart the network on every step.

19

Well, things are going better now. Here is what I have so far:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd8a:ae69:23d5::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '3 6t'

config interface 'wan2'
        option proto 'dhcp'
        option device 'eth0.1'

config interface 'LTE'
        option proto 'qmi'
        option device '/dev/cdc-wdm0'
        option apn 'giffgaff'
        option auth 'none'
        option pdptype 'ipv4v6'

config interface 'wireguard'
        option proto 'wireguard'
        option private_key 'xxx'
        option listen_port '51820'
        option peerdns '0'
        list addresses '10.0.1.2/24'

config wireguard_wireguard
        option description 'server'
        option public_key 'xxx'
        list allowed_ips '10.0.1.250/32'
        list allowed_ips '10.0.1.249/32'
        list allowed_ips '10.0.1.248/32'
        list allowed_ips '10.0.1.247/32'
        list allowed_ips '10.0.1.246/32'
        list allowed_ips '10.0.1.245/32'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        option endpoint_host 'myhost.org'
        option endpoint_port '51820'

config interface 'wwan'
        option proto 'dhcp'
        option device 'wlan0'

config interface 'wwan2'
        option proto 'dhcp'

config interface 'bridge'
        option proto 'none'
        option device 'wlan0-1'

cat /etc/config/firewall

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'wireguard'
        option output 'REJECT'
        option forward 'REJECT'
        option input 'ACCEPT'
        list network 'wireguard'

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'
        list network 'LTE'
        list network 'wwan'
        list network 'wwan2'

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 src_ip 'fc00::/6'
        option dest_ip 'fc00::/6'
        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 'Support-UDP-Traceroute'
        option src 'wan'
        option dest_port '33434:33689'
        option proto 'udp'
        option family 'ipv4'
        option target 'REJECT'
        option enabled 'false'

config include
        option path '/etc/firewall.user'

config zone
        option name 'bridge'
        list network 'bridge'
        option input 'REJECT'
        option output 'REJECT'
        option forward 'ACCEPT'

config forwarding
        option src 'bridge'
        option dest 'wan'

config redirect
        option dest 'wan'
        option target 'DNAT'
        option name 'console_redir'
        list proto 'all'
        option src 'wireguard'
        option src_dip '10.0.0.2'
        option dest_ip '192.168.101.1'

Here's a list of the interfaces and what I expect them to do:
LTE, wan, wan6 and wwan are all options to connect to the Internet. No incoming connections expected.
wan2 is my testing connection. It will be placed on the wan zone later so you will no longer be able to log in via wired LAN. All ports on the router should effectively be 'wan' ports.
wwan2 is a connection to the controller. I'm only really interested in the IP 192.168.101.1.
wireguard is my main connection to administer the router and the controller(10.0.0.2 forwarded to192.1681.10.1).
As far as I can tell this all works.
bridge is a bridge to wwan2. Ideally clients connected to this interface should only be able to connect to 192.168.101.1.
At the moment I'm not sure about how to go about this. The first issue is DHCP. 192.168.1.1 has a DHCP server. What's the correct way to allow bridge to use this DHCP?