WireGuard to Branch office over VPN

RouterOS General
1

I have a problem I can not seem to solve.

I have a Branch office router that is making an OVPN to Main.
I am making a WG interface to the main.

Everything on the Main network works over WG but Branch I can not reach.
HOWEVER there is also a L2TP connection to Main, and that one can reach Branch no problem:

Topography:
VPNs (client) -------------------- Main ------------------------OVPN ---------------------- Branch
WG 10.0.10.2 ----------------- 192.168.10.0/24 --------10.0.13.2---------- 192.168.13.0/24
L2TP 10.0.13.2


The Branch subnet is routed to the OVPN GW on Main (Network DST 192.168.13.0/24 to GW 10.0.13.2 at distance 1)
Branch has allow on input chain for VPN address IPs.

As stated L2TP has no problems going trough, however WG can not reach it.
Is WG in some way special that it needs sth extra? On client side? On server side? NAT perhaps?

2

Since WireGuard is a VPN, I don’t see why you have two other tunneling layers.

Your diagram doesn’t make it clear, but it looks like you’ve got L2TP-in-WG-in-OVPN. That sounds like a recipe for all kinds of problems.

If you simply your configuration, some of those problems may go away, and at that point, any remaining problems will be easier to think about.

3

I agree whole heartedly, this is the exact point starting the WG setup, to drop the rest. However I sadly can not disable the old VPN solutions before I get this one up and running.

4

Also to clear the diagram, every VPN is separate with separate subnets. Its not a VPN in VPN in VPN…

5

(1) Which is server and which is client for the initial wireguard connection.
(2) What are the required traffic flows .
a. main to branch subnets?
b. branch to main subnets?
c. main to internet via branch?
d. branch to internet via main?
e. others???

Are both MT devices?
Will need config on MT devices… /export file=anynameyouwish

6

Okay, then that means you have three gateways configured on the client machine, one for each VPN. Look at your routing tables. I suspect you’ll find that packets aren’t taking the path you think they should.

You can use advanced testing tools like nmap and hping3 to force the source IP. If that works where a regular ping doesn’t, it means you’ve got a routing problem.

Alternately, try a traceroute. It won’t solve the problem, but it’ll put it on display.

7

Found it.

The Branch Address space for the OVPN connection had a /24 mask. Since the WG now has a different subnet the mask had to be changed to a /16 bit mask.

Nasty one to find, since the OVPN on the Branch was making a dynamic route (and thats default 24 bit)

Thanks to all for the input.