I'm having a rough time with WireGuard and routing tables. I have a WireGuard VPN between 2 Mikrotik routers (both at 7.1.2, as shown in the diagram bellow:



Each side has proper routes to the other side's network, through WireGuard, and it works flawlessly.

Side A:
Side B: (internet interace and routes are omitted)

However, if I try to use mangle/conn-mark/route-mark (or a route rule) to force all traffic from a specific host on side A (such 10.10.11.31)
to flow over to side B (so it will come out to the Internet with side-B's IP address) it simply doesn't work.

I've added to side A

The router on side A will return "unreacheable" if I try pinging anything on side "B" or on the Internet. If I disable the mangle mark connection rule, then I can ping hosts on side-B, but then Internet will flow with Side-A external IP address (that is not the desired configuration)

I can make it work using an OpenVPN or L2TP VNP (simply changing the name of the gateway interace on the route command for the "to_b" routing table), albeit in these cases I use src-NAT on side "A".

Any ideas? It's really strange that

I'd expect the missing src-nat to be the cause - not only that the allowed-address of a wireguard peer chooses the traffic to be sent to that peer, but it also drops traffic from a peer if its source address doesn't match any of the prefixes in the allowed-address list of that peer.

Do you have allowed-address=0.0.0.0/0 at both sites on the peers representing each other?

COncur would need to see both configs. Strange why do you have subnet of 4096 described ?? That is like huge??
/export file=anynameyouwish

ALSO I NOTE YOUR DIAGRAM IS WRONG---> the local network A should be 10.10.10.0/20

(1) Its not clear what you desire but it appears that you want both subnets to be able to reach any device on the remote subnet.
Therefore, the allowed IPs on each peer would be the other subnet
Router A
allowed IPs=10.10.192.0/20 { ensures that incoming IPs from the remote subnet will be allowed in and they are also the destination IPs for the folks locally. }
Router B
allowed IPs=10.10.20.0/20 same same.......

That should ensure the traffic passes the wireguard tests........

(2) next is routes You have two choices. Simply create routes for both subnets or create routes using the wireguard interface IP address you have used.
for example
Router A
dst-address=10.10.192.0/20 gateway=172.16.2.1 table=main. This will ensure the local subnet users will go out wireguard and will ensure the return traffic from the remote subnet will also travel back on the tunnel
Router B
dst-address=10.10.20.0/20 gateway=172.16.2.2 table=main same same

So finally, we need firewall rules....
Router A
add chain=forward action=accept in-interface=wgName src-address=10.20.192/20 dst-address=10.10.10.0/20 ( for incoming traffic and returns )
add chain=forward action=accept out-interface=wgName src-address=10.10.10.0/20 dst-address= 10.20.192.0/20 ( to allow local traffic (originating) to go outbound on the tunnel )

Router B
add chain=forward action=accept in-interface=wgName src-address=10.10.10.0/20 dst-address=10.20.192.0/20 ( for incoming traffic and returns )
add chain=forward action=accept out-interface=wgName src-address=10.20.192.0/30 dst-address= 10.10.10.0/20 ( to allow local traffic (originating) to go outbound on the tunnel )

Note the firewall rules are predicated upon one having a drop all else rule at the end of the forward chain!.

There is no requirement for mangling!

This is an interesting statement..........
However, if I try to use mangle/conn-mark/route-mark (or a route rule) to force all traffic from a specific host on side A (such 10.10.11.31)
to flow over to side B (so it will come out to the Internet with side-B's IP address) it simply doesn't work.

You really need to state your requirements up front before even discussing how to config. This seems to indicate that you wish to ensure that all of Router As inquiries to the internet on Router B are seen with a source address of Router B users ? Why?

IN any case, the post I did before was predicated on you accessing the otehr routers subnets.
Is this not the case or are you now stating you want access to the other sites internet......

Assuming you want perhaps both then that changes things.......... So the next post will address that~

Based on really wanting internet access, not access to other subnets SIGH.....................

(1) Its not clear what you desire but it appears that you want both subnets to be able to reach any device on the remote subnet.
Therefore, the allowed IPs on each peer would be the other subnet
Router A
allowed IPs=0.0.0.0/0 { ensures that incoming IPs from the remote subnet will be allowed in and they are also the destination IPs for the folks locally. }
Router B
allowed IPs=0.0.0.0/0 same same.......

(2) You need two ROUTES per router>
Router A
/routing table add name=useWG1 fib
/routing rule src-address=10.10.192.0/20 action=lookup-only-in-table table=useWG1
dst-address=0.0.0.0/0 gateway=172.16.2.1 table=useWG1 . This will ensure the local subnet users with destination addresses for internet will go out the tunnel
dst-address=10.10.10.0/20 gateway=172.16.2.1 table=main { this will ensure return traffic originated in remote subnet will get returned }

Router B
/routing table add name=useWG2 fib
/routing src=address=10.10.10.0/20 rule action=lookup-only-in-table table=useWG2
dst-address=0.0.0.0/0 gateway=172.16.2.2 table=useWG2 . This will ensure the local subnet users with destination addresses for internet will go out the tunnel
dst-address=10.10.192.0/20 gateway=172.16.2.2 table=main { this will ensure return traffic originated in remote subnet will get returned }

NOTE: Since 0.0.0.0/0 includes the other subnet addresses, users will also be able to access the remote subnet etc....... So use Firewall RULES to limit/permit Traffic as required

As for the other interesting tidbit........ You want Subnet A to travel through the Tunnel and go out Router Bs WANIP and also no longer have source address from subnet A and vice versa................ As sindy pointed out that requires the right sourcenat rule............ probably something like

Router B
add action=src-nat chain=srcnat src-address=10.10.10.0/20 to-addresses=10.10.192.1

Router A
add action=src-nat chain=srcnat src-address=10.10.192.0/20 to-addresses=10.10.10.254

I believe that the Router will source nat all of the remote routers incoming with the IP address of the local subnet LAN and then will be further NATTED out the local router.
Thus traffic will have source address B subnet but be sent associated with public IP of Local Router. Return traffic will get back to the public IP of the router, the router will unsource nat that back to the Local subnet IP and the router will further unsource nat that back to the remote subnet IP and then it will follow the routing prescribed through table main.

@404Network: You keep doing the thing that you shouldn't be doing:

Router A
dst-address=10.10.192.0/20 gateway=172.16.2.1 table=main
...
Router B
dst-address=10.10.20.0/20 gateway=172.16.2.2 table=main

When adding route to remote subnet, correct gateway IP address is the remote one.

I believe that the Router will source nat all of the remote routers incoming with the IP address of the local subnet LAN and then will be further NATTED out the local router.

No, it won't, traffic passing through router hits srcnat only once, so there should be just one of:

So in essence the IP address of the wireguard interface CANNOT be used as the wireguard gateway?
why one works and the other doesnt is beyond me........

So in other words I have two options
OPTION 1 -use IP address of remote router wg interface and the router will know that it needs to go out the tunnel
Router A
dst-address=10.10.192.0/20 gateway=172.16.2.2 table=main
...
Router B
dst-address=10.10.20.0/20 gateway=172.16.2.1 table=main

OPTION2 -just use wg interface name and the router knows it needs to go out the tunnel.
Router A
dst-address=10.10.192.0/20 gateway=wg1-name table=main
...
Router B
dst-address=10.10.20.0/20 gateway=wg2-name table=main

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

As for sourcenat, I am not sure you understand.

The OP wants All subnet B traffic heading over the wireguard tunnel, to go out Router A's WANIP.
On top of that he wants all the below the line source addresses to be from the local router (like coming from subnet A) not the originating B subnet.

If you are saying this is not possible OKAY!
Then I agree one of the sourcenat rules only is required.

I thought it was possible to source nat within a router and external to a router......... ?????
I suppose what your saying is that you cannot source nat at layer 2?? or are you saying you can only source nat at WAN interfaces............... my brain hurts LOL.

@404Network: About routes, yes, now you have correct gateway addresses. And for further discussion about what address can be gateway see this post and continue in that thread.

As for NAT, you seem to be mixing not only numbers, but also letters, and inventing additional requirements on top of that. Because I see only this one:

... force all traffic from a specific host on side A (such 10.10.11.31) to flow over to side B (so it will come out to the Internet with side-B's IP address) ...

And that needs:

- on Mikrotik #1, WG peer for Mikrotik #2 must have allowed-address=0.0.0.0/0
- on Mikrotik #1, something to route this traffic to WG tunnel, either OP's marking or your routing rule, only with correct src-address=10.10.11.31
- on Mikrotik #2, firewall filter must allow routing from WG interface to WAN interface
- on Mikrotik #2, there must be one of srcnat rules I posted, if the existing one doesn't cover this already

Thanks for all the comments. Let me start to address some of the points:

ALSO I NOTE YOUR DIAGRAM IS WRONG---> the local network A should be 10.10.10.0/20

Ah... nope: 10.10.10.0/20 = IP address 10.10.10.0 on the 10.10.0.0/20 network. The /20 applied to x.x.0.0 will go from x.x.0.0 to x.x.15.255, thus all adresses in the 10.10.10.x are covered.

As for the purpose:

Just to make it clea about the purposer: Network on side-A can see network on side-B and vice-versa. No problem here. The idea is to have *all* internet traffic from selected hosts on Side-A exit to the Internet from Side-B (the router on side-A itself shall not be subjected to this, otherwise the WireGuard tunnel will not work). This is the part that is not working.

I acknowledge that I should have posted the peers definitions for both sides:
Allowed IPs on Side-A for Peer-B contains 0.0.0.0/0.
Allowed IPs on SIde-B for Peer-A contain 10.10.0.0/20, 172.16.2.0/30

In my config the WireGuard is set as being part of the Internal network thus will not be subject to source-NAT and traffic will pass both the input and forward firewall chains.

As for source-NATing the WireGuard, I think that if both routers are properly configured and know what networks are on the other side of the tunnel, then source-NAT should only be used once at the interface facing the Internet for outbound traffic (in this case on router B). But for what's worth, I've already tried adding the source-NAT (both explicit and the masquerade) and no go.

@404Network: "So in essence the IP address of the wireguard interface CANNOT be used as the wireguard gateway? why one works and the other doesnt is beyond me........"

My Understanding here is that WireGuard is not a point-to-point interface. It's more like a broadcast interface (with no broadcast) where there can be several hosts and even networks connected to the Interface (a single broadcast interface can have different IPs on different connected networks). A single IP address for a local WireGuard may have more that one peer on the other side. Therefore the proper way to route traffic over WireGuard is to have a route to <peer-address>/<prefix> to the WireGuard interface and to route any other network to gateway=<peer-address>. That way WireGuard knows what peer to use. Using gateway=wireguard1 or gateway=locai-wireguard-ip may work if only one peer is connected. This is simular to broadcast interfaces. (My guess that since WireGuard has some topology knowledge, this may be offset if the "Allowed-IPs" for the peers are non-overlapping, thus WireGuard may use this information to properly forward packets - needs testing).

@Sob: ypu are correct
- MKT #1 def of peer for MKT #2 contains 0.0.0.0/0
- Routing selection is done with mangle because it's more than one IP, and I can control it with an address list - this works fine when the VPN is OpenVPN or L2TP.
- On Mkt #2: filters are allowing the traffic. And the issue seems to be on the Mkt #1 side as it is the one returning ICMP unreacheable.
- On Mkt #2 there is a src-NAT rule (masquerading) and it works fine for Side-B/Internet traffic and from Side-A with OpenVPN or L2TP.

Really puzzing. I later today to replace Mkt #1 with a space router with a much simple configuration (the actual one is way more complex) and redo everything. Lets see what happens.

Arnaldo, seeing is not a purpose, and vice versa implying site B users have some purpose at site A
So you want Site A to use Site B for internet
What do you want site B users, including the admin to do on site A, if nothing make that clear as you intimate otherwise which is very confusing.

As for Site A to Site B, what is not clear is intent.
1. Do you wish all site A users to use Site B internet ?
2. Do you wish some site A users to use Site B internet and the rest of Site A users not to have internet?
3. Do you wish some site A users to use site B internet and the rest of Site A users to use local (router A) internet?

How many users will be going through site B for internet ??
How do you determine this?
Are they a contiguous IP block or all over the place?
Are they captured in a Firewall address List?

Depending, it may be that mangling is unavoidable........
and then I am really out of a job.


(As for source-nat, yes my bad I read too much into the source nat request and thought you wanted the traffic from site A users to hit the B router, then get assigned a B subnet IP before going out the internet and that is why I was trying to sourcenat A into B and then again out to the internet. Apparently that was not the intent, and also not possible even in RoS. Maybe I should patent the idea )

Therefore the proper way to route traffic over WireGuard is to have a route to <peer-address>/<prefix> to the WireGuard interface and to route any other network to gateway=<peer-address>. That way WireGuard knows what peer to use. Using gateway=wireguard1 or gateway=locai-wireguard-ip may work if only one peer is connected.

Not exactly. The gateway=<peer-address> is fine, but it's just for routing process, WG doesn't care about that. WG determines to which peer it should send it from their allowed-address. That's why you can't have more than one peer with same allowed addresses on one WG interface.

[Not exactly. The gateway=<peer-address> is fine, but it's just for routing process, WG doesn't care about that. WG determines to which peer it should send it from their allowed-address. That's why you can't have more than one peer with same allowed addresses on one WG interface.

Good to know, as I haven't played enough with WG to know that "Allowed-IPs" on an interface set of peers cannot overlap. So I was right in assuming: "My guess that since WireGuard has some topology knowledge, this may be offset if the "Allowed-IPs" for the peers are non-overlapping, thus WireGuard may use this information to properly forward packets - needs testing". Good to know that setting gateway=gw_interface will work. Much simpler than thinking of IP addresses. Nice!

To make my scenario clear, the requirements are:

1 - Both sites have direct Internet access using the ISP on their side.
2 - Both sites can reach hosts on the other side of the WG tunnel, through the tunnel
3 - Selected (one or more, but not all) hosts on side-A will reach the Internet by traversing the WG tunnel and exiting with side-B extenal IP address.

Selection of the hosts for (3) above is done with a firewall address list. This imply the use of a mangle rule to conn-mark and then route-mark. There can be CIDR blocks or individual addresses, but for an address list type mangle rule it does not matter (routing rule cannot use lists, and it's understandable).

The capture and setting of the routing table works fine, as the approach works great when I set the route through an OpenVPN or L2TP tunnel. When I switch to WG, router #1 (Side-A) return "unreachable".

Summary: Okay so one needs Routes for subnet to subnet traffic in both directions.
One needs allowed IPs to capture subnets in both directions. One needs a special route for one or more IPs ( the number somehow is no known) from A to go out Bs WANIP.
The latter one will be the focus of this post!

Option1: If the number is 10 or less, a reasonable number I would create single Route for these each with its own rule.

/routing table add name=useWG fib
dst-address=0.0.0.0/0 gateway=wginterface-name table=useWG
/routing rule src-address=IP1-subnetA action=lookup table=useWG { this way if WG interface is down they will be able to use WANIP of A for internet, if not desired use lookup-only-in-table }
/routing rule src-address=IP2-subnetA action=lookup table=useWG
......
/routing rule src-address=IPXX-subnetA action=lookup table=useWG

Option2: If you can carve out a contiguous chunk of IPs and more specifically that can be correctly described by a subnet address then only one rule is required........

/routing table add name=useWG fib
dst-address=0.0.0.0/0 gateway=wginterface-name table=useWG
/routing rule src-address=applicableSubnet action=lookup table=useWG

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

A quick discussion about routing...

Would have Router A......
dst-address=0.0.0.0/0 gwy=local-gateway-name table=main { lan A users go out their own WANIP }

dst-address=10.10.10.192/20 gwy=wginterface-name table=main { works regardless if IP address is assigned to wireguard interface }
Note1: allows Router to provide LAN A users a routing to LAN B subnet
Note2: allows Router to ensures LAN B traffic to LAN A, return traffic finds the path back through the tunnel to Router B.

dst-address=0.0.0.0/0 gwy=wginterface-name table=useWG { ensures identified LAN A users are forced through the tunnel to get internet on Router B }

NOTE: Since the the 10.10.192/0 traffic is more defined than 0.0.0.0/0 requests for such traffic will take priority in routing and thus not go out the first route.

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Lets say for shits and giggles, that you have this large 4000+ address block 10.10.0.0/20
Within that you want to send 10.10.10.1/24 to go through the tunnel to router B except one nasty customer 10.10.10.69/32

dst-address=0.0.0.0/0 gateway=localgateway-name table=main
dst-address=10.10.192.0/20 gateway=wginterface-name table=useWG
dst-address=0.0.0.0/0 gateway=wginterface-name table=useWG
/routing table add name=useWG fib
/routing rule src-address=10.10.10.69/32[color=#0000FF] gwy=localinterface-name[/color] table=main
/routing rule src-address=10.10.10.0/24 action=lookup gwy=wginterface-nametable=useWG

Discussion. Routing Rules are very cool and ORDER is IMPORTANT.

As for allowed IPs.
Router A will need 0.0.0.0/0 for destination addresses to be selected for tunnel use (enter tunnel outbound traffic) which covers internet addresses and subnet B addresses and and 10.10.192.0/20 for inbound subnet B traffic exiting the tunnel.
Thus allowedIPs= 0.0.0.0/0

For Router B.
Allowed IPs for destination addresses entering the tunnel outbound is 10.10.0.0/20 and for inbound traffic to exit the tunnel 10.10.0.0/20
Thus Allowed IPs= 10.10.0.0/20

As for Firewall Rules
Nothing unusual just need to let the inbound and outbound traffic flow above ( to enter and exit the wg interface and to and fro the applicable subnet and internet (for Router B).

Finally you should be able to troubleshoot connections by pinging 10.10.10.254 from RouterB and 10.10.192.1 from Router A (who needs IP addresses for wg interface ;-P )

Finally you should be able to troubleshoot connections by pinging 10.10.10.254 from RouterB and 10.10.192.1 from Router A (who needs IP addresses for wg interface ;-P )

Ha ha ha!!! This is the part that works!!! Pinging either router from the other side! And yes, I have realized that with "allowed IPs" (that can't overlap), there is no need for IP Addresss on the WG interface.

As for the setup you described, that's mostly what I have been doing. I've tried 3 route table selection methods:

- Mangle rule to mark-conn and mark-route
- Mangle rule with Address list to mark-conn and mark-route
- route rule

All fail the same way. Anyway I will try a restricted version of the configuration later on tonight, given that I'm not too tried (still recovering from long COVID).

Sorry to hear that, happy that you are on the mend! I avoid mangling like its covid

I finally managed to get it working this weekend.

The problem was that I was using a single wireguard interface for both the site-to-site tunnel and to allow inbound road warriors! The "allowed-ip" were overlapping, even though the road-warriors were "not connected" (but I guess that does not matter for WG).

Creating another wireguard interface and working from there: it worked like a charm!

Using a single wireguard interface sounds tempting. For road warriors, with a single IP on the peer side it's fine. But if a default route is involved, there can be only one peer (with allow ips: 0.0.0.0/0). One thing I've learned with WireGuard: good planning is a requirement.

Arnaldo, all of that is clearly pointed out here.
viewtopic.php?t=182340

I finally managed to get it working this weekend.
..................
One thing I've learned with WireGuard: good planning is a requirement.

Nice work arnaldo .... YES good planning is the KEY to WireGuard Success ...

Why do i have to accept 0.0.0.0/0 when i want that ip`s behind Router B can access the internet trough Tunnel B<>A <>Internet ?!
if i just make separate IP Adresses for each that should have access to the internet that won`t work...

Your question is confusing because I have no idea
A. what your network diagram looks like
B. what your c onfig looks like.

Suggesting start a new/own thread.