Okay so remote router is not MT its something else.
You wish for your external users to use your DYNDNS URL/IP address of the mikrotik router to reach the server at 192.168.10.200
In other words, enter the MT router then be port forwarded through the tunnel to the other router…
I will look at the config… keep important lines and modify others.
/interface bridge add admin-mac=B8:69:F4:03:26:AE arp=proxy-arp auto-mac=no comment=defconf name=bridge port-cost-mode=short
/interface wireguard add comment=“WireGuard server” listen-port=13231 mtu=1420 name=wg1 private-key=“xxx”
/interface list add comment=defconf name=WAN
/interface list add comment=defconf name=LAN
/ip pool add name=dhcp ranges=192.168.88.100-192.168.88.254
/ip dhcp-server add address-pool=dhcp interface=bridge lease-time=1h name=defconf
/routing table add disabled=no fib name=wg-vpn
/interface list member add comment=defconf interface=bridge list=LAN
/interface list member add comment=defconf interface=ether1 list=WAN
/interface list member add interface=pppoe-out1 list=WAN
/interface wireguard peers add allowed-address=192.168.80**.7**/32,192.168.10.0/24,192.168.1.0/24 comment=“Sokol Router” interface=wg1 public-key=“<…>”
OKAY
so we can infer that your local subnet 192.168.88.1 needs access to 192.168.10.0/24 and 192.168.1.0/24 subnets at the other router!
OR
we can infer that remote subnets 192.168.10.0/24 and 192.168.1.0/24 require access to the MT LAN or WAN.
WRONG
The IP address for the remote router is wrong should be
/interface wireguard peers add allowed-address=192.168.80**.8**/32,192.168.10.0/24,192.168.1.0/24 comment=“Sokol Router” interface=wg1 public-
WHY
you dont seem to have any other peers, would have thought at least one for the admin to remotely connect to be able to config the router when away.
/ip address add address=192.168.88.1/24 comment=defconf interface=ether2 network=192.168.88.0
/ip address add address=10.0.88.0/24 disabled=yes interface=bridge network=10.0.88.0
This makes no sense to me ETHER2 is on the bridge so why does it have some strange address DELETE/REMOVE IT.
Not only that but the SYNTAX is wrong anyway should be 10.0.88.1
The address for the bridge should have the BRIDGE as interface.
/ip address add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
FIREWALL RULES ORDER AND ORGANIZATION MODIFIED
Q1: how does 10.0.88.0/24 subnet even come into this config?
Q2. how does 10.0.90.0/24 subnet even come into this config?
{ Forward Chain }
(default rules to keep)
/ip firewall filter add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
/ip firewall filter add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
/ip firewall filter add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
/ip firewall filter add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
(admin rules)
/ip firewall filter add action=accept chain=input comment=“Allow establish Remote Access” in-interface-list=WAN log=yes log-prefix=remote_sys port=500,4500 protocol=udp
/ip firewall filter add action=accept chain=input comment=“Allow establish Remote Access” in-interface-list=WAN log=yes log-prefix=remote_sys protocol=ipsec-esp
/ip firewall filter add action=accept chain=input comment=WireGuard handshake" dst-port=13231 protocol=udp
/ip firewall filter add action=accept chain=input comment=“Allow access to WinBox via WireGuard” dst-port=8291 in-interface=wg1 protocol=tcp
/ip firewall filter add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN log-prefix=bad
{ Forward Chain }
(default rules to keep fastrack rule is BEFORE established,related)
/ip firewall filter add action=accept chain=forward comment=“defconf: accept in ipsec policy” disabled=yes ipsec-policy=in,ipsec
/ip firewall filter add action=accept chain=forward comment=“defconf: accept out ipsec policy” ipsec-policy=out,ipsec log-prefix=vpn
/ip firewall filter add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related hw-offload=yes
/ip firewall filter add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
/ip firewall filter add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid log-prefix=drop
(admin rules)
/ip firewall filter add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
/ip firewall filter add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat
/ip firewall filter add action=drop chain=forward comment=“Drop all else”
There are too many things going on to comment further on firewall rules or mangles.
If the complete config is not presented, then its not possible to see the forest from the trees…
-Two subnets make no sense without the rest of the config.
-Your destination nat rules are not complete or consistent in format
-You suddenly have a second wireguard interface without reason…
- Mangles cannot be digested without more information… why which speaks to requirements, etc etc…
++++++++++++++++++++++++++++++++++++++
In any case, I will remove myself from this thread and state.
To get port forwarding to work through the tunnel, you need to accept the incoming external traffic at the MT router, as per normal port forwarding. You then have to guide that traffic into the wireguard tunnel. This is accomplished with a properly formatted dstnat rule and and IP route.
- see my forward chain ruleset (allows port forwarding)
- Dst-nat rule for traffic to remote server, use to-address of actual server on remote router.
- Create IP route on MT
add dst-address=IPServer gateway=wg1 routing-table=main
( NOTE: since other router allowed-IPs for MT peer will be =0.0.0.0/0 different source address arriving at other router not a problem and OPs usually want to see the actual source IPs anyway. )
-
NO need to sourcenat out WG1 and dont recommend it in this case see note above…
-
Add the WG interface to the LAN interface list.
-
What you do after it leaves the MT and arrives at the other router is not our concern.
-
Return traffic will come from the server and thus will be accounted for on the allowed IPs on the MT peer settings for the other router.
-
the LAN to WAN Rule will ensure the server return traffic exiting the WG tunnel at the MT will go back out the WAN interface ( see point 5. )
Good luck!!
