Just trying to understand firewall rules and what they do.
My firewall was set up like this:
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade log=no
Wireguard clients could access LAN but couldn’t make it through WAN.
When I added this rule, they suddenly could:
add chain=srcnat out-interface=ether1 action=masquerade src-address=[wireguard subnet]
Shouldn’t the first rule catch all subnets including wireguard since no source was specified?
You do not provide enough context.
If you have wireguard traffic leaving the router it has nothing to with going out your WAN on ether1.
In fact, in general, one has no need to specify the WAN interface because we use interface lists
/interface list
add name=LAN
add name=WAN
/interface list memberes
add interface=ether1 list=WAN ( or for pppoe commonly add interface=pppoe-out1 list=WAN.
add interface=bridge list=LAN
Thus, the source nat rule covers this
add chain=srcnat action=masquerade out-interface-list=WAN
+++++++++++++++++++++++++++++++++++++++++
The reason for this rule is so that traffic from all the users on subnets, are given the WANIP of the router out the door to the WWW.
External WWW addresses will respond back to the IP adddress of the router. The router will unsourenat that traffic back to the local IP of the subnet user.
The same COULD be required for users going out the wireguard tunnel. A clue is if your allowed IPs is set to 0.0.0.0/0 and that means.
a. your mikrotik device is a client peer for handshake
b. your mikrotik is being used to go out the internet of the other end of the tunnel, not the internet provided by your local WAN
The question next to be answered is, what is at the other end of the wireguard tunnel aka the Server Peer for handshake device.
a. if its another router, then then there are two options
i. the other end has your local subnets as allowed IPs, and thus masquerade through the tunnel is not required.
ii. the other end does not have your local subnets as allowed IPs, and thus you have to masquerade through the tunnel.
b. if its to a third party VPN provider such as Proton, then it only gives you a single wireguard address and in like a ii. above, it does not know about your local subnets and
thus masquerade through the tunnel is required.
The key point is that the sourcenat rule has NOTHING TO DO with ether1 and would look like.
add chain=srcnat action=masquerade out-interface=wireguard1
|++++++++++++++++++++++++++++++++++++++++++++
Hence, what I often recommend in the scenario of a ii. and b. is to simply use this trick.
/interface list members
add interface=ether1 list=WAN
add interface=bridge list=LAN
add interface=wireguard1 list=WAN
Then you still only need one sourcenat rule.
add chain=srcnat action=masquerade out-interface-list=WAN
In conclusion. Wireguard bound traffic does not go out ether1, it goes out wireguard1 interface.
With that in mind, in the forward chain, one must ensure a rule allowing those supposed to go out the tunnel to have permission to do so…
Remember firewalls do not push traffic anywhere that is the job of routing to select the path.
Second rule is same as first rule, with one extra condition => there’s no reason why it should catch more traffic than first one. It’s the opposite.
@llamajaja: You can have WG clients connecting to router as WG server and then use it to access internet, then their traffic will go out to WAN.
Good day,
As usual, I disagree, otherwise, the world would have frozen over,
The discussion above I provided, expressed the viewpoint that we were talking about local LAN users entering the wireguard tunnel and heading outbound to a distant site for internet.
In this case your comment does not apply..
If you are intimating the other case, where one has incoming remote lan users COMING out of the tunnel and wanting to go out the local WAN for internet, then
you have one leg to stand on, but let me take it away so you falleth on thou face…
In this case, typically the local Router is Server Peer for handshake, but not necessarily. One has two options.
a. If the MT device is a server peer for handshake it is common to set the wireguard interface as a member of the LAN interface list.
The forward chain rule
add chain=forward action=accept in-interface-list=LAN out-interface-list=WAN provides the necessary permission for those users to access the WAN.
To be blunt, there is no requirement for an additional sourcenat rule as the traffic will use the existing single rule same as local users…
b. If MT device is a client peer and one has remote exiting the tunnel on the local router, it is more likely the following forward chain rule is needed in addition to existing rules
add chain=forward action=accept in-interface=wireguard1 out-interface-list=WAN
Personally, I prefer being precise on arriving traffic and would recommend adding to the rule if known…
add chain=forward action=accept in-interface=wireguard1 out-interface-list=WAN { one of → src-address=remotesubnet src-address-list=userlist src-address… }
As in a.
There is no requirement for an additional sourcenat rule as the traffic will use the existing single rule same as local users…
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Therefore, the comment,
"@llamajaja: You can have WG clients connecting to router as WG server and then use it to access internet, then their traffic will go out to WAN.
Is not helpful. First the MT as a peer client for handshake can still provide internet for the other end, no absolute requirement for the MT to be server peer for handshake. Remember, it is a peer to peer connection 
Secondly, nothing changes for sourcnat default rule, only the forward chain firewall rules require consideration.
Nobody said anything about forward chain, and if the traffic reached any srcnat rule, it obviously wasn’t stopped in forward, so there shouldn’t be any problem there. 
Thats not necessarily a good sign, sometimes ones forward chain is non-existant or needs work… we both know that sometimes things work on the forgiving platform until…