Troubleshooting Wireguard connection

Hi all!
I’m new to this forum and to networking as a whole, so sorry if this is a basic answer but I cannot for the life of me find a solution.
I recently bought a MT hAP ax2 and I’ve been configuring it in my home network to selfhost some services on my Raspberry Pi, and access them from the outside through Wireguard VPN.

I followed this tutorial and the written guide from this video: https://www.youtube.com/watch?v=vn9ky7p5ESM , gave the wg interface an IP, configured a peer and the client device (a macbook) the same way it’s shown in the guide, but looking at the logs from the wg client it shows “sending handshake initiation” and doesn’t get a response.

The firewall is configured with the 2 rules shown in the guide, to accept the connection and the traffic.
The only thing I can think of is the NAT: my MT is behind my ISP router, and from its webpage I NATed UDP port 13231 public to the internal IP of the MT, port 13231. This is the only thing that’s different from the guide I’m following.

Do you have any suggestions on where to go to troubleshoot the problem? I don’t know if my ISP router is dropping the connection, if I’ve configured my MT wrong, or what else.
Any help would be appreciated, thanks!

You’re probably neglecting to NAT the reply traffic on its way back out of the network.

Try this guide.

Can you provide more detail tangent.
The server device normally does not require to NAT —> Responses from single external clients.
The traffic comes in hits an MT router subnet and goes back out same way, or even the router itself for config purposes. AKA no NAT required.

However if the OP wants to use the internet of the ISP router, thats a different story.
One would suspect that anything leaving the MT is going out the LANIP of the MT on the ISP router LAN.
ITs here where the MT device must still have a SOURCENAT RULE for its traffic heading out the etherport towards the upstream router.

Even if not done, the other work around is to have the OP put in a static route for the wireguard subnet, pointing at the LANIP of the MT on the ISP router LAN.

It’s not an “if”. OP stated it explicitly, else I wouldn’t have pointed him to my double-NAT WG guide.


One would suspect that anything leaving the MT is going out the LANIP of the MT on the ISP router LAN.

On reflection, I believe it’s relevant that I wrote my guide for the CRS328, where you can’t count on routing logic without breaking it as a wire-speed switch. I needed my NAT rule to fix things up while keeping everything else working.

On the OP’s ax², the existing routing rules might work, in which case we’ll need more details about what isn’t working if my double-NAT hack doesn’t work.

There’s a fair chance it will work, though, because with the ax² behind another router, it might be configured as a pure bridge which doesn’t know anything about routing beyond “default route thattaway”.

Thanks! I’m checking it out and it definitely sounds like that may be the problem. One thing I didn’t specify is that I was actually able to get a handshake, but only while I was connected to my local network (it was a mistake actually, I thought I wasn’t connected but actually was to the ISP box’s wifi), so it could be that WG isn’t able to respond to the client over the internet. I’m at work right now, but I’ll try and add that NAT rule to the firewall when I get back.

I was also thinking that maybe configuring my ax2 as a DMZ host could also help? This way I should be able to bypass the double NAT and access directly to my MT’s firewall. Any pros and cons to doing it that way?

Thanks!

What is preferential if the ISP router does not provide some benefit that the MT router cannot, is to find out the bridge mode if possible.
In other words pass the public IP to the Mikrotik.
If you cannot do that then you simply use a static LANIP address on the ISP address and it is used as the WANIP address of the mikrotik.

Whether or not you DMZ that connection is up to you. If the ports requireing forwarding are limited then simply forward the needed ports (most use cases).
If you have a whole bunch, then maybeDMZ makes sense.
I would certainly ensure my MT firewall setup is as thought it was connected directly to the internet.

Cannot, nor will comment further on specific issues without facts! :slight_smile:
/export file=anynameyouwish ( minus router serial#, any public WANIP info, keys etc.)