What is the entrypoint of the WG tunnel? I assume it the Mikrotik router and all else what is outside the tunnel between that and the exit point is invisible to the encrypted traffic…and vise versa, it should be the same.
ONT (Optical Network Termination) integrate to Modem Router mode bridge to ISP, mikrotik(mode firewall router, nat, dhcp) receives any from ISP
So basically you get a private LANIP from the ISP modem/router which is the also the WANIP of the RB4011
Hello,
There is one thing I do not understand really.
Assuming a MT router is behind a pure VDSL modem. When connected, the /ip/dns prints “dynamic-servers” from the DSL-ISP.
I read a few nice tutorials here and tested a bit under 7.1.3, setting up very simple VPN tunnels for one single ip address (via a fw address-list) with VPN providers supporting IKE or WG.
Eventually tunnels were rock stable and all worked quite good for several days and I was optimistic for productive use.
However (strangely) just recently, dhcp/auto-dns users outside of the address-list for VPN were not able to get name-resolution anymore.
I noticed that when the test-tunnel was alive, these auto-config users (not even affected by the address-list in fw for use of VPN) the second the tunnel was alive received the VPN Provider’s NS and, thus, name resolution was no more possible for them. It seems that the tunnel setup simply overrides the /IP/DNS “dynamic-servers”.
My question is: How to easily manage that other devices within the network can still have their auto-setups to still use the DSL-ISP’s DNS?
I would love to understand how this works and am highly interested in this topic in general. Any tutorial or help would be great.
Guys, I’m having a similiar problem, not sure if its with routeros or vpn provider side. The funny thing is I can access http (port 80) traffics via vpn, but https (443) gets timeout.
Here the gist of it.
Connecting wireguard tunnel
/interface wireguard
add listen-port=13235 mtu=1420 name=surfshark
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=sg-sng.prod.surfshark.com endpoint-port=51820 interface=surfshark \
persistent-keepalive=25s public-key="..."
add allowed-address=172.16.0.36/32 endpoint-address=92.249.38.1 endpoint-port=51820 interface=surfshark \
persistent-keepalive=25s public-key="..."
/ip address
add address=10.14.0.2/16 interface=surfshark network=10.14.0.0
add address=172.16.0.36 interface=surfshark network=172.16.0.36
masquerade the packets of tunnel
/interface list
add name=WAN
/interface list member
add interface=surfshark list=WAN
/ip firewall nat
add action=masquerade chain=srcnat out-interface-list=WAN
Routing, here I want the local device 192.168.10.17 having all its traffic routed through the vpn tunnel.
/routing table
add disabled=no fib name=surfshark-bypass
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=surfshark routing-table=surfshark-bypass scope=30 \
suppress-hw-offload=no target-scope=10
/routing rule
add action=lookup-only-in-table disabled=no src-address=192.168.10.17/32 table=surfshark-bypass
Now I also tried mangle to mark route 192.168.10.17’s to surfshark-bypass table. Same result.
In the device:
ping ipinfo.io
curl http://ipinfo.io
works, but
curl https://ipinfo.io
gets stuck. Basically every time in chrome / browser gets timeout. As if the device doesn’t have internet access. Any idea what is happening / how to fix?
Here is the wireguard config file, that works flawlessly in linux with wg-quick.
[Interface]
PrivateKey = HIDDDEENN.....
Address = 10.14.0.2/16
DNS = 162.252.172.57, 149.154.159.92
[Peer]
PublicKey = HIDDDEENN.....
AllowedIps = 0.0.0.0/0
Endpoint = sg-sng.prod.surfshark.com:51820
[Peer]
PublicKey = HIDDDEENN.....
AllowedIPs = 172.16.0.36/32
Endpoint = 92.249.38.1:51820
ubuntu@ubuntu:~$ sudo wg-quick up ./sg.conf
Warning: `/home/ubuntu/sg.conf' is world accessible
[#] ip link add sg type wireguard
[#] wg setconf sg /dev/fd/63
[#] ip -4 address add 10.14.0.2/16 dev sg
[#] ip link set mtu 1420 up dev sg
[#] resolvconf -a tun.sg -m 0 -x
[#] ip -4 route add 172.16.0.36/32 dev sg
[#] wg set sg fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev sg table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
ubuntu@ubuntu:~$ curl https://ipinfo.io
{
"ip": "103.216.223.166",
"city": "Singapore",
"region": "Singapore",
"country": "SG",
"loc": "1.2897,103.8501",
"org": "AS136557 Host Universal Pty Ltd",
"postal": "018989",
"timezone": "Asia/Singapore",
"readme": "https://ipinfo.io/missingauth"
}
I would need to see the full config of the mikrotik device,
/export file=anynameyouwish
Just looking at the wireguard for the MT…
Assuming its the client which is fine, what is very confusing is why are there two peers to the 3rdparty VPN?? (same listening port, different IP??)
you also have two addresses for the wireguard interface, for what purpose?
You need to make it more clear exactly what traffic flows are required. Is it just the one device going out for internet, or is there more/other requirements.
/interface wireguard
add listen-port=13235 mtu=1420 name=surfshark
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=sg-sng.prod.surfshark.com endpoint-port=51820 interface=surfshark
persistent-keepalive=25s public-key=“…”
add allowed-address=172.16.0.36/32 endpoint-address=92.249.38.1 endpoint-port=51820 interface=surfshark
persistent-keepalive=25s public-key=“…”
/ip address
add address=10.14.0.2/16 interface=surfshark network=10.14.0.0
add address=172.16.0.36 interface=surfshark network=172.16.0.36
Yes, its the client. Check the wireguard config file I included in previous post. The config file was generated by surfshark app. They use that config file to serve their vpn. And If I take that config file and run it with wg-quick in a fresh linux vm, there the wireguard vpn works too. But In mikrotik I can’t make it work.
I attached my router full config. I removed some public IPs and some private MAC address etc… with REMOVED as I don’t want to publish them in public forum.
Update: Removed attachment as it was not really relevant after all. Relevant config snippets are in previous post.
Let me put it another way.
if the MT is a client why do you have this… I mean besides the default…
(in fact there is no need for any listen port…)
/interface wireguard
add disabled=yes listen-port=13233 mtu=1280 name=cloudflare-warp
add listen-port=13232 mtu=1420 name=mcmslave
add listen-port=13231 mtu=1420 name=nordlynx
add listen-port=13235 mtu=1420 name=surfshark
If its a client why are there five peers noted and not just ONE, the Third party provider.
What traffic is coming to the mikrotik from the tunnel.
What traffic is originating on your mikrotik going out the tunnel
Umm because you can’t make the listen-port empty for a wireguard interface? If I empty it and apply routeros just puts a random port there, so I entered some ports myself 
Because, I can (and I need) establish multiple tunnels to multiple provider, then selectively route different data through different tunnels. mcmslave is creating a local network (192.168.x.x) between few of my friends’ houses. cloudflare-warp, nordlynx and surfshark are vpn providers. cloudflare-warp is disabled for now so lets skip it. surfshark provides 2 peers (reference their app’s generated config file), WHY that is I don’t know the answer, only surfshark can answer 
192.168.x.x and 10.99.0.x are local ips and creating a local network between my friends’ houses. These are routed through the mcmslave interface. Realistically this mcmslave is only wireguard interface that transmits AND receives data.
Right now only nordlynx is “kinda” active (and its working). Websites listed as vpnbypass in /ip firewall address-list are going through the nordlynx tunnel. For example reddit, so anyone under my network tries to browse reddit, it’ll be marked as vpn-bypass. This comes from /ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=vpnbypass new-routing-mark=vpn-bypass passthrough=no. Then routing-table=vpn-bypass gets routed through 10.5.0.1. This is nordlynx’s gateway ip, this belongs to nordlynx tunnel bcz of /ip address add address=10.5.0.2/24 interface=nordlynx network=10.5.0.0
The difference between nordlynx and surfshark (and I suspect cloudflare-warp) is, nordlynx HAS an gateway IP - 10.5.0.1. So for routing traffic for it, I am doing: dst-address=0.0.0.0/0 gateway=10.5.0.1 in /ip route. But for surfshark (and cloudflare-warp) I need to do dst-address=0.0.0.0/0 gateway=surfshark. So I’m putting the wireguard interface name as gateway. While this works in linux and window’s wireguard, it doesn’t seem to work properly in routeros.
Imagine john’s device has 192.168.10.17 ip address and is under my network. Now I want all INTERNET traffic originating from john’s device to go out to the world via surfshark vpn. To achieve this I did
/routing rule
add action=lookup-only-in-table src-address=192.168.10.17/32 \
table=surfshark-bypass
Now to verify this I ran the commands below from john’s device.
ping ipinfo.io
curl http://ipinfo.io
curl https://ipinfo.io
Here ping rans successfully, curl to http://ipinfo.io works, and as ipinfo.io is a service that returns your ip info, from the output I can see the ip / city / country got changed to surfshark’s vpn location. But curl to https://ipinfo.io fails. It times out. This is my problem. And I want to solve this. I suspect somehow packets are getting broken/crashed/lost or something, so a simple ping and a simple http request can go through, but complex tcp connection like https gets broken and lost.
This comes from /ip firewall mangle add action=mark-routing chain=prerouting dst-address-list=vpnbypass new-routing-mark=vpn-bypass passthrough=no. Then routing-table=vpn-bypass gets routed through 10.5.0.1. This is nordlynx’s gateway ip, this belongs to nordlynx tunnel bcz of /ip address add address=10.5.0.2/32 interface=nordlynx network=10.5.0.2
The TCP MTU has been always a source of slow pages or even pages not loading. When using IKEv2 or WireGuard. If I only want to change the MTU of traffic being encrypted a simple line helps to find the correct MTU to be used.
/ip/firewall/mangle
add action=change-mss chain=forward comment="WireGuard & IKEv2 Sync" ipsec-policy=in,none new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
This line only handles SYNC packet that negotiate the MTU in the TCP handshake between the client and server. An ipsec-policy=in,none is used to target only packets that was encrypted and normally a more specific than none is is used but to also handle WireGuard decrypted packets beside IKEv2 packets
The clamp-to-pmtu adapts the MTU to what the servers suggests to be used.
The manual on ipsec-policy:
ipsec-policy (in | out, ipsec | none; Default: )
Matches the policy used by IPsec. Value is written in the following format: direction, policy. The direction is Used to select whether to match the policy used for decapsulation or the policy that will be used for encapsulation.in - valid in the PREROUTING chain
out - valid in the OUTPUT chainipsec - matches if the packet is subject to IPsec processing;
none - matches packet that is not subject to IPsec processing (for example, IpSec transport packet).For example, if a router receives an IPsec encapsulated Gre packet, then the rule ipsec-policy=in,ipsec will match Gre packet, but the rule ipsec-policy=in,none will match the ESP packet.
The manual on new-mss & clamp-to-pmtu
new-mss (integer; Default: )
Sets a new MSS for a packet.Clampt-to-pmtu feature sets (DF) bit in the IP header to dynamically discover the PMTU of a path. Host sends all datagrams on that path with the DF bit set until receives ICMP
Destination Unreachable messages with a code meaning “fragmentation needed and DF set”. Upon receipt of such a message, the source host reduces its assumed PMTU for the path.
Holy ****. You solved the problem. change-mss solves the problem. Now the devices get internet connection through vpn at full speed. From me and my friends, Thank you very very much :3
So this kinda begs the question, whose fault it is that tcp packets were getting broken? VPN provider? or mikrotik? When gateway=IP it works, I’m getting thats because mikrotik can talk to that gateway ip and can set the correct mtu? When gateway=wireguard_interface_name mikrotik kinda have to blindly send packets to the tunnel so can’t know the correct mtu?
We are “fixing” tcp syn packets with that mangle rule, but would the underlying problem affect other types on packets?
Is this mangle fix the only way to address the MTU issue.
By that I mean losing fastrack for the rest of the router to solve a wireguard issue??
/ip/firewall/mangle
add action=change-mss chain=forward comment=“WireGuard & IKEv2 Sync” ipsec-policy=in,none new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn
Is there not a different way, like simply set the MTU on wireguard settings??
Sindy helped me big time in my first quest for NordVPN and having the client get the correct MTU. Sadly NordVPN do not sent aways a ICMP 4-3 back anymore since about a year.
So that does not work anymore with NordVPN.
When starting with WireGuard took the a standard way for MTU on IPSEC an found if using none it would also handle wireguard.
There is no side here doing it wrong. This line adapts to what the server uses as MTU and that depends on what packet size being available to them.
Glad that it works also for others. You go from a bumpy road surfing to a smooth ride and pages just fly in.
Fastracking in a VPN tunnel…rule one in the manual explains that is not wise. Please explain then, why the router looses the ability to fasttrack none VPN traffic?
The MTU fixed is nice if you known what the MTU is used on the other side. The subject of this thread states NordVPN so the MTU of the webserver visited is unknown.
Wireshark sniff of traffic does not show MTU other side uses ?? no way to find out??