Hi,
Further to my previous post I'm trying to set up a wireguard tunnel on an LtAP so that it can be accessed remotely using a private IP.

For clarity:
- The LtAP will initiate a wireguard connection to a data centre over the internet
- The wireguard IP of the LtAP will be in a private range local to the data centre

I set up a dstnat rule to change the destination IP of traffic coming from the wireguard interface (10.122.128.26) to the ip of the LtAP's (192.168.3.253 - ether1 is connected to another LAN which is providing internet access and this IP comes from DHCP there):
This works for packets coming from the wireguard interface but doesn't route the return packets back, presumably because they have a destination of 192.168.3.253 and so get routed out over the default gateway. I added a route:
which forces packets heading for 10.122.0.0/16 back over the wireguard interface. This works but doesn't feel quite right.

I expected dstnat to magically track the connections and route packets back - am I missing something?

I suspect I'm wrong in using dstnat to transform the destination address to 192.168.3.253, and should instead use a different local IP?

To be clear, I think we should talking source nat not dst nat?

If the below is accurate use srcnat not dstnat.
Your MT device is a peer client for handshake and connects to a peer server for handshake at a data center.
The data center is solely expecting traffic to come from the single WG IP address provided to you.
To ensure all your subnet traffic behind the MT device is accepted at the other end, one must sourcenat the connection.

add action=srcnat chain=masquerade out-interface=wireguard-Interface

Thank you anav.

One consideration I'm not sure I explained properly is that connections will be initiated from the data centre. I would like to be able to make http requests through the web proxy on the LtAP via the wireguard interface, but also be able to manage the device itself.

So the LtAP will initiate the wireguard connection to the data centre, but connections will then be initiated over the wireguard connection from the data centre side.

Does this affect your advice at all?

Not sure I understand BUT.


Yes if the wireguard config is correct at both sites, the MT device will initiate the connection and establish the tunnel and will keep the tunnel alive.
What you should be able to do is.

a. behind the MT, access the internet provided by the data center connection to the WWW.
b. be remote anywhere, in a cafe, hotel etc, with smartphone or laptop, etc. and thru the data center
i. connect to the MT device to configure it.
ii access the subnets behind the MT device

If that is what you mean, we are on the same page.
The big unknown is this data centre entity. If it was MT CHR running on a data center server, Id be happy, however
you have not indicated what it is, whether or not you have access to it, if you can configure it via any rules ???

I tried removing the ip route and dst nat rule and added: as suggested, but did not get the behaviour I want.

For further clarification:
The data centre is just where the wireguard "server" is. It's not Mirotik based but I don't think that's relevant. It provides the wireguard endpoint and controls the wireguard IP address that gets set on the Mikrotik LtAP. Traffic in the data centre gets correctly forwarded over the wireguard connection - when I run `ping 10.122.128.26` from the data centre I can see ICMP packets arriving on the Mikrotik via the wireguard interface.

ping doesn't work without these two settings: The first translates the destination address of the packets to one that the Mikrotik knows how to route. On its own this makes the ICMP packets arriving at the Mikrotik get routed correctly but I believe the responses get routed to ether1 as the main gateway.

The second setting causes any packet with a destination in 10.122.0.0/16 to get sent via the wireguard interface. This includes the responses, but is obviously a fairly rigid rule routes any packets headed for 10.122.0.0/16 to go via the wireguard interface, even if the connection was initiated from ether1. Similarly if I tried to ping the Mikrotik from the datacentre via an IP that was outside of that address space the responses would not go back via the wireguard interface.

I was hoping that connections initiated from the data centre side of the wireguard tunnel could be tracked and responses routed back via the tunnel. I've added a mangle rule:
which I think should mark the connections, but I'm not entirely sure what the next step is.

It's much easier to understand if you just explain the end goal. For example, do you want to access the LAN behind the LtAP from the data center, or the other way around (or both ways?)

To make it easier to suggest a practical solution, please provide the subnet on each side.

Yes, I would like to access the LAN behind the LtAP from the data centre. I don't want to access the data centre LAN from the LtAP.

The end goal is to be able to deploy the LtAP anywhere with a wired internet connection (connected to ether1) and use it as a proxy server from the data centre via the wireguard IP.

I want to at least be able to use the proxy server on port 8080 (so sending requests to 10.122.128.26:8080 from the data centre) and webfig (10.122.128.26:80), though I hoped there might be a general solution rather than specifying individual ports.

EDIT: sorry, I realise I've not provided the subnet on the LtAP side.
I'm perhaps realising a mistake here. The LtAP is currently plugged into a router via ether1 which is providing a 192.168.3.253 address via dhcp. I notice that ether1 is assign as a bridge port. I think this is a mistake and it should not be. The DHCP server is still set up for Mikrotik's default 192.168.88.0/24 space but no address from that space is assigned.

I think I need to assign 192.168.88.1 to the bridge and remove ether1 from the bridge ports. I could then add another IP (e.g. 192.168.88.2) and dstnat all traffic from wireguard to there, and have a route back from that to wireguard. Does that sound reasonable?

I'm not sure what you mean by "proxy server," but if your DNS-NAT is set up correctly, you shouldn't need a return route. To access your LAN, you'll still need to add a route from the datacenter and allow access in the forward chain on the LtAP. If you want to allow access to the LtAP itself, you need to allow it in the input chain.

Could you share a simple network topology, something like this?
Datacenter [x.x.x.x/yy] -> WireGuard interface [x.x.x.x] -> INTERNET -> LtAP WireGuard interface [x.x.x.x] -> LAN [x.x.x.x/yy]

Sure, it's:

Datacenter [10.122.128.0/24] -> WireGuard interface [10.122.128.26] -> INTERNET -> LtAP WireGuard interface [10.122.128.26] -> LAN [192.168.3.0/24].

I want to be able to talk to the LtAP from the data centre on IP 10.122.128.26 as if I'm on the 192.168.3.0/24 LAN and I'm accessing 192.168.3.1 (which is now assigned to the bridge).

I think you might have accidentally written the wrong address for one of the WireGuard interfaces since both have the same one.

To my understanding this is how it works, though my past experience has been setting up a more traditional usage where wireguard clients connect to a server and then access things on the server's LAN. The IP address is defined in the server and the client sets the same one in their config. Packets sent from the DC to 10.122.128.26 arrive on the LtAP with a destination address of 10.122.128.26. I can add an IP to the wireguard interface but I'm not sure how that helps.

I'd be very glad to be corrected here!

What currently works is:
- a packet, (e.g. ICMP) sent from DC to the LtAP arrives at the wireguard interface with src: 10.122.x.x, dst: 10.122.128.26
- DST-NAT translates this packet's dst to 192.168.3.1
- The router generates a response packet with src: 192.168.3.1, dst: 10.122.x.x
- An entry in ip/routes routes this packet to the wireguard interface

Having written that out I'm wondering whether the src address is wrong on the return path.

EDIT: confirming in wireshark the return packets have the correct src address. I suppose this is the dst NAT working?
The real question might then be how to automatically route the response packets back to the wireguard interface without the somewhat rigid ip route for all 10.122... addresses.

If the data center already uses the entire 10.122.0.0/16 subnet for other purposes, it’s better to pick a different subnet for the WireGuard tunnel. That way, you avoid routing conflicts and make return traffic easier to manage if needed.

A good option would be 172.16.10.0/24, with for example 172.16.10.1 on the data center side and 172.16.10.2 on the LtAP.

You’d still need a route at the data center, something like "/ip route add dst-address=192.168.3.0/24 gateway=your-dc-wireguard-interface.