Should the wireguard interface be included in the interface-list TRUSTED?
Cannot get much clearer than this..
Of course since your bridge is part of TRUSTED
and wireguard is part of TRUSTED
then you are good to go.
Got it. TRUSTED includes BRIDGE and WIREGUARD.
Thank you.
Any other trashing (I’m sure there’s plenty)?
Not feeling well today so maybe not…dental stuff nothing serious.
Sorry to hear it.
Feel better soon.
I’m in no rush.
Well post dental was not the only issue today its also a stomach bug of some sort, luckily at only one end. 
Too many errors or weird things to go through it yet line by line.
What is the purpose of the two guest wifi networks?
Why would you not have two vlans, one for home subnet and one for guest subnet?
Which device is providing wifi and how connected to router?
Why are both guest and home subnets considered admin on firewall address list?
There are 5 wifi networks using 4 SSIDs, as follows:
2point4 – this is for IoT devices, many of which only work on 2.4ghz; network name is 2point4 and is a slave under master wifi2
729-5ghz – this is for me (admin) access to connect only to the 5ghz network; network name is wifi1 and is a master for 5ghz
729-2ghz – this is for me (admin) access to connect only to the 2.4ghz network; network name is wifi2 and is a master for 2.4ghz
GuestWiFi – this is for regular users and should provide access only to the Internet; 2 networks have this same SSID: Guest2g (slave under wifi2) and Guest5g (slave under wifi1)
I don’t have VLANs because I am not a master of them (or skilled enough to get by managing them) and you are too far away to come and help when I screw things up.
This is all a single hapAX3 device.
I don’t understand the “guest and home subnets” question.
Hahaha okay, I will catch a ride the next time the orange drag president flys by in his sleigh…
Guests would be your guest subnets and home would be your trusted home subnet, iot a subnet for devices, etc…
Guests (connecting to GuestWiFi) are assigned 10.0.0.10-254
IoT wifi devices (connecting to 2point4) are assigned addresses on 192.168.80.100-200
Admins (connecting to the 729* SSIDs) are also assigned 192.168.80.100-200.
What this does is it protects the greater network from guest connections, but still leave it vulnerable to IoT devices gone wild or hacked.
VLANs would be much better. I’m working on it.
Besides three vlans, three pools, three dhcp-server, three dhcp server networ and 3 associated IP addresses…
Please explain this wireguard client… I assume it is another router with two subnets? WHich router is server peer for handshake???
If indeed its a router but a client peer then the allowed address should in the form /32
/interface wireguard peers
add allowed-address=10.10.90.0/24,192.168.88.0/24 comment=
“WG client on BI PC” interface=wireguard1 name=peer9 public-key=
“R5SjZucQPhyu5CQyXLvxf/RFr9FogUr5iBSC0jt9TV4=”
This is not the correct format:
add action=accept chain=input comment=“Allow WG Handshake” dst-address=
0.0.0.0 dst-port=51880 protocol=udp
Change TO:
add action=accept chain=input comment=“Allow WG Handshake” dst-port=51880 protocol=udp
For what purpose you trying to be cute??? Simply make wireguard address.
/ip address
add address=10.10.100.1/24 interface=wireguard1 network=10.10.100.0
Okay it gets more confusing, how many wireguard interfaces to you have, you have several different addresses at play???
GRE is not a secure protocol why are you accepting it in input chain… what is its purpose in the config…
These rules are highly suspect why are they needed" This is traffic to the router, NOT for port forwarding!!
add action=accept chain=input comment=“allow 67 68 to 10.0.0.1” dst-address=
10.0.0.1 dst-port=67,68 log=yes log-prefix=“allow 67 68 to 10.0.0.1”
protocol=udp
add action=drop chain=input comment=“drop all to 10.0.0.1” dst-address=
10.0.0.1 in-interface=!lo log=yes log-prefix=“drop all to 10.0.0.1”
Replace this incoherent access to the router by something better.
add action=accept chain=input comment=“Alow wireguard to router”
in-interface=wireguard1
add action=accept chain=input comment=“Allow all from LAN ifaces (bridge)”
in-interface-list=LAN
add action=accept chain=input src-address-list=admin
add action=accept chain=input src-address-list=212
add action=accept chain=input src-address-list=XXXXX
add action=accept chain=input comment=“admin access” in-interface-list=TRUSTED src-address-list=Authorized
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=udp
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=tcp
add action=drop chain=input comment=“Drop all else” { insert here but last rule ensuring address list and above rules are in place }
/firewall address list
add address=homesubnet-IP1 list=Authorized comment=“local admin PC”
add address=homesubnet-IP1 list=Authorized comment=“local admin laptop”
add address=homesubnet-IP1 list=Authorized comment=“local admin smartphone/ipad”
add address=wireguard-IP1 list=Authorized comment=“remote admin laptop”
add address=wireguard-IP1 list=Authorized comment=“remote admin smartphone/ipad”
add address=192.168.55.2 list=Authorized comment=“offbridge access”
/ip address
add address=192.168.55.1/30 interface=OffBridge5 network=192.168.55.0
Lets fix the forward chain rules … TO:
add action=fasttrack chain=forward connect-state=established,related
add action=accept chain=forward connect-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“wireguard to subnet of choice” in-interface=wireguard1 dst-address=subnet-address
add action=accept chain=forward comment=“Local subnet to wireguard” src-address=subnet-address out-interface=wireguard { but for what purpose, to where? }
add action=accept chain=forward comment" port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment=“drop all else”
WHY these two rules… running your own server on port 80? What is the IP address of the server? surely not .1
add action=dst-nat chain=dstnat disabled=yes dst-port=80 log=yes protocol=tcp
to-addresses=192.168.4.1 to-ports=80
add action=src-nat chain=srcnat disabled=yes dst-address=192.168.4.0/24 log=
yes to-addresses=192.168.4.2
/interface list
add comment=defconf name=WAN
add name=LAN
add name=TRUSTED
/ip neighbor discovery-settings
set discover-interface-list=TRUSTED
/interface list member
add comment=defconf interface=ether1 list=WAN
add interface=vlan10-home list=LAN
add interface=vlan20-iot list=LAN
add interface=vlan30-guest list=LAN
add interface=wireguard1 list=LAN
add interface=OffBridge5 list=LAN
add interface=OffBridge5 list=TRUSTED
add interface=wireguard1 list=TRUSTED
/interface bridge port
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=ether2 pvid=10
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=ether3 pvid=10
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=ether4 pvid=10
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=wifi1 pvid=10
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=wifi2 pvid=10
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=iotWLAN pvid=20
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=guest5 pvid=30
add bridge=bridge ingress-filtering=yes frame-types=admit-only-priority-and-untagged interface=guest2 pvid=30
/interface bridge port { I am not clear on bridge ports or bridge vlans when using capsman so this config assumes no capsman )
add bridge=bridge tagged=bridge untagged=ether2,ether3,ether4, wifi1,wifi2 vlan-id=10
add bridge=bridge tagged=bridge untagged=iotWLAN vlan-id=20
add bridge=bridge tagged=bridge untagged=guest5,guest2 vlan-id=30
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=TRUSTED
Fun image, thanks!
IMO “orange president” has clear meaning. How does “orange drag president” alter such?
Does this mean my needs or preferences are too complicated?
I know we all try to keep things simple, so I’d love to hear how to do what I need done in a more simple way.
Please explain this wireguard client… I assume it is another router with two subnets? WHich router is server peer for handshake???
If indeed its a router but a client peer then the allowed address should in the form /32
/interface wireguard peers
add allowed-address=10.10.90.0/24,192.168.88.0/24 comment=
“WG client on BI PC” interface=wireguard1 name=peer9 public-key=
“R5SjZucQPhyu5CQyXLvxf/RFr9FogUr5iBSC0jt9TV4=”
I honestly don’t remember why it is set up that way.
I can explain that “BI PC” mean Blueiris personal computer (i.e., the PC running the BI server).
But, I don’t think it is in use.
This is not the correct format:
add action=accept chain=input comment=“Allow WG Handshake” dst-address=
0.0.0.0 dst-port=51880 protocol=udp
Change TO:
add action=accept chain=input comment=“Allow WG Handshake” dst-port=51880 protocol=udp
So the error is the inclusion of:
dst-address=0.0.0.0
I honestly don’t know where that came from.
I checked my other devices with the same firewall rule and the “dst-address=0.0.0.0” does not exist.
I removed the “dst-address=0.0.0.0” from the rule.
For what purpose you trying to be cute??? Simply make wireguard address.
/ip address
add address=10.10.100.1/24 interface=wireguard1 network=10.10.100.0
I think you are referring to this:
/ip address
add address=10.10.100.80/24 interface=wireguard1 network=10.10.100.0
If so, then, yes, I think of myself as extra cute with a .80 address. Because, you know, it’s 79 more than .1
Actually, the reason is that the devices at other locations that all connect via wireguard all have are in the 10.10.100.x/24 network with the last octect being different from each other and being the same as the local network’s 3rd octect (192.168.80.x at this location).
Okay it gets more confusing, how many wireguard interfaces to you have, you have several different addresses at play???
Just 1 wireguard interface on this device.
GRE is not a secure protocol why are you accepting it in input chain… what is its purpose in the config…
Should I just remove firewall rule allowing GRE?
These rules are highly suspect why are they needed" This is traffic to the router, NOT for port forwarding!!
add action=accept chain=input comment=“allow 67 68 to 10.0.0.1” dst-address=
10.0.0.1 dst-port=67,68 log=yes log-prefix=“allow 67 68 to 10.0.0.1”
protocol=udp
add action=drop chain=input comment=“drop all to 10.0.0.1” dst-address=
10.0.0.1 in-interface=!lo log=yes log-prefix=“drop all to 10.0.0.1”
I do understand input vs. forwarding rules.
These rules allow the guestwifi-connected users to access only DNS and DHCP from 10.0.0.1 (the ax3). The idea is that guestwifi-connected users have no access to the router other than that DNS and DHCP.
Replace this incoherent access to the router by something better.
add action=accept chain=input comment=“Alow wireguard to router”
in-interface=wireguard1
add action=accept chain=input comment=“Allow all from LAN ifaces (bridge)”
in-interface-list=LAN
add action=accept chain=input src-address-list=admin
add action=accept chain=input src-address-list=212
add action=accept chain=input src-address-list=XXXXXadd action=accept chain=input comment=“admin access” in-interface-list=TRUSTED src-address-list=Authorized
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=udp
add action=accept chain=input comment=“users to services” in-interface-list=LAN dst-port=53 protocol=tcp
add action=drop chain=input comment=“Drop all else” { insert here but last rule ensuring address list and above rules are in place }
I don’t understand. I already allow wireguard-connected users access to the router.
/firewall address list
add address=homesubnet-IP1 list=Authorized comment=“local admin PC”
add address=homesubnet-IP1 list=Authorized comment=“local admin laptop”
add address=homesubnet-IP1 list=Authorized comment=“local admin smartphone/ipad”
add address=wireguard-IP1 list=Authorized comment=“remote admin laptop”
add address=wireguard-IP1 list=Authorized comment=“remote admin smartphone/ipad”
add address=192.168.55.2 list=Authorized comment=“offbridge access”/ip address
add address=192.168.55.1/30 interface=OffBridge5 network=192.168.55.0
Too much change for me.
WHY these two rules… running your own server on port 80? What is the IP address of the server? surely not .1
add action=dst-nat chain=dstnat disabled=yes dst-port=80 log=yes protocol=tcp
to-addresses=192.168.4.1 to-ports=80
add action=src-nat chain=srcnat disabled=yes dst-address=192.168.4.0/24 log=
yes to-addresses=192.168.4.2
I don’t believe I am running a server on port 80 (http).
I also don’t see any 192.168.4.x network in my system.
EDIT: I see the NAT rules now. I don’t remember why there were created. Luckily, they are disabled.
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=TRUSTED
Done.
I will need to study a heck of a lot to understand the VLAN entries.
I have a specific question about my firewall rules.
You write that the last input and forward rules should be drop all.
I have these as the last of the input and forward rules:
/ip firewall filter
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
I’m specifically asking whether is it okay to have the last input rule as droping all for frames arriving at in-interface-list=!LAN, instead of just drop all.
The last forward rule drops all frames arriving on in-interface-list=WAN that are also connection-nat-state=!dstnat, instead of drop all.
I don’t know why I have each of these 2 rules with these additional conditions.
It costs nothing for you to test.
Just add the drop all rule after the last one you have.
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="drop all test"
Two possibilities:
- this last rule will never be hit (counters will remain 0)
- this last rule is actually hit by something
Test that your internet and everything else works as before.
Then, take your time reading this (thanks Wayback Machine):
https://web.archive.org/web/20230524131930/https://forum.mikrotik.com/viewtopic.php?t=180838
I added a drop all at the end of the input rules.
I added a drop all at the end of the forward rules.
I then discovered that the drop all forward rule was catching lots of frames originating on the LAN and destined for the WAN.
Then I realized that I did not have an allow forward rule for all from LAN to WAN traffice. I added the rule.
So far I’ve found this on 3 devices.
Thank you.
Is not present because it is not needed, you must not add random rules without know what you doing…
Are you saying I should not add an allow forward rule for LAN to WAN?
If my last forward rule drops all, and there is no allow rule for LAN to WAN before that, then all LAN to WAN forwarding will be dropped, right?
Default firewall rules are still here.
http://forum.mikrotik.com/t/buying-rb1100ahx4-dude-edition-questions-about-firewall/148996/4
drop-all-at-the-end should only be put in the input chain.
It is obvious that the router must allow everything between the entire LAN and the external WAN, otherwise why did you put a router and connect to the internet?
The last rule of the forward chain is used to drop everything that comes from the WAN, but that has not been requested (NATted) by the internal LAN.
Following too many suggestions only leads to confusion.
The things @jaclaz wrote were just a test to make you understand, they were not rules to leave, and then add the rule to allow PCs in LAN to use the internet.