I established a separate WireGuard connection to Device A from my laptop in the hotel, that Device A WireGuard subnet is 192.168.200.0/24 and my laptop has IP address 192.168.200.11 once connected. Device B has a static route for the 192.168.200.0/24 subnet via 192.168.10.1. I used the packet sniffer streaming feature on Device B (192.168.10.5) to stream the UDP packets back to my laptop in the hotel (192.168.200.11:37008 via WireGuard). So whilst the WireGuard VPN to Device A was established (to allow me to stream the UDP packets back from Devcie B) I then established the WireGuard connection from the laptop to Device B (using command line WireGuard client).
With Wireshark running a capture filter “(udp port 37008) or (udp port 13232)” on the hotel laptop I captured the streamed packets from Device B on UDP port 37008 and the WireGuard connection attempt on UDP port 13232 at the same time so we could see both sides in the one capture.
That transfer.sh server is semi-dead for me, it was slow before, but now I managed to download only client_connect.pcap and it took two hours.
The obvious problem is that it contains only initial requests, there’s not a single response. It was the same in previous combined capture as well. All non-TZSP packets are from client to server. But if you look at TZSP packets, you can see that device B is sending responses.
So one more thing you can try is to capture packets on device A’s WAN interface. If you see responses there, the problem is somewhere else. If not, then they are eaten either by device A, or by something between device A and B (you could try another capture on device A’s LAN interface to tell which it is).
Client WAN IP: 49.195.16.14
Client LAN IP: 192.168.8.101
Device A WAN IP: 123.209.117.65
Device B LAN IP: 192.168.10.5
I have also built a new WireGuard server on a Raspberry Pi. I can connect to it successfully locally (within the 192.168.10.0/24 LAN) but when I DSTNAT to it from Device A I cannot connect to it from the WAN side. I will provide packet captures for this connection as well if it helps.
It’s still the same thing. There are requests coming from client to server, and on your routers you can see responses from server to client. But for some reason, none of them reaches the client, so it’s no suprise that connection fails. It doesn’t look like you can do anything on your routers. I’d blame the other side, or your ISP, but it seems you tested it from two different places, and you wrote that WG connection to device A works, so that’s not it either.
I’m running out of ideas. Last one for now, although there’s no reason why it should be the problem, did you try to connect only to device B and no other server at the same time?
I set up a dirt cheap TP-Link LTE 4G router with the same SIM card and gave it the same LAN IP address and set up a port forward to the Mikrotik Device B. I connected from the same iOS WireGuard client and it successfully connected and performed handshake.
The issue has to be within the DSTNAT part of the Mikrotik Device A.
Not that it would be completely impossible, but dstnat is simple thing, it’s there for years, everyone uses it, … it’s not likely that it would get broken and not noticed by many other people. On the other hand, it is beta version, so maybe the chance is slightly higher.
You can test another service. Not tcp, that may be different, but udp. In v7 there’s udp support for OpenVPN, so you can test it with that.
I agree… its just strange that the Mikrotik cAP running WireGuard worked fine behind a non-Mikrotik cheap 4G router doing the dstnat. No changes were made to the Mikrotik cAP, just connected ethernet and set up the port forward and it worked. I can test OpenVPN but it will take some time to set it up on the Mikrotik. I will give it a go later tonight.
Or try dns as the first easy test. It’s just one packet with request and one with response, but since with WG not even first response made it back to client, it could be enough.
Sorry, but I’m a little confused. Are you saying that you have put a 7.1beta2 WireGuard instance (Device B) behind a 7.1beta2 router (Device A) and its all working?
So how do I troubleshoot my failed installation then? It works if I put a cheap router in front and port forward, it fails when I put a $365 Mikrotik Chateau LTE12 in front and dstnat the WireGuard traffic.
It’s difficult. Your packet captures showed that responses are being sent by device B and they also seemed to successfully pass through device A and continue to internet and client. But with LTE connection you can’t verify this last part. If it was regular ethernet, you could add another device between device A and ISP and see that it definitely sends those packets.
Although, you can sort of do it. Put SIM in TP-Link, connect Chateau behind it, and then cAP behind that, so you’ll end up with double NAT. Forward port from TP-Link to Chateau and from there to cAP. If it works, then 7.1beta2 on your Chateau is not completely broken. The difference between non-working and working would be only whether you use LTE or ethernet as uplink. In that case, it would seem as possible bug, and you could try to continue with MikroTik support, send them supout from router and hopefully they would see something in it.
Ok, so putting the TPLink LTE router (Device 0) in front of Device A and placing a port forward (UDP 13232) on Device 0 to Device A, and then Device A with a port forward to Device B WORKED.
So its not the dstnat that the problem it is something in the LTE side of things.
Device 0 - TPlink LTE router WAN 100.96.102.142 / LAN 192.168.6.1
Device A - Mikrotik Chateau LTE12 - WAN 192.168.6.254 / LAN 192.168.10.1
Device B - Mikrotik cAP ac - LAN 192.168.10.254
Packet capture from Device A and Device B (couldn’t get packet capture from TPLink as there is no way to get a port into promiscuous mode):
