Hi,
I.m trying to setup PBR to route certain subnets stored in a "address-list" through a wireguard tunnel. Wireguard works fine, static routes work fine, however, I am not able to figure out why "routing-mark" doesn't work. Here are the relevant parts of my setup:


# software id = Y6VN-URPQ
# model = RB750Gr3
...
/interface wireguard
add listen-port=52311 mtu=1420 name=wg1 private-key="*******************"

/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=mysecretgw.com \
endpoint-port=52311 interface=wg1 preshared-key="************=" public-key="**********"
...
/ip address add address=10.6.1.2/24 comment=mysecretgw.com interface=wg1 network=10.6.1.0
...
/routing table
add fib name=VIA_WG1
...
/ip firewall address-list
add address=5.2.128.0/19 list=DIGI-NETWORK
add address=5.2.160.0/21 list=DIGI-NETWORK
add address=5.2.174.0/24 list=DIGI-NETWORK
add address=5.2.178.0/23 list=DIGI-NETWORK
...
/ip route add comment=VIA_WG1 disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\
10.6.1.1 pref-src="" routing-table=VIA_WG1 scope=30 suppress-hw-offload=\
no target-scope=10
...
/routing rule add action=lookup disabled=no routing-mark=VIA_WG1 table=VIA_WG1
...

/interface list member
add interface=ether2 list=LAN
add interface=ether1 list=WAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=WAN
add interface=vlan1 list=WAN
add interface=wg1 list=LAN
...
/ip firewall filter
add action=accept chain=output
add action=accept chain=input comment=\
"Accept all input:established, input:related" connection-state=established,related
add action=accept chain=input comment="Ping from WAN" in-interface-list=WAN protocol=icmp
add action=accept chain=input comment="Wireguard Service" dst-port=52311 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="DHCP Service" dst-port=67 in-interface-list=!WAN protocol=udp src-address-list=PRIVATE_NETWORKS
add action=accept chain=input comment="DNS Service" dst-port=53 in-interface-list=!WAN protocol=udp src-address-list=PRIVATE_NETWORKS
add action=accept chain=input comment="Ping from LAN" in-interface-list=LAN protocol=icmp src-address-list=PRIVATE_NETWORKS
add action=accept chain=input comment="Mikrotik Winbox Access" dst-port=8291 in-interface-list=!WAN protocol=tcp src-address-list=PRIVATE_NETWORKS
add action=accept chain=input comment="SSH Service" dst-port=22 in-interface-list=!WAN protocol=tcp src-address-list=PRIVATE_NETWORKS
add action=accept chain=input comment="NTP Service" dst-port=123 in-interface-list=!WAN protocol=udp src-address-list=PRIVATE_NETWORKS

add action=drop chain=input
add action=fasttrack-connection chain=forward comment=FastTrack connection-state=established,related disabled=yes hw-offload=yes
add action=accept chain=forward comment="forward:established, forward:related" connection-state=established,related
add action=drop chain=forward comment="Drop invalid" connection-state=invalid log=yes log-prefix=invalid
add action=drop chain=forward comment="Drop incoming packets that are not NAT`ted" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN log=yes log-prefix=!NAT
add action=jump chain=forward comment="Jump to ICMP filters" jump-target=icmp protocol=icmp
add action=drop chain=forward comment="Drop private subnets incoming from internet" in-interface-list=WAN log=yes log-prefix=!public src-address-list=PRIVATE_NETWORKS
add action=accept chain=icmp comment="echo reply" icmp-options=0:0 protocol=icmp
add action=accept chain=icmp comment="net unreachable" icmp-options=3:0 protocol=icmp
add action=accept chain=icmp comment="host unreachable" icmp-options=3:1 protocol=icmp
add action=accept chain=icmp comment="host unreachable fragmentation required" icmp-options=3:4 protocol=icmp
add action=accept chain=icmp comment="allow echo request" icmp-options=8:0 protocol=icmp
add action=accept chain=icmp comment="allow time exceed" icmp-options=11:0 protocol=icmp
add action=accept chain=icmp comment="allow parameter bad" icmp-options=12:0 protocol=icmp
add action=drop chain=icmp comment="deny all other types"

/ip firewall mangle
add action=mark-packet chain=prerouting dst-address-list=DIGI-NETWORK log=\
yes new-packet-mark=VIA_WG1 passthrough=yes
add action=mark-connection chain=prerouting log=yes new-connection-mark=\
conn_WG1 packet-mark=VIA_WG1 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=conn_WG1 log=yes \
new-routing-mark=VIA_WG1 passthrough=no
...


I would expect when pinging an IP that's part of a "DIGI-NETWORK" to get logged, but the PBR does not work and nothing shows up in the logs. Any ideas? what am I doing wrong ?

Can you clarify if the router here is at the server end or the client end.
I am assuming you are doing wireguard from MT router to MT router is that the case? OR are you doing MT router as client to 3 party VPN provider??
(reason I ask is I only see one MT router here and it seem set up to be the client end).

The MT is a wireguard client connected to a remote server (my own wg server, another country, no 3rd party providers). The remote WG server is in the same country as DIGI-NETWORK, my goal is to route DIGI-NETWORK destined traffic (destination -> DIGI.NETWORK) through the WG tunnel in order to hide my local public IP. The WG tunnel works fine, I have static routes in place for private subnets from the other side that work without issues:

/ip route add comment="WG1 static" disabled=no distance=1 dst-address=192.168.1.110/32 \
gateway=10.6.1.1 pref-src="" routing-table=main scope=30 \
suppress-hw-offload=no target-scope=10

Makes sense.

So to me the only difference from routing all traffic from a subnet on the client
dst- 0.0.0.0/0 gwy=wireguard_interface Routing Table - HideMyIP / Action - Lookup only in table Table - HideMyIP source-address - client subnet

To what you are asking seems to be the addition on the RULE part adding the PBR stuff........
Action - Lookup only in table Table - HideMyIP source-address - client subnet, ROUTING MARK - >>>>>>
Sadly no option for dst-address-LIST in the route rule.

Here is what I would do..... cause just like capsman I hate mangling LOL.

1x IP Route:
dst=0.0.0.0/0 gwy=wireguardinterface Routing Table=HideMyIP

4x Route Rules:
source-address=applicable subnet dst-address=5.2.128.0/19 Action=Lookup Only in Table Table=HideMyIP
source-address=applicable subnet dst-address=5.2.160.0/21 Action=Lookup Only in Table Table=HideMyIP
source-address=applicable subnet dst-address=5.2.174.0/24 Action=Lookup Only in Table Table=HideMyIP
source-address=applicable subnet dst-address=5.2.178.0/23 Action=Lookup Only in Table Table=HideMyIP

If this is applicable to all subnets then just remove the source address portion.

By the way, I dont assign any IP address to my wireguard interfaces as I have yet found a reason to do so!!!

@anav - thank you so much for your time and effort to help me out.

I am aware of the soultion you've suggested, in fact that's what I'm using currently as a workaround to my problem, but it's not a perfect soultion because:

1. "DIGI-NETWORK" is a long list (I've provided 4 subnets just to make a point),
2. Not all traffic in "DIGI-NETWORK" should go through the tunnel, e.g. the remote wireguard gw resides in the "DIGI.NETWORK" (server name is set by dynamic DNS, changes frequently) therefore UDP52311 should not get routed through the tunnel - this solution only works if I "know" the public IP of the remote WG GW + disable the route to that subnet/ip.
PBR would have been an elegant soultion, I'd have the option to route only certain ports or protocols through the tunnel while setting up only a few static routes.

No worries, Ive reached the extent of what I know to help LOL.
By the way I use the IP cloud dyndns name of the MT routers as endpoints and in firewall address lists.

What bugs me and what NORMIS still has to answer, is if the IP mynetname I put in wireguard settings will update if the far endpoint changes.
Right now I believe it resolves to the correct IP but unlike firewall address lists, there is no obvious dynamic assignment that gives me a warm and fuzzy .

IN addtiion I suggest that there are both paid and free dyndns name hosts out there and thus every public IP you have could be reacheable via this method.

Thanks again @anav, your help is much appreciated.

One more question, though: Why is it not working? Is it a missing feature, or is this a bug ?

I'm facing same issue

I would like to route specific address list over to wireguard tunnel

Is there something that I've missed ?
Edited:
Sorry, seems the problem on my wireguard tunnel, since when I'm change the route over PPTP tunnel, the traffic works well