I’ve been reading posts and troubleshooting this for a bit. I have a Sprinkler Controller which needs port forwarding to be accessed outside the network. My configuration works great until I enable Wireguard on the router and then the Hairpin rule never fires. I can access the Sprinkler Controller from within my network or externally if not connected to my local network. However, I am not able to access the Port Forwarding address through my internal network when Wireguard is activated.
The screenshots do not provide enough information, because many columns are by default hidden, and because the cause for your issue is probably in the mangle table, that we can't see.
Follow this guide and post an export of your configuration Forum rules - #5 by gigabyte091.
Why do you not access the sprinkler controller, remotely, via wireguard?
There should be no need to use port forwarding.
Understood so basically you do not have a public IP address and thus cannot actually host wireguard?
What I do see is the fact that over the same interface for mullvad you have simultaneously 7 connections that are live and to the same listening port. I am not convinced this will work.
Also its not clear what type of WANIP do you have, public/private, static-fixed/dynamic so its very hard to muddle through.
The problem here is a lack of understanding of wireguard. Any user going out wireguard will ONLY and ALWAYS go out the first peer you have created. As the allowed address is checked first for traffic requests out wireguard ( assuming firewall rules allow it and routing is in place) and since the router will hit the first server peer 210.1, this will be the only path out for users.
Also I would put the mullvad address as: ( yours is not wrong, so personal pref, but the below works for all cases )
add address=10.75.166.78/24 comment=Mulvard interface=Mulvad network=
10.75.166.0
As for the port forwarding you are duplicating things....... and its not unexpected as the default rules in the forward chain are confusing.
Instead of this..........
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=accept chain=forward comment="Allow OpenSprinkler" dst-address=\
192.168.88.17 dst-port=80 protocol=tcp
USE THIS
add action=accept chain=forward comment="internet traffic" in-interface-list=LAN \
out-interface-list=WAN src-address-list=ALLOWED
add action=accept chain=forward comment="mulvad traffic" in-interface-list=LAN \
out-interface-list=Mulvad
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=drop chain=forward comment="drop all else"
Your DSN NAT rules are missing key information,............ adjusted
/ip firewall-address-list
add address=487575393mynetname.net list=MYWAN { get from IP CLOUD }
add address=192.168.88.17 list=ALLOWED
add address=192.168.88.25 list=ALLOWED
/ip firewall nat
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
192.168.88.0/24 log-prefix=Hairpin src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment="OpenSprinkler TCP" dst-address-list=MYWAN \
dst-port=62437 log-prefix=NAT protocol=tcp to-addresses=192.168.88.17 to-ports=80
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment=Mulvad out-interface=Mulvad \
Okay I see some issues, first off you want A server on the LAN not to go out mulvad.
Also you have one user that needs to reach local server vice going out mulvad??? or by .25 you need one device probably the admin PC, to go out normal wan vice mulvad??
You can achieve what you want by having internal users use the LAN IP of the server...
/routing rule
add min-prefix=0 action=lookup-only-in-table table=main { this ensures local traffic will flow }
add src-address=192.168.88.17 action=lookup-only-in-table table=main {doesnt go out mulvad}
add src-address=192.168.88.25 action=lookup-only-in-table table=main {doesnt go out muvlad}
add src-address=192.168.88.0/24 action=lookup table=Mulvard
Combine with with the following
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,9.9.9.9
/ip dns static
add address=192.168.88.17 regexp=http://sprinkler.com type=A
This way local users on the LAN can type in sprinkler.com and will be redirected to the Server. Thus allowing anyone to connect to server on the LAN.
I cannot help with the mulvad thingy. If you want to have up to seven different countries you wish to access then it will get more complicated. Its also unclear what other routes exist on the router, for example do you have default route selected on IP DHCP client ( and what is router connected to)??
The easiest approach is to disable ALL except the one you want users to go out from. You would have to manually disable and enable as required but ONLY ONE can be functioning at a time.
If you want to have 7 countries UP and Running at the same time you need 7 different interfaces and that means multiple accounts with mulvad.
Now without all the information many guesses/assumptions are being made. So help clear it up.
Your main issue is due to the routing rule at the bottom of the /routing rule table that cause everything from LAN to use the Mulvad routing table when the WG interface is active. The fix is to add the first rule in the routing rule table, like @anav wrote above. But he made a small typo 
, it's lookup-only-in-table and not lookup-only-in-router. Basically, this is the rule that will fix your issue:
/routing rule
add min-prefix=0 action=lookup-only-in-table table=main
This is to be placed at the top of the table, as @anav has written (the action can just be lookup too, and it would also work).
But of course, you should also do all the other clean-ups as he instructed.
Much thanks... fixed!