Little late to the party, but it doesn't look like you ever got a full answer.
So for Wireguard, you need to create seperate peers for each device, then you'll be able to use both at the same time.
As for your core issue, you have tons and tons of stuff on your network exposed straight to the internet for anyone to poke at, including (seemingly) a home automation system and InfluxDB.
If I were you, I'd wipe it all and start over. If you don't, sooner or later you're gonna get hacked. I'll give you a framework to start with below. It looks very overwhelming, but just stick to it, and it should start to make sense as you go.
Notes:
- You don't need to understand all of these notes, they'll become more clear as you move through the steps
- All values will be marked like
this
- Some textboxes won't accept the
/24
notation used below. You must empty the box then click the green +
beside it. After doing this it will work. Leave the additional newly created field blank.
- OpenWRT's firewall is stateful. Zone forwardings only apply in one direction, so allowing one zone to initate a connection to another zone will cause the firewall to track the state of the connection and allow related return traffic back through.
- As such, you SHOULD NOT allow zone forwardings both to and from a zone unless you really do need both sides to be able to initate connections at any time. Traffic rules can and should be used to more precisely allow certain traffic through to an otherwise unreachable zone when needed.
- You can make changes to the zone forwardings below if you want to adjust which traffic is allowed. The forwardings in step 8 are good safe examples, but if for some reason you decide you want to allow the
lan
zone to reach the guest
zone, you can add the guest
zone to the lan
zone's forwardings and nothing bad will happen.
- You should not edit the
wan
zone
- If you're doing something that you think needs the
wan
zone to be changed, you're actually looking for a port forward (for allowing traffic from the internet to services) or traffic rule (for allowing traffic from the internet to OpenWRT) instead.
- Zone forwardings on the
wan
zone behave differently from the other's due to masquerading. You don't need to understand this yet, just trust me when I say you should leave it be unless you know exactly what you're doing.
- If you can't reach forwarded ports from inside your network, you need to configure
Reflection zones
in the Advanced Settings
for your port forward. Add the zones that you want to allow to reach the forwarded port here. You don't need to add the Destination zone
(e.g. wan
) to Reflection zones
, as it's already implied and will work by default
Instructions:
- Copy these instructions to a text file on your machine. Take a config backup of your router, then reset it to factory defaults
- Set a static IP on your workstation in
192.168.1.0/24
, and add a secondary IP address in 192.168.2.0/24.
- The steps for this vary based on your OS. Let me know which one you use, and I'll do my best to help.
- If
192.168.1.2
and 192.168.2.2
are unused, you can use those. Any address from 2 to 254 will work as long as it's not used by something else.
- Adjust the IPv4 address on your
lan
interface to 192.168.2.1/24
:
- We have to do this because
192.168.1.0/24
is extremely commonly used, and when using a VPN, it may collide with the network you're connecting from.
- If it won't let you enter
/24
, empty the box and click the green +
first
- After you do this, navigate to the new IP address in your web browser to pick up where you left off. If you did step 1 correctly, this should just work. If you didn't you'll need to wait 90 seconds for it to revert back to the old IP before you can try again.
- Install the needed components for Wireguard:
- Use the package manager UI or
opkg update && opkg install luci-app-wireguard
then restart your device.
- Create 4 new firewall zones, but leave the settings empty (we'll finish them later):
- Name them
vpn
, guest
, services
, and iot
- Save and apply when finished
- Create a new interface named
vpn
:
- Protocol:
Wireguard VPN
- General Settings:
- Click
Generate new key pair
- Listen Port:
51820
- IP Addresses:
192.168.3.1/32
- Firewall Settings:
- Create a new interface named
guest
:
- Protocol:
Static Address
- Device:
Unspecified
- General Settings:
- IPv4 Address:
192.168.4.1/24
- Firewall Settings:
- Create a new interface named
services
:
- Protocol:
Static Address
- Device:
Unspecified
- General Settings:
- IPv4 Address:
192.168.5.1/24
- Firewall Settings:
- Create a new interface named
iot
:
- Protocol:
Static Address
- Device:
Unspecified
- General Settings:
- IPv4 Address:
192.168.6.1/24
- Firewall Settings:
- Configure the following firewall rules:
- This one allows inbound Wireguard traffic to be accepted and handled by your router.
- Name:
Allow-Wireguard
- Protocol:
UDP
- Source zone:
Any zone
- Destination zone:
Device
- Destination port:
51820
- Action:
accept
- These ones ensure that all devices in each network are able to request IP addresses. They're all the same, with only the source zone modified.
- Name:
Allow-Guest-DHCP
- Protocol:
UDP
- Source zone:
guest
- Output zone:
Device
- Destination port:
67
- Action:
accept
- Name:
Allow-IoT-DHCP
- Protocol:
UDP
- Source zone:
iot
- Output zone:
Device
- Destination port:
67
- Action:
accept
- Name:
Allow-Services-DHCP
- Protocol:
UDP
- Source zone:
services
- Output zone:
Device
- Destination port:
67
- Action:
accept
- These ones ensure that all devices can reach the built-in DNS server. Your devices should be configured to use this, as it enables a lot of fancy features. Once again, only the source zone changes for each rule.
- Name:
Allow-Guest-DNS
- Protocol:
TCP, UDP
- Source zone:
guest
- Output zone:
Device
- Destination port:
53
- Action:
accept
- Name:
Allow-IoT-DNS
- Protocol:
TCP, UDP
- Source zone:
iot
- Output zone:
Device
- Destination port:
53
- Action:
accept
- Name:
Allow-Services-DNS
- Protocol:
TCP, UDP
- Source zone:
services
- Output zone:
Device
- Destination port:
53
- Action:
accept
- Configure each zone as follows so we can control how they talk to each other:
- Zone Name:
lan
- Input:
accept
- Output:
accept
- Forward:
accept
- Allow forward to destination zones:
wan
, vpn
, iot
, services
- Zone Name:
wan
- Do not make any changes. The defaults are fine.
- Zone Name:
vpn
- Input:
accept
- Output:
accept
- Forward:
accept
- Allow forward to destination zones:
lan
, wan
, iot
, services
- Zone Name:
guest
- Input:
reject
- Output:
accept
- Forward:
reject
- Allow forward to destination zones:
wan
- Zone Name:
iot
- Input:
reject
- Output:
accept
- Forward:
reject
- Allow forward to destination zones:
wan
- Zone Name:
services
- Input:
reject
- Output:
accept
- Forward:
reject
- Allow forward to destination zones:
wan
- Take a configuration backup and put it somewhere safe so you don't have to do this again.
- Remove the static 192.168.1.0/24 address, and switch to DHCP or just use the 192.168.2.0/24 address set above
You should now be at the point where you can configure any Wi-Fi networks, VLANs, and/or Wireguard peers you need. For Wi-Fi networks, simply select the network you want to attach it to when creating the SSID. If you need help with VLANs or wireguard peers, let me know, as we'll need more info.
I'll dissent from the crowd here and say exposing SSH is safe as long as you disable password authentication, use a strong key (ssh-ed25519
), and (optionally) use a non-default port. SSH is a very well tested piece of software, and it's unlikely that you will have any security issues as long as you follow basic best practices. I would go so far as to recommend doing this, as it's extremely handy if your VPN breaks for some reason and you have no other way in. You can use SSH local forwarding to connect to the OpenWRT Web UI over an SSH connection and fix any issues. You can also proxy traffic to other SSH servers on your network. I can elaborate more on this if you want me to
You can do the same with Wireguard, as it's also extremely well-designed and safe.
Final recommendation, with the exception of Wireguard and SSH, don't port forward anything that shouldn't be publicly-accessible. Every forwarded port means potential security issues. Everything should be accessible from the Wireguard tunnel. If for some reason you do need to port forward something, create another network/interface/zone called dmz
with very limited rules (forward only to wan etc), and stick everything that must be exposed in there before forwarding it. That way if a service does get compromised, it will only be able to do limited damage.
I know this is a lot to read, but it will get you up and running. Let me know if you need help, or if anything isn't clear or doesn't work right.