My subnet is rather large 10.0.0.0/16 (no, I don’t need 65k clients, but it’s convenient to use 10.0.A.0, 10.0.B.0, … for various categories / persons). I also have a working WireGuard Road Warrior configuration in a dedicated 172.17.20.0.1/24 subnet.
I wouldn’t mind to keep it as it is right but there is one issue. The WG peers cannot connect to SMB on Windows machines as the firewall allows only the local subnet (in my understanding 10.0.0.0/16), turning off the Windows firewall doesn’t seem like a good idea (as some of the device are mobile device) although it works and doesn’t really scale as I’d have to either turn off or change the firewalls of all the Windows devices…
So I’d like the WG peers to be part of the 10.0.0.0/16 network (say 10.0.X.0). I’m just unsure how to achieve that.
I read in http://forum.mikrotik.com/t/place-wireguard-within-an-existing-subnet/163739/4 that in theory it could work, but I really don’t know how this should be done. (My home-grade router of a different brand had an IPsec setup which “just” worked. I know that WireGuard is a different beast, but maybe there is a way…)
Any help would be greatly appreciated (last time I did a bigger change I borked it and had to use Woobm-USB to get back online )
As stated in the topic it should be possible in theory if you allocate addresses from the subnet, i.e. create a new subnet which is part of the original one. For instance:
I don’t think what you want to achieve (WG Road Warriors being able to access the SMB shares) will work if you let the WG peers be part of the 10.0.0.0/16 subnet. It worked for the post you linked to, because they used the workaround to access the 10.2.0.0/16 subnet from the 10.1.0.0/16 subnet.
Let’s assume that you have successfully set the WG peers to be in a 10.0.50.0/24 subnet. When a WG client from this subnet access something on the LAN subnet 10.0.0.0/16 (an SMB server for instance), the router will happily route the packet sent by the WG peer to the destination. And the Windows Server will accept the packet (because it sees the source IP address to be in the allowed 10.0.0.0/16 subnet). But what do you think will happen when the Windows Server replies? It will be replying to an address in the 10.0.0.0/16 subnet, as a result it will completely bypass the router and only use ARP to try to find the MAC address of the IP address and only try to do everything on the same Layer 2 network. It won’t be able to send the packet back to the WG peer, because that requires the Windows Server to use the router as gateway to forward the packet. Which is not attempted if the destination is in the same configured subnet 10.0.0.0/16.
What should work is that you keep your WG peers in the 172.17.20.0/24 subnet but then add a srcnat rule to the firewall, to masquerade connection from 172.17.20.0/24 into 10.0.0.0/16 (similar to what is done for Hairpin NAT). That way, when client from 172.17.20.0/24 access 10.0.0.0/16, the source address of the packet sent will be changed to the 10.0.0.1 address of the router, which means the SMB server will accept the connection. When they answer, packets will be sent back to the router at 10.0.0.1, which will then undo the NAT and forward them to the original host within 172.17.20.0/24.
Thanks @CGGXANNX. Sounds like the way to go.
If I understand this approach correctly, all WireGuard peers over this WireGuard interface would appear as 10.0.0.1 to the internal network, right?
I tried multiple things myself but somehow there is still something off (that’s the reason it took me so long to come back to this topic…)
After finally understanding what should be done (you wrote it clearly but I somehow I couldn’t direclty process it…) I got this:
(It’s wireguard2 since I’m using a fallback WireGuard configuration for testing to still have access with the main one in case of breaking things…)
This one seemed to fail me at first, since I the first thing I test, is access to the router. And this one doesn’t work. However access to my SMB shares and other devices within the network works.
It seems I’m missing one tiny bit, why the router doesn’t allow me on the UI. SSH is also not possible, the connection times out, however ping to the router seemingly works…
The action should be masquerade instead of accept. With this action, the source address of the packet sent will be changed to the 10.0.0.1 address of the router like I described in the previous post.
And you would not want to use out-interface=wireguard2, but write the matching conditions from what I wrote above when client from 172.17.20.0/24 access 10.0.0.0/16, which is src-address=172.17.20.0/24 dst-address=10.0.0.0/16. The resulting rule would be:
)