0% found this document useful (0 votes)
169 views

WireGuard - RouterOS - MikroTik Documentation

Hhh

Uploaded by

Aton 693
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
169 views

WireGuard - RouterOS - MikroTik Documentation

Hhh

Uploaded by

Aton 693
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

 Spaces   Search  Log in

Pages / RouterOS / Virtual Private Networks 


RouterOS

WireGuard
Property Description
Pages

Blog
Introduction

PAGE TREE
Introduction
Properties
 Getting started
Read-only properties
 Authentication, Authorization, Accounting
 Bridging and Switching
Peers
 Diagnostics, monitoring and troubleshooting
Read-only properties
 Extended features Application examples
 Firewall and Quality of Service Site to Site WireGuard tunnel
 Hardware WireGuard interface configuration
 High Availability Solutions Peer configuration
 Internet of Things IP and routing configuration
 IPv4 and IPv6 Fundamentals Firewall considerations
 Management tools RoadWarrior WireGuard tunnel
 Mobile Networking RouterOS configuration
 Network Management iOS configuration
 Routing
WireGuard® is an extremely simple yet fast and modern VPN
 Multi Protocol Label Switching (MPLS)
that utilizes state-of-the-art cryptography. It aims to be
 System Information and Utilities
faster, simpler, leaner, and more useful than IPsec while
 Virtual Private Networks
avoiding massive headaches. It intends to be considerably
6to4
more performant than OpenVPN. WireGuard is designed as
EoIP

GRE
a general-purpose VPN for running on embedded interfaces
IPIP
and super computers alike, fit for many different
circumstances. Initially released for the Linux kernel, it is
 IPsec
now cross-platform (Windows, macOS, BSD, iOS, Android)
 L2TP
OpenVPN and widely deployable.
 PPPoE
PPTP Properties
SSTP Property Description
WireGuard
comment Short description of the tunnel.
ZeroTier (string;
Default: )
 Wired Connections
 Wireless disabled Enables/disables the tunnel.
(yes | no;
Default: no)

listen-port Port for WireGuard service to listen on for incoming


(integer;
sessions.
Default:
13231)

mtu Layer3 Maximum transmission unit.


(integer
[0..65536];
Default:
1420)

name Name of the tunnel.


(string;
Default: )

private-key A base64 private key. If not specified, it will be


(string;
automatically generated upon interface creation.
Default: )

Read-only properties
Property Description
public-key A base64 public key is calculated from the private key.
(string)

running Whether the interface is running.


(yes | no)

Peers
Property Description
allowed-address List of IP (v4 or v6) addresses with CIDR masks
(IP/IPv6 prefix;
from which incoming traffic for this peer is allowed
Default: )
and to which outgoing traffic for this peer is
directed. The catch-all 0.0.0.0/0 may be specified
for matching all IPv4 addresses, and ::/0 may be
specified for matching all IPv6 addresses.
comment (string; Short description of the peer.
Default: )

disabled (yes | Enables/disables the peer.


no; Default: no)

endpoint- An endpoint IP or hostname can be left blank to


address
allow remote connection from any address.
(IP/Hostname;
Default: )

endpoint-port An endpoint port can be left blank to allow remote


(integer:0..65535;
connection from any port.
Default: )

interface (string; Name of the WireGuard interface the peer belongs


Default: )
to.
persistent- A seconds interval, between 1 and 65535 inclusive,
keepalive
of how often to send an authenticated empty
(integer:0..65535;
Default: 0) packet to the peer for the purpose of keeping a
stateful firewall or NAT mapping valid persistently.
For example, if the interface very rarely sends
traffic, but it might at anytime receive traffic from a
peer, and it is behind NAT, the interface might
benefit from having a persistent keepalive interval
of 25 seconds.
preshared-key A base64 preshared key. Optional, and may be
(string; Default: )
omitted. This option adds an additional layer of
symmetric-key cryptography to be mixed into the
already existing public-key cryptography, for post-
quantum resistance.
public-key The remote peer's calculated public key.
(string; Default: )

Read-only properties
Property Description

current- The most recent source IP address of correctly


endpoint-
authenticated packets from the peer.
address
(IP/IPv6)

current- The most recent source IP port of correctly


endpoint-
authenticated packets from the peer.
port
(integer)

last- Time in seconds after the last successful handshake.


handshake
(integer)

rx (integer) The total amount of bytes received from the peer.


tx (integer) The total amount of bytes transmitted to the peer.

Application examples
Site to Site WireGuard tunnel
Consider setup as illustrated below. Two remote office
routers are connected to the internet and office
workstations are behind NAT. Each office has its own local
subnet, 10.1.202.0/24 for Office1 and 10.1.101.0/24 for
Office2. Both remote offices need secure tunnels to local
networks behind routers.

WireGuard interface configuration


First of all, WireGuard interfaces must be configured on
both sites to allow automatic private and public key
generation. The command is the same for both routers:

/interface/wireguard
add listen-port=13231 name=wireguard1

Now when printing the interface details, both private and


public keys should be visible to allow an exchange.

 Any private key will never be needed on the remote


side device - hence the name private.

Office1

/interface/wireguard print
Flags: X - disabled; R - running
0 R name="wireguard1" mtu=1420 listen-port=13231 p
public-key="u7gYAg5tkioJDcm3hyS7pm79eADKPs/ZU

Office2

/interface/wireguard/print
Flags: X - disabled; R - running
0 R name="wireguard1" mtu=1420 listen-port=13231 p
public-key="v/oIzPyFm1FPHrqhytZgsKjU7mUToQHLr

Peer configuration
Peer configuration defines who can use the WireGuard
interface and what kind of traffic can be sent over it. To
identify the remote peer, its public key must be specified
together with the created WireGuard interface.
Office1

/interface/wireguard/peers
add allowed-address=10.1.101.0/24 endpoint-address=1
public-key="v/oIzPyFm1FPHrqhytZgsKjU7mUToQHLrW+Tb5e

Office2

/interface/wireguard/peers
add allowed-address=10.1.202.0/24 endpoint-address=1
public-key="u7gYAg5tkioJDcm3hyS7pm79eADKPs/ZUGON6/f

IP and routing configuration


Lastly, IP and routing information must be configured to
allow traffic to be sent over the tunnel.
Office1

/ip/address
add address=10.255.255.1/30 interface=wireguard1
/ip/route
add dst-address=10.1.101.0/24 gateway=wireguard1

Office2

/ip/address
add address=10.255.255.2/30 interface=wireguard1
/ip/route
add dst-address=10.1.202.0/24 gateway=wireguard1

Firewall considerations
The default RouterOS firewall will block the tunnel from
establishing properly. The traffic should be accepted in the
"input" chain before any drop rules on both sites.
Office1

/ip/firewall/filter
add action=accept chain=input dst-port=13231 protoco

Office2

/ip/firewall/filter
add action=accept chain=input dst-port=13231 protoco

Additionally, it is possible that the "forward" chain restricts


the communication between the subnets as well, so such
traffic should be accepted before any drop rules as well.
Office1

/ip/firewall/filter
add action=accept chain=forward dst-address=10.1.202
add action=accept chain=forward dst-address=10.1.101

Office2

/ip/firewall/filter
add action=accept chain=forward dst-address=10.1.101
add action=accept chain=forward dst-address=10.1.202

RoadWarrior WireGuard tunnel


RouterOS configuration
Add a new WireGuard interface and assign an IP address to
it.

/interface wireguard
add listen-port=13231 name=wireguard1
/ip address
add address=192.168.100.1/24 interface=wireguard1

Adding a new WireGuard interface will automatically


generate a pair of private and public keys. You will need to
configure the public key on your remote devices. To obtain
the public key value, simply print out the interface details.

[admin@home] > /interface wireguard print


Flags: X - disabled; R - running
0 R name="wireguard1" mtu=1420 listen-port=13231 p
public-key="VmGMh+cwPdb8//NOhuf1i1VIThypkMQrK

For the next steps, you will need to figure out the public key
of the remote device. Once you have it, add a new peer by
specifying the public key of the remote device and allowed
addresses that will be allowed over the WireGuard tunnel.

/interface wireguard peers


add allowed-address=192.168.100.2/32 interface=wireg

Firewall considerations
If you have default or strict firewall configured, you need to
allow remote device to establish the WireGuard connection
to your device.

/ip firewall filter


add action=accept chain=input comment="allow WireGua

To allow remote devices to connect to the RouterOS


services (e.g. request DNS), allow the WireGuard subnet in
input chain.

/ip firewall filter


add action=accept chain=input comment="allow WireGua

Or simply add the WireGuard interface to "LAN" interface


list.

/interface list member


add interface=wireguard1 list=LAN

iOS configuration
Download the WireGuard application from the App Store.
Open it up and create a new configuration from scratch.

First of all give your connection a "Name" and choose to


generate a keypair. The generated public key is necessary
for peer's configuration on RouterOS side.

Specify an IP address in "Addresses" field that is in the


same subnet as configured on the server side. This address
will be used for communication. For this example, we used
192.168.100.1/24 on the RouterOS side, you can use
192.168.100.2 here.
If necessary, configure the DNS servers. If allow-remote-
requests is set to yes under IP/DNS section on the RouterOS
side, you can specify the remote WireGuard IP address
here.

Click "Add peer" which reveals more parameters.


The "Public key" value is the public key value that is
generated on the WireGuard interface on RouterOS side.
"Endpoint" is the IP or DNS with port number of the
RouterOS device that the iOS device can communicate with
over the Internet.
"Allowed IPs" are set to 0.0.0.0/0 to allow all traffic to be
sent over the WireGuard tunnel.

No labels

Powered by Atlassian Confluence 7.20.2 · Report a bug · Atlassian News

You might also like