SXT LTE route all traffic over WireGaurd VPN

RouterOS Wireless Networking
1

So I have an SXT LTE running ROS7.2 and I have a Mullvad Wiregaurd VPN. I want to setup the VPN so that I run all my traffic over it to get around my carriers app specific throttling. I have tried this with IKEv2 NordVPN, but the SXT CPU maxes out pretty quick when I try to do anything. Im hoping that Wiregaurd will be much more efficient.

Ive tried following several guides, but it just doesn’t seem to work. Can anyone point me in the right direction, or is what Im trying to do impossible?
Thank you!

2

Has anyone done something like this?

3

What you basically want to do is setup a wireguard connection and have all traffic send over it. Correct ?

See here
https://forum.mikrotik.com/viewtopic.php?t=182340

Since you want to send all traffic over the tunnel, use 0.0.0.0.0/0 as allowed addresses and provide route with 0.0.0.0/0 to wg itf.
But what will happen if that interface does not work ?
So make sure to have a fallback…

4

Correct, I want to route all traffic over the wg interface. I have been trying to follow this guide http://forum.mikrotik.com/t/v7-1beta2-development-is-released/142356/1
But when I get to the part to add a default route, it does not seem to work. See attached screenshot
Screenshot 2022-04-16 115909.png

5

Are you sure you typed the name of wireguard interface correct ?
Doesn’t look like it from that terminal screenshot.
Or is it like that ?

6

All the information is at the link Holvoetn provided, and yet you elected to go elsewhere, cant help with trying to muck about some other reference LOL

The path forward is clear for the LTE

WIREGUARD INTERFACE,
name= wireguard1
private key
public key - which you need to give to mulvad

WIREGUARD PEER
endpoint address and port - supplied by mullvad
allowed IPs: 0.0.0.0/0 ( desination addresses you wish to send (all internet) over tunnel )
keep-alive set to 35 seconds or so
public key - provided to you by mullvad

IP ADDRESS, assuming mulvad supplied you with some sort of IP for your side…??? lets say it was 10.10.10.2
/ip address
add address=10.10.10.2/24 interface=wireguard1
Firewall rules.
You need to ensure your subnet is allowed to enter the tunnel.
add chain=forward action=accept in-interface-list=LAN out-interface=wireguard1

If you only have one subnet (lets say 192.168.20.0/24) it can be in-interface=name of subnet or simply src-address=192.168.20.0/24

IP ROUTE - this is the tricky part.
You should have the default route already in place, either automatically because in IP DHCP Client you have YES selected for use ISP as default route, OR you should have created one manually.
add dst-address=0.0.0.0/0 gwy=ISP gateway table=main.

THREE STEPS
Add table
/routing table add name=useWG fib

Add routing rule
/routing rule add src-address=192.168.20.0/24 action=lookup table=useWG

Add additional route
dst-address=0.0.0.0/0 gwy=wireguard1 table=useWG

Note: lookup means use the table indicated for traffic but if the table is not available, look for another routing (which means check table=main to see if any alive routes exist and use that one).
If you had selected lookup-only-in-table, then the router would not look elsewhwere if the wg tunnel was not available and traffic would be dropped.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

make the necessary changes and then post your config here
/export file=anynameyouwish

7

Thank you so much for all the help guys, I got it! Also yes, spelling wireguard correctly helped :open_mouth:

8

For anyone wondering, you also have to masquerade your traffic like this. Or at least I had to.

ip/firewall/nat/add chain=srcnat out-interface=wireguard1 action=masquerade

9

This is the way.

10

Most interesting… I wonder why you need source-nat through wireguard??
There is no need to source NAT private IPs on your subnet, they do not point to location etc…

Sorry my bad, I keep forgetting that third party providers are HORRIBLE servers LOL, they give you a single IP and from their perspective,
they send all traffic back to that single IP and source info is lost.
Thus the MT router has to sourcenat each private IP first to the assigned wireguard IP and is thus able to unsource nat on the return…


In any case I am suggesting two options.
masquerade out-interface=ether1
masquerade out-interface=wireguard

OR
masquerade out-interface-list=WAN
where
/interface list memberts
add interface=ether1 list=WAN
add interface=wireguard list=WAN.

In this way, internet users on the subnet behind the router will be able to use the internet, whenever the tunnel is not working.

11

Why ?
I don’t have that on any of my wg peers, also one SXT LTE device.

12

Holvoeten, you really need to read the user Article, let me point you to the answer,

PARA 7 !!!

https://forum.mikrotik.com/viewtopic.php?p=906311#p906311

13

1- that post is a DISASTER for referencing … really unclear and chaotic. My view. In Dutch we have a saying which goes like: “A cat would lose her kittens there”
2- I still don’t see why. I do not see a difference between a third-party VPN and an own controlled Tik on the other side.

14

If you cannot find a paragraph clearly labelled then I suspect reading the paragraph will not help.
Suggest changing devices to D-stink, TP-stink, nor Net-crap. ;-PP

Seriously,
The issues is the SERVER (the third party VPN is only expecting one source for IPs coming from the client Router).
Think of it simply. The PEER Settings on the Third party VPN describing the peer (the MT device) include ALLOWED IPs= single IP address.


Put the shoe on the other foot. If I was using an iphone instead of an MT device, it would be easy because I assign the Wireguard in the interface settings this single supplied IP address.
That is the only source address the client, the iphone will send over the tunnel and the only source IP the 3rd Party VPN will see…

However, when I set the MT router as a client, I will be sending MANY private IPs over the tunnel, the entire subnet will have access !!!
BUT, the wireguard THIRD PARTY SERVER is only expecting one, and thus at their end all the traffic will get dropped!!.

OR not sure how they do it, lets say they changed all the incoming IPs to the single IP, not a source nat but a modification.
Then all the returning traffic will have a single source IP, none of which match any of the private users on teh originating subnet.

In either case the solution is to sourcenat all the private IPs to the assigned IP from the third party provider.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From a router to router perspective, You tell the server MT router, via allowed IPs, hey you can expect this entire subnet to be coming out of the tunnel at your end (by its peer settings for allowed IPs) and thus all this traffic is permitted whereas, if it showed up on a third party vpn expecting only one source IP, it would be dropped