Mikrotik as WireGuard VPN concentrator - some sites work, some are not

Hi!

I started configuring Wireguard on my RB4011 (as a VPN concentrator) and connected my computer to it as a Remote Access VPN.

VPN closes and even works but some pages format badly / do not want to open

Below is VPN server config:



FW accepts VPN connection attempts and DNS queries


And here is VPN Client config:


After the tunnel is turned on, some sites work well and some work crappy (but stable).

For example, tvn24.pl always opens correctly and speedtest.net loads in 2 minutes and always formats badly


With WireGuard tunnel working, SpeedTest CLI cannot connect:

Microsoft Windows [Version 10.0.22621.1702](c) Microsoft Corporation.
All rights reserved.

C:\Users\pawel>speedtest
[2023-05-25 09:05:52.708] [error] Configuration - Timeout was reached (TimeoutException)
[2023-05-25 09:05:52.708] [error] Configuration - Cannot retrieve configuration document (0)
[2023-05-25 09:05:52.708] [error] ConfigurationError - Could not retrieve or read configuration (Configuration)
[2023-05-25 09:05:52.708] [error] ConfigurationError - Could not retrieve or read configuration (Configuration)
[error] Configuration - Could not retrieve or read configuration (ConfigurationError)

Without the tunnel everything works fine

What I’m doing wrong here?

change MSS of TCP, Wireguard doesnt have PMTUD

/ip firewall mangle
add action=change-mss chain=forward new-mss=1380 out-interface-list=\
    Wireguard_MTU_1420 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=\
    1381-65535

Looks like an MTU issue. Try to lower the tunnel MTU by 10 bytes until it works.

A good test site to check for MTU issues is CNN.com, if that doesn’t load it’s definitely MTU.

/ip firewall mangle
add action=change-mss chain=forward new-mss=1380 out-interface-list=\
Wireguard_MTU_1420 passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=\
1381-65535

Thanks a lot!
This seems solved the problem, yet some websites still does not work - but it’s better

But there is a way to set MTU directly on the WG interface, no ? On the client side too. Why change the tcp mss if so?

Anyway, setting MTU 1500 on mikrotik interface side and MTU manually to 1500 on my android app side, I am able to push 1480 bytes without fragmentation. If I don’t manually set MTU on the android app, I am able to push only 1280 bytes without fragmentation.

To the OP:
Try to set your MTU to 1500 bytes in both sides, it should solve your problem. If not, try decreasing MTU by 10 bytes until it works (but start from 1500, not 1412).

Note: It’s quite possible that your MTU could be lower if you’re doing PPPoE. In my case, I’m doing this over a FTTH connection, that means that my packets are not being encapsulated in PPP frames. Therefore, I don’t need to account for PPP encapsulation headers.

Unfotunately even after changin MTU to 1kB it still behaves the same way

cnn.com doesn’t load at all when tunnel is up

But there is a way to set MTU directly on the WG interface, no ? On the client side too. Why change the tcp mss if so?

I faintly remember Wireguard in the Linux kernel (and Mikrotik) ignoring those ICMP codes. And you dont want to set that MTU in your LAN interfaces, cause it will drag everyone else down.

EDIT: I still had to do this here aswell even though I have MTU 1500 on both endpoints, and 1420 through the tunnel (IPv4).

Maybe they updated something, but when I ping with “don’t fragment” flag I found my currecnt “border” at 1392B

PS C:\Users\pawel> ping 8.8.8.8 -f -l 1393

Pinging 8.8.8.8 with 1393 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 8.8.8.8:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Control-C

PS C:\Users\pawel> ping 8.8.8.8 -f -l 1392

Pinging 8.8.8.8 with 1392 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 1392) time=39ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1392) time=56ms TTL=118
Reply from 8.8.8.8: bytes=68 (sent 1392) time=45ms TTL=118

Hmm. I see your point, however in my setup setting manually the MTU on client and server side to 1500 seems to solve all my problems “automagically”. I haven’t tested with windows client though, only android client, and pings with DF set.

Did you read my reply above?
Try starting from 1500 bytes MTU.
Also try setting the MTU at the client side (not only server side)

Hmm interesting, i can confirm that here too, yet i still have to do that mangling thing or nothing works, interesting.

I feel like I messed up somewhere, i gotta recheck my other mangles, the ones that route traffic maybe.

Yeah - I did. Thanks for your hint - I’ll definitely give it a try
I just don’t have enough time to test every hint one by one - wish I’d had :slight_smile:

Don’t do anything on clients, that’s bad practice