Hello,
Has anyone here set up a router (mine is hEX S) to work as a Wireguard VPN client towards Mullvad service (https://mullvad.net) and could give me a helping hand how to configure such setup, please?
BR,
Mike
You have to perform the following steps:
- create a new WireGuard interface using the private key from the downloaded config file
- add the peer configuration from the downloaded config file
- add the “Address” of the downloaded config file to the WireGuard interface in /ip/address with a mask of /32
- add a route for all traffic you want to route over the VPN, setting the name of the WireGuard interface as gateway
- Set the DNS server from the config file for the clients properly to avoid leaks, e.g. by distributing it via DHCP
- Create a Firewall masquerade rule to NAT all traffic coming out of the WireGuard interface
In my case I created a separate VLAN which routes all traffic via VPN using a separate routing table and a routing rule.
Hi moaiddip
Some examples from my mullvad setup, hope this helps you out!
My use case:
vlan3 uses policy routing to route all traffic on that vlan via mullvad:
I think this is the full config, if you see a missing part let me know
Summary:
Configure interface for wireguard and peer setup.
Configure VRF
Configure Interface Group
Configure NAT
Configure Route rule for VRF (vlan 3 in my case lookup route via table mullvad)
configure default route for table vrf_mullvad
/interface wireguard
add comment=Mullvad listen-port=44875 mtu=1420 name=wg3 private-key="******************"
/interface wireguard peers
add allowed-address=0.0.0.0/0 comment=Mullvad endpoint-address=************** endpoint-port=51820 interface=wg3 public-key="*******************"
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=wg3 pref-src="" routing-table=vrf_mullvad scope=30 suppress-hw-offload=no target-scope=10
/ip vrf
add list=vrf_mullvad name=vrf_mullvad
/interface list member
add interface=2_vlan3 list=vrf_mullvad
add interface=wg3 list=vrf_mullvad
/ip firewall nat
add action=masquerade chain=srcnat comment="Mullvad NAT" ipsec-policy=out,none out-interface=wg3
/ip vrf
add list=vrf_mullvad name=vrf_mullvad
/routing rule
add action=lookup disabled=no interface=2_vlan3 table=vrf_mullvad
Using VRF for that is a pretty good idea aglabs. I tried to change my setup to use VRF like you do (I’m currently using a separate route table), but with beta5 WinBox crashes when I want to show/edit the routes with a VRF enabled.
I think your IP address definition may be missing from your config (in my case traffic could not be routed without ip) and the “/ip vrf” config is duplicated.
I also try do opposite, redirect all traffic via VPN, except one bridge(interface), tried with VRF but also get same problem that on beta5 WinBox crashes when I want to open IP/Routes with a VRF enabled. Look like bug. Tried via terminal but couldn’t get working NAT, maybe related to the bug. Any idea how else could I except specific interface to using Wireguard?
You could create a new routing table with your WG interface as default gateway and add a routing policy rule for each interface except your bridge. The downside compared to VRF is that you have to create a rule for each interface (I don’t know if you could create a catchall routing policy rule and have a specific rule for your bridge override it) and that there are no routes between the attached interfaces.
Thanks for useful post!
In case someone still interested - here working config using wireguard + vrf
# 2.2.2.2 - far wg endpoint address
# 172.128.1.0/31 - wg tunnel network, local - 172.128.1.0, remote - 172.128.1.1
# 192.168.129.0/24 - local LAN subnet, 192.168.129.1/24 - local LAN bridge interface
#
/interface bridge add name=bridge-vpn
/interface wireguard add listen-port=7887 mtu=1420 name=wg0 private-key="BlaBlaBla1"
/interface wireguard peers add allowed-address=0.0.0.0/0 endpoint-address=2.2.2.2 endpoint-port=7887 interface=wg0 public-key="BlaBlaBla2"
#
/ip address add address=192.168.129.1/24 interface=bridge-vpn network=192.168.129.0
/ip address add address=172.128.1.0/31 interface=wg0 network=172.128.1.0
#
/interface list add name=VPN-rm
/interface list member add interface=bridge-vpn list=VPN-rm
/interface list member add interface=wg0 list=VPN-rm
#
/ip vrf add list=VPN-rm name=VPN-rm
#
/ip route add dst-address=0.0.0.0/0 gateway=wg0@VPN-rm routing-table=VPN-rm
# The following not working in case using /31 network for wg tunnel
# http://forum.mikrotik.com/t/feature-request-31-subnet/85157/1
#/ip route add dst-address=0.0.0.0/0 gateway=172.128.1.1@VPN-rm routing-table=VPN-rm
#
/routing rule add action=lookup-only-in-table dst-address=0.0.0.0/0 interface=bridge-vpn src-address=192.168.129.0/24 table=VPN-rm
/routing rule add action=lookup-only-in-table dst-address=192.168.129.0/24 interface=wg0 src-address=0.0.0.0/0 table=VPN-rm
#
/ip firewall mangle add action=change-mss chain=postrouting new-mss=1380 out-interface=wg0 passthrough=no protocol=tcp tcp-flags=syn
/ip firewall nat add action=masquerade chain=srcnat out-interface=wg0
Br, Alexey
Thanks for sharing your config, Alexey! I am currently also setting this up and wondering why it’s necessary to create the two routing rules. I was under the impression that creating the VRF will create a separate routing table and creating the default route in that table should be enough. But it seems you went one step further and also created the lookup-only-in-table rules, which makes me think: why is the VRF needed in first place?
Assuming wireguard is already a layer 3 activity then Concur, dont see the need to add vrf??
I actually like the VRF concept. In fact, I could/should have presented my question differently: When using a VRF, why is it necessary to create extra routing rules. Shouldn’t the router just automatically pull the rules in the VRF routing table for all interfaces linked to it?
To answer my own question: I ran a few tests and in my case, creating the VRF made the router automatically choose the routes that are assigned to the VRF’s routing table. I didn’t need to create extra routing rules to point traffic to a specific routing table. This might be needed for route leaking, but not for basic routing setup.
Hi verbylab!
I can confirm the routing rules in my posted is completely redundant and hereby unneeded.
Thank you for pointing!
Hell i can’t remember why i added those )
Br, Alexey