Mikrotik - VPN

Contents
Articles
Manual:Interface/VLAN 1
Manual:IP/IPsec 7
Manual:Interface/EoIP 29
Manual:Interface/Gre 32
Manual:Interface/IPIP 34
Manual:Interface/PPP 36
Manual:Interface/PPPoE 38
Manual:Interface/PPTP 50
Manual:Interface/L2TP 56
Manual:Interface/SSTP 63
Manual:Interface/OVPN 73
Manual:BCP bridging (PPP tunnel bridging) 76
Manual:MLPPP over single and multiple links 84
Manual:Interface/VPLS 86
References
Article Sources and Contributors 90
Image Sources, Licenses and Contributors 91
Manual:Interface/VLAN
Applies to RouterOS: v3, v4+
Summary
Sub-menu: /interface vlan
Standards: IEEE 802.1Q [1]
Virtual Local Area Network (VLAN) is layer 2 method that allows you to have multiple Virtual LANs on a single
physical interface (ethernet, wireless, etc.), giving the ability to segregate LANs efficiently.
You can use MikroTik RouterOS (as well as Cisco IOS, Linux and other router systems) to mark these packets as
well as to accept and route marked ones.
As VLAN works on OSI Layer 2, it can be used just as any other network interface without any restrictions. VLAN
successfully passes through regular Ethernet bridges.
You can also transport VLANs over wireless links and put multiple VLAN interfaces on a single wireless interface.
Note that as VLAN is not a full tunnel protocol (i.e., it does not have additional fields to transport MAC addresses of
sender and recipient), the same limitation applies to bridging over VLAN as to bridging plain wireless interfaces. In
other words, while wireless clients may participate in VLANs put on wireless interfaces, it is not possible to have
VLAN put on a wireless interface in station mode bridged with any other interface.
802.1Q
The most commonly used protocol for Virtual LANs (VLANs) is IEEE 802.1Q. It is standardized encapsulation
protocol that defines how to insert a four-byte VLAN identifier into Ethernet header. (see Figure 12.1.)
Each VLAN is treated as separate subnet. It means that, by default, host in specific VLAN cannot communicate with
host that is member of another VLAN, although they are connected in the same switch. So if you want inter-VLAN
communication you need a router. RouterOS supports up to 4095 VLAN interfaces, each with a unique VLAN ID,
per interface. VLAN priorites may also be used and manipulated.
When the VLAN extends over more than one switch, the inter-switch link have to become trunk, where packets are
tagged to indicate which VLAN they belong to. A trunk carries the traffic of multiple VLANs, it is like a
point-to-point link that carries tagged packets between switches or between a switch and router.
Q-in-Q
Original 802.1Q allows only one vlan header, Q-in-Q in the other hand allows two or more vlan headers. In
RouterOS Q-in-Q can be configured by adding one vlan interface over another. Example:
/interface vlan
add name=vlan1 vlan-id=11 interface=ether1
add name=vlan2 vlan-id=12 interface=vlan1
If any packet is sent over "vlan2" interface, two vlan tags will be added to ethernet header - "11" and "12".
Properties
Property Description
arp (disabled | enabled | proxy-arp | reply-only; Address Resolution Protocol mode

Default: enabled)
interface (name; Default: ) Name of physical interface on top of which VLAN will work
l2mtu (integer; Default: ) Layer2 MTU. For VLANS this value is not configurable. Read more>>
mtu (integer; Default: 1500) Layer3 Maximum transmission unit
name (string; Default: ) Interface name
use-service-tag (yes | no; Default: ) 802.1ad compatible Service Tag
vlan-id (integer: 4095; Default: 1) Virtual LAN identifier or tag that is used to distinguish VLANs. Must be equal for all
computers that belong to the same VLAN.
Note: MTU should be set to 1500 bytes as on Ethernet interfaces. But this may not work with some Ethernet
cards that do not support receiving/transmitting of full size Ethernet packets with VLAN header added (1500
bytes data + 4 bytes VLAN header + 14 bytes Ethernet header). In this situation MTU 1496 can be used, but
note that this will cause packet fragmentation if larger packets have to be sent over interface. At the same
time remember that MTU 1496 may cause problems if path MTU discovery is not working properly between
source and destination.
Setup examples
Simple Example
Lets assume that we have several MikroTik routers connected to a hub. Remember that hub is OSI physical layer
device (if there is a hub between routers, then from L3 point of view it is the same as Ethernet cable connection
between them). For simplification assume that all routers are connected to the hub using ether1 interface and has
assigned IP addresses as illustrated in figure below. Then on each of them the VLAN interface should be created.
Configuration for R2 and R4 is shown below:

R2:
[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no
[admin@MikroTik] /interface vlan> print

Flags: X - disabled, R - running, S - slave
# NAME MTU ARP VLAN-ID INTERFACE
0 R VLAN2 1500 enabled 2 ether1
R4:
[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no
[admin@MikroTik] /interface vlan> print

Flags: X - disabled, R - running, S - slave
# NAME MTU ARP VLAN-ID INTERFACE
0 R VLAN2 1500 enabled 2 ether1
The next step is to assign IP addresses to the VLAN interfaces.

R2:
[admin@MikroTik] ip address> add address=10.10.10.3/24 interface=VLAN2

[admin@MikroTik] ip address> print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
0 10.0.1.4/24 10.0.1.0 10.0.1.255 ether1
1 10.20.0.1/24 10.20.0.0 10.20.0.255 pc1
2 10.10.10.3/24 10.10.10.0 10.10.10.255 vlan2
[admin@MikroTik] ip address>
R4:
[admin@MikroTik] ip address> add address=10.10.10.5/24 interface=VLAN2

[admin@MikroTik] ip address> print
0 10.0.1.5/24 10.0.1.0 10.0.1.255 ether1
1 10.30.0.1/24 10.30.0.0 10.30.0.255 pc2
2 10.10.10.5/24 10.10.10.0 10.10.10.255 vlan2
[admin@MikroTik] ip address>
At this point it should be possible to ping router R4 from router R2 and vice versa:
'''Ping from R2 to R4:'''
[admin@MikroTik] ip address> /ping 10.10.10.5
10.10.10.5 64 byte ping: ttl=255 time=4 ms
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1/2.5/4 ms
'''From R4 to R2:'''

To make sure if VLAN setup is working properly, try to ping R1 from R2. If pings are timing out then VLANs are
successfully isolated.
'''From R2 to R1:'''

10.10.10.2 ping timeout
10.10.10.2 ping timeout
Create trunks and implement routing between VLANs

If separate VLANs are implemented on a switch, then router is required to provide communication between VLANs.
Switch works at OSI layer 2 so it uses only Ethernet header to forward and does not check IP header. For this reason
we must use the router that is working as a gateway for each VLAN. Without a router host is unable to communicate
outside its own VLAN. Routing process between VLANs described above is called inter-VLAN communication.
To illustrate inter-VLAN communication, we will create a trunk that will carry traffic from three VLANs (VLAN2
and VLAN3, VLAN4) across a single link between Mikrotik router and a manageable switch that supports VLAN
trunking.
Each VLAN has its own separate subnet (broadcast domain) as we see in figure above:
VLAN 2 10.10.20.0/24;
VLAN 3 10.10.30.0/24;
VLAN 4 10.10.40.0./24.
VLAN configuration on most of switches is straightforward, basically we need to define which ports are members of
VLAN and define "trunk" port that can carry tagged frames between switch and router.
Configuration example on MikroTik router:
Create VLAN interfaces:
/interface vlan
add name=VLAN2 vlan-id=2 interface=ether1 disabled=no
Add IP addresses to VLANs:
/ip address
add address=10.10.20.1/24 interface=VLAN2
RouterOS /32 and IP unnumbered addresses

In RouterOS to create point-to-point tunnel with addresses you have to use address with network mask /32 that
effectively brings you same features as some vendors unnumbered IP address.
There are 2 routers RouterA and RouterB that each is part of networks 10.22.0.0/24 and 10.23.0.0/24 respectively, to
connect these router using VLAN as carrier with the following configuration:
RouterA:
/ip address add address=10.22.0.1/24 interface=ether1

/interface vlan add interface=ether2 vlan-id=1 name=vlan1
/ip address add address=10.22.0.1/32 interface=vlan1 network=10.23.0.1
/ip route add gateway=10.23.0.1 dst-address=10.23.0.0/24
RouterB:
/ip address add address=10.23.0.1/24 interface=ether1

/interface vlan add interface=ether2 vlan-id=1 name=vlan1
/ip address add address=10.23.0.1/32 interface=vlan1 network=10.22.0.1
/ip route add gateway=10.22.0.1 dst-address=10.22.0.0/24
[ Top | Back to Content ]
References
[1] http:/ / standards. ieee. org/ getieee802/ download/ 802. 1Q-1998. pdf
Manual:IP/IPsec 7
Manual:IP/IPsec
Applies to RouterOS: v6.0 +
Summary
Sub-menu: /ip ipsec
Package required: security
Standards: RFC 4301
Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to
secure packet exchange over unprotected IP/IPv6 networks such as Internet.
IpSec protocol suite can be divided in following groups:
Authentication Header (AH) RFC 4302
Encapsulating Security Payload (ESP) RFC 4303
Internet Key Exchange (IKE) protocols. Dynamically generates and distributes cryptographic keys for AH and
ESP.
Authentication Header (AH)

AH is a protocol that provides authentication of either all or part of the contents of a datagram through the addition
of a header that is calculated based on the values in the datagram. What parts of the datagram are used for the
calculation, and the placement of the header, depends whether tunnel or transport mode is used.
The presence of the AH header allows to verify the integrity of the message, but doesn't encrypt it. Thus, AH
provides authentication but not privacy (Another protocol ESP is used to provide encryption).
RouterOS supports the following authentication algorithms for AH:
SHA1
MD5
Transport mode
In transport mode AH header is inserted after IP header. IP data and header is used to calculate authentication value.
IP fields that might change during transit, like TTL and hop count, are set to zero values before authentication.
Tunnel mode
In tunnel mode original IP packet is encapsulated within a new IP packet. All of the original IP packet is
authenticated.
Encapsulating Security Payload

Encapsulating Security Payload (ESP) uses shared key encryption to provide data privacy. ESP also supports its own
authentication scheme like that used in AH, or can be used in conjunction with AH.
ESP packages its fields in a very different way than AH. Instead of having just a header, it divides its fields into
three components:
Manual:IP/IPsec 8
ESP Header - Comes before the encrypted data and its placement depends on whether ESP is used in transport
mode or tunnel mode.
ESP Trailer - This section is placed after the encrypted data. It contains padding that is used to align the
encrypted data.
ESP Authentication Data - This field contains an Integrity Check Value (ICV), computed in a manner similar to
how the AH protocol works, for when ESP's optional authentication feature is used.
Transport mode
In transport mode ESP header is inserted after original IP header. ESP trailer and authentication value is added to the
end of the packet. In this mode only IP payload is encrypted and authenticated, IP header is not secured.
Tunnel mode
In tunnel mode original IP packet is encapsulated within a new IP packet thus securing IP payload and IP header.
Encryption algorithms
RouterOS ESP supports various encryption and authentication algorithms.
Authentication:
SHA1
MD5
Encryption:
DES - 56-bit DES-CBC encryption algorithm;
3DES - 168-bit DES encryption algorithm;
AES - 128, 192 and 256-bit key AES-CBC encryption algorithm;
Blowfish - added since v4.5
Twofish - added since v4.5
Camellia - 128, 192 and 256-bit key Camellia encryption algorithm added since v4.5
Hardware encryption
Hardware encryption allows to do faster encryption process by using built-in encryption engine inside CPU. AES is
the only algorithm that will be accelerated in hardware.
List of RouterBoards with enabled hardware support:
RB1000
RB1100AHx2
For comparison RB1000 with enabled HW support can forward up to 550Mbps encrypted traffic. When HW support
is disabled it can forward only 150Mbps encrypted traffic in AES-128 mode.
Some configuration advices on how to get maximum ipsec throughput on multicore RB1100AHx2:
Avoid using ether12 and ethet13. Since these prots are pci-x they will be slowest ones.
Fastest forwarding is from switch chip ports (ether1-ether10) to ether11 (directly connected to CPU) and vice
versa.
Set hardware queue on all interfaces
/queue interface set [find] queue=only-hardware-queue
Disable RPS:
/system resource irq rps disable [find]

Manual:IP/IPsec 9
Assign one CPU core to ether11 and other CPU core to everything else. Forwarding over ether11 requires more
CPU that is why we are giving one core only for that interface (in IRQ setting ether11 is listed as ether12 tx,rx
and error).
/system resource irq

set [find] cpu=1
set [find users="eth12 tx"] cpu=0
set [find users="eth12 rx"] cpu=0
set [find users="eth12 error"] cpu=0
disable connection tracking

With all above recommendations it is possible to forward 820Mbps (1470byte packets two streams).
With enabled connection tracking 700Mbps (1470 byte packets two streams).
Internet Key Exchange Protocol

The Internet Key Exchange (IKE) is a protocol that provides authenticated keying material for Internet Security
Association and Key Management Protocol (ISAKMP) framework. There are other key exchange schemes that work
with ISAKMP, but IKE is the most widely used one. Together they provide means for authentication of hosts and
automatic management of security associations (SA).
Most of the time IKE daemon is doing nothing. There are two possible situations when it is activated:
There is some traffic caught by a policy rule which needs to become encrypted or authenticated, but the policy
doesn't have any SAs. The policy notifies IKE daemon about that, and IKE daemon initiates connection to remote
host. IKE daemon responds to remote connection. In both cases, peers establish connection and execute 2 phases:
Phase 1 - The peers agree upon algorithms they will use in the following IKE messages and authenticate. The
keying material used to derive keys for all SAs and to protect following ISAKMP exchanges between hosts is
generated also. This phase should match following settings:
authentication method
DH group
encryption algorithm
exchange mode
hash alorithm
NAT-T
DPD and lifetime (optional)
Phase 2 - The peers establish one or more SAs that will be used by IPsec to encrypt data. All SAs established by
IKE daemon will have lifetime values (either limiting time, after which SA will become invalid, or amount of
data that can be encrypted by this SA, or both). This phase should match following settings:
Ipsec protocol
mode (tunnel or transport)
authentication method
PFS (DH) group
lifetime
Manual:IP/IPsec 10
Note: There are two lifetime values - soft and hard. When SA reaches it's soft lifetime treshold, the IKE
daemon receives a notice and starts another phase 2 exchange to replace this SA with fresh one. If SA reaches
hard lifetime, it is discarded.
Warning: Phase 1 is not re-keyed if DPD is disabled when lifetime expires, only phase 2 is re-keyed. To
force phase 1 re-key, enable DPD.
IKE can optionally provide a Perfect Forward Secrecy (PFS), which is a property of key
exchanges, that, in turn, means for IKE that compromising the long term phase 1 key will not
allow to easily gain access to all IPsec data that is protected by SAs established through this phase
1. It means an additional keying material is generated for each phase 2.
Generation of keying material is computationally very expensive. Exempli gratia, the use of modp8192 group can
take several seconds even on very fast computer. It usually takes place once per phase 1 exchange, which happens
only once between any host pair and then is kept for long time. PFS adds this expensive operation also to each phase
2 exchange.
Diffie-Hellman Groups
Diffie-Hellman (DH) key exchange protocol allows two parties without any initial shared secret to create one
securely. The following Modular Exponential (MODP) and Elliptic Curve (EC2N) Diffie-Hellman (also known as
"Oakley") Groups are supported:
Diffie-Hellman Group Name Reference
Group 1 768 bit MODP group RFC 2409
Group 2 1024 bits MODP group RFC 2409
Group 3 EC2N group on GP(2^155) RFC 2409
Group 4 EC2N group on GP(2^185) RFC 2409
Group 5 1536 bits MODP group RFC 3526
IKE Traffic
To avoid problems with IKE packets hit some SPD rule and require to encrypt it with not yet established SA (that
this packet perhaps is trying to establish), locally originated packets with UDP source port 500 are not processed
with SPD. The same way packets with UDP destination port 500 that are to be delivered locally are not processed in
incoming policy check.
Setup Procedure
To get IPsec to work with automatic keying using IKE-ISAKMP you will have to configure policy, peer and
proposal (optional) entries.
Warning: Ipsec is very sensitive to time changes. If both ends of the IpSec tunnel are not synchronizing time
equally(for example, different NTP servers not updating time with the same timestamp), tunnels will break
and will have to be established again.
Manual:IP/IPsec 11
Mode Config
Sub-menu: /ip ipsec mode-cfg
Note: If RouterOS client is initiator, it will always send CISCO UNITY extension, and RouterOS supports
only split-include from this extension.
address-pool (none | string; Default: ) Name of the address pool from which responder will try to assign address if mode-cfg is enabled.
address-prefix-length (integer Prefix length (netmask) of assigned address from the pool.
[1..32]; Default: )
comment (string; Default: )
name (string; Default: )
split-include (list of ip prefix; Default: ) List of subnets in CIDR format, which will be sent to the peer using CISCO UNITY extension,
remote peer will create dynamic policy for these subnets.
Peer configuration
Sub-menu: /ip ipsec peer
Peer configuration settings are used to establish connections between IKE daemons ( phase 1 configuration). This
connection then will be used to negotiate keys and algorithms for SAs.
Starting from v6rc12 responder side now uses initiator exchange type for peer config selection. It means that you can
configure multiple ipsec peers with the same address but different exchange modes or encryption methods.
Note: exchange modes main and l2tp-main are treated the same, so these modes cannot be used select config
between multiple peers.
address (IP/IPv6 Prefix; Default: 0.0.0.0/0) If remote peer's address matches this prefix, then the peer configuration is used in authentication
and establishment of Phase 1. If several peer's addresses match several configuration entries, the
most specific one (i.e. the one with largest netmask) will be used.
auth-method (pre-shared-key | Authentication method:

rsa-signature; Default: pre-shared-key) pre-shared-key - authenticate by a password (secret) string shared between the peers
rsa-signature - authenticate using a pair of RSA certificates
rsa-key - authenticate using a RSA key imported in Ipsec key menu.
pre-shared-key-xauth - mutual PSK authentication + xauth username/password.
passive parameter identifies server/client side
rsa-signature-hybrid - responder certificate authentication with initiator Xauth.
passive parameter identifies server/client side
certificate (string; Default: ) Name of a certificate listed in certificate table (signing packets; the certificate must have private
key). Applicable if RSA signature authentication method (auth-method=rsa-signature) is used.
comment (string; Default: ) Short description of the peer.

Manual:IP/IPsec 12
dh-group (ec2n155 | ec2n185 | modp1024 | Diffie-Hellman group (cipher strength)

modp1536 | modp2048 | modp3072 |
modp4096 | modp6144 | modp768; Default:
modp1024)
disabled (yes | no; Default: no) Whether peer is used to match remote peer's prefix.
dpd-interval (time | disable-dpd; Default: Dead peer detection interval. If set to disable-dpd, dead peer detection will not be used.
2m)
dpd-maximum-failures (integer: 1..100; Maximum count of failures until peer is considered to be dead. Applicable if DPD is enabled.
Default: 5)
enc-algorithm (3des | aes-128 | aes-192 | Encryption algorithm.

aes-256 | blowfish | camellia-128 |
camellia-192 | camellia-256 | des; Default:
aes-128)
exchange-mode (aggressive | base | main | Different ISAKMP phase 1 exchange modes according to RFC 2408. Do not use other modes then
main-l2tp; Default: main) main unless you know what you are doing. main-l2tp mode relaxes rfc2409 section 5.4, to allow
pre-shared-key authentication in main mode.
generate-policy (no | port-override | Allow this peer to establish SA for non-existing policies. Such policies are created dynamically
port-strict; Default: no) for the lifetime of SA. Automatic policies allows, for example, to create IPsec secured L2TP
tunnels, or any other setup where remote peer's IP address is not known at the configuration time.
no - do not generate policies
port-override -- generate policies and force policy to use any port (old behavior)
port-strict -- use ports from peer's proposal, which should match peer's policy
hash-algorithm (md5 | sha1 | sha256 | Hashing algorithm. SHA (Secure Hash Algorithm) is stronger, but slower.
sha512; Default: sha1)
key (string; Default: ) Name of the key from key menu. Applicable if auth-method=rsa-key.
lifebytes (Integer: 0..4294967295; Phase 1 lifetime: specifies how much bytes can be transferred before SA is discarded. If set to 0,
Default: 0) SA will not be discarded due to byte count excess.
lifetime (time; Default: 1d) Phase 1 lifetime: specifies how long the SA will be valid.
mode-cfg (none | string; Default: none) Name of the mode config parameters from mode-cfg menu. When parameter is set mode-cfg is
enabled.
initiator peer on phase1 will send mode-cfg request and will set assigned IP address and DNS.
responder will assign ip address if address-pool is specified, will send also DNS server
addresses and split-include subnets (if defined).
my-id-user-fqdn (string; Default: ) By default IP address is used as ID. This parameter replaces ID with specified value. Can be used,
for example, in cases if DNS name as ID is required.
nat-traversal (yes | no; Default: no) Use Linux NAT-T mechanism to solve IPsec incompatibility with NAT routers inbetween IPsec
peers. This can only be used with ESP protocol (AH is not supported by design, as it signs the
complete packet, including IP header, which is changed by NAT, rendering AH signature invalid).
The method encapsulates IPsec ESP traffic into UDP streams in order to overcome some minor
issues that made ESP incompatible with NAT.
passive (yes | no; Default: no) When passive mode is enabled will wait for remote peer to initiate IKE connection. Enabled
passive mode also indicates that peer is xauth responder, and disabled passive mode - xauth
initiator.
policy-group (none | string; Default: ) If generate-policy is enabled, responder checks against templates from the same group. If none of
the templates match, Phase2 SA will not be established.
port (integer:0..65535; Default: 500) Communication port used for ipsec traffic.
Manual:IP/IPsec 13
proposal-check (claim | exact | obey | Phase 2 lifetime check logic:

strict; Default: obey) claim - take shortest of proposed and configured lifetimes and notify initiator about it
exact - require lifetimes to be the same
obey - accept whatever is sent by an initiator
strict - if proposed lifetime is longer than the default then reject proposal otherwise accept
proposed lifetime
remote-certificate (string; Default: ) Name of a certificate (listed in certificate table) for authenticating the remote side (validating
packets; no private key required). Applicable if RSA signature authentication method is used. If
remote-certificate is not specified then received certificate from remote peer is used and checked
against CA in certificate store. Proper CA must be imported in certificate store.
secret (string; Default: ) Secret string (in case pre-shared key authentication is used). If it starts with '0x', it is parsed as a
hexadecimal value
send-initial-contact (yes | no; Specifies whether to send "initial contact" IKE packet or wait for remote side, this packet should
Default: yes) trigger removal of old peer SAs for current source address. Usually in road warrior setups clients
are initiators and this parameter should be set to no.
xauth-login (string; Default: ) initiator (client) XAuth username
xauth-password (string; Default: ) initiator (client) XAuth password
Note: IPSec phases information is erased, when /ip ipsec peer configuration is modified on the fly, however
packets are being encrypted/decrypted because of installed-sa (for example remote-peers information is
erased, when peer configuration is modified.
Keys
Sub-menu: /ip ipsec key
This submenu list all imported public/private keys, that can be used for peer authentication. Submenu also has
several commands to work with keys.
For example print below shows two imported 1024-bit keys, one public and one private.
[admin@PoETik] /ip ipsec key> print

Flags: P - private-key, R - rsa
# NAME KEY-SIZE
0 PR priv 1024-bit
1 R pub 1024-bit
Commands
Manual:IP/IPsec 14
export-pub-key (file-name; Export public key to file from one of existing private keys.
key)
generate-key (key-size; name) Generate private key. Takes two parameters, name of newly generated key and key size 1024,2048 and
4096.
import (file-name; name) Import key from file.
Policy
Sub-menu: /ip ipsec policy
Policy table is used to determine whether security settings should be applied to a packet.
action (discard | encrypt | none; Default: Specifies what to do with packet matched by the policy.
encrypt) none - pass the packet unchanged
discard - drop the packet
encrypt - apply transformations specified in this policy and it's SA
comment (string; Default: ) Short description of the policy
disabled (yes | no; Default: no) Whether policy is used to match packets.
dst-address (IP/IPv6 prefix; Default: Destination address to be matched in packets.

0.0.0.0/32)
dst-port (integer:0..65535 | any; Default: any) Destination port to be matched in packets. If set to any all ports will be matched
group (string; Default: default) Name of the policy group to which this template is assigned.
ipsec-protocols (ah | esp; Default: esp) Specifies what combination of Authentication Header and Encapsulating Security Payload
protocols you want to apply to matched traffic
level (require | unique | use; Default: require) Specifies what to do if some of the SAs for this policy cannot be found:
use - skip this transform, do not drop packet and do not acquire SA from IKE daemon
require - drop packet and acquire SA
unique - drop packet and acquire a unique SA that is only used with this particular
policy
manual-sa (string | none; Default: none) Name of the manual SA template
priority (integer:-2147483646..2147483647; Policy ordering classificator (signed integer). Larger number means higher priority.
Default: 0)
proposal (string; Default: default) Name of the proposal template that will be sent by IKE daemon to establish SAs for this
policy.
protocol (all | egp | ggp| icmp | igmp | ...; IP packet protocol to match.
Default: all)
sa-dst-address (ip/ipv6 address; Default: ::) SA destination IP/IPv6 address (remote peer).
sa-src-address (ip/ipv6 address; Default: ::) SA source IP/IPv6 address (local peer).
src-address (ip/ipv6 prefix; Default: Source IP prefix

0.0.0.0/32)
src-port (any | integer:0..65535; Default: any) Source Port of the packet

Manual:IP/IPsec 15
template (yes | no; Default: no) Creates a template and assigns it to specified policy group Following parameters are used by
template:
src-address, dst-address - Requested subnet must match in both directions(for example
0.0.0.0/0 to allow all)
protocol - protocol to match, if set to all, then any protocol is accepted
proposal - SA parameters used for this template.
tunnel (yes | no; Default: no) Specifies whether to use tunnel mode
Note: All packets are IPIP encapsulated in tunnel mode, and their new IP header's src-address and dst-address
are set to sa-src-address and sa-dst-address values of this policy. If you do not use tunnel mode (id est you use
transport mode), then only packets whose source and destination addresses are the same as sa-src-address and
sa-dst-address can be processed by this policy. Transport mode can only work with packets that originate at
and are destined for IPsec peers (hosts that established security associations). To encrypt traffic between
networks (or a network and a host) you have to use tunnel mode.
Policy Stats
Command /ip ipsec policy print stats will show current status of the policy. Additional read-only
parameters will be printed.
in-accepted (integer) How many incoming packets were passed by the policy without an attempt to decrypt.
in-dropped (integer) How many incoming packets were dropped by the policy without an attempt to decrypt
in-transformed (integer) How many incoming packets were decrypted (ESP) and/or verified (AH) by the policy
out-accepted (integer) How many outgoing packets were passed by the policy without an attempt to encrypt.
out-dropped (integer) How many outgoing packets were dropped by the policy without an attempt to encrypt.
out-transformed (integer) How many outgoing packets were encrypted (ESP) and/or verified (AH) by the policy.
ph2-state (expired | no-phase2 | established) Indication of the progress of key establishing.
Dumping Policies
It is possible to dump policies installed into the kernel for debugging purposes with command:
/ip ipsec policy dump-kernel-policies
After executing this command check the logs to see the result, there should be three policies in the kernel: forward,
in and out.
[admin@test-host] >/log print

07:28:34 ipsec,debug,packet policy ipsec fwd: 10.5.101.9[0] - 10.5.101.13[0]
07:28:34 ipsec,debug,packet policy ipsec in: 10.5.101.9[0] - 10.5.101.13[0]
07:28:34 ipsec,debug,packet policy ipsec out: 10.5.101.13[0] - 10.5.101.9[0]
Manual:IP/IPsec 16
Policy Groups
Sub-menu: /ip ipsec policy group
comment (string; Default: )
Proposal settings
Sub-menu: /ip ipsec proposal
Proposal information that will be sent by IKE daemon to establish SAs for this policy ( Phase 2). Configured
proposals are set in policy configuration.
auth-algorithms (md5|sha1|null|sha256|sha512; Default: sha1) Allowed

algorithms
for
authorization.
sha1 is
stronger, but
slower
algorithm.
comment (string; Default: ) Short

description
of an item.
disabled (yes | no; Default: no) Whether

item is
disabled.
enc-algorithms Allowed
(null|des|3des|aes-128-cbc|aes-128-cbc|aes-128gcm|aes-192-cbc|aes-192-ctr|aes-192-gcm|aes-256-cbc|aes-256-ctr|aes-256-gcm|blowfish|camellia-128|camellia-192|camellia-256|twofish; algorithms
Default: aes-128-cbc) and key
lengths to
use for SAs.
lifetime (time; Default: 30m) How long to

use SA
before
throwing it
out.
name (string; Default: ) Name of the

proposal
template, that
will be
identified in
other parts of
ipsec
configuration.
pfs-group (ec2n155 | ec2n185 | modp1024 | modp1536 | modp2048 | modp3072 | modp4096 | modp6144 | modp768 | none; Default: modp1024) Diffie-Helman
group used
for Perfect
Forward
Secrecy.
Manual:IP/IPsec 17
Manual SA
Sub-menu: /ip ipsec manual-sa
Menu is used to configure SAs manually. Created SA template then can be used in policy configuration.
ah-algorithm (in/out Authentication Header encryption algorithm.

in,out = md5|null|sha1; Default: null)
ah-key (string/string; Default: ) Incoming-authentication-key/outgoing-authentication-key
ah-spi (0x100..FFFFFFFF/0x100..FFFFFFFF; Default: 0x100) Incoming-SA-SPI/outgoing-SA-SPI
disabled (yes | no; Default: no) Defines whether item is ignored or used
esp-auth-algorithm (in/out Encapsulating Security Payload authentication encryption algorithm

in,out = md5|null|sha1; Default: null)
esp-auth-key (string/string; Default: ) Incoming-authentication-key/outgoing -authentication-key
esp-enc-algorithm (in/out Incoming-encryption-algorithm

in,out = 3des | aes-128 | aes-192 | aes-256 | des | ...; Default: null)
esp-enc-key (string/string; Default: ) Incoming-encryption-key/outgoing-encryption-key
esp-spi (0x100..FFFFFFFF/0x100..FFFFFFFF; Default: 0x100) Incoming-SA-SPI/outgoing-SA-SPI
lifetime (time; Default: 0s) Lifetime of this SA
name (string; Default: ) Name of the item for reference from policies
Installed SA
Sub-menu: /ip ipsec installed-sa
This facility provides information about installed security associations including the keys.
AH (yes | no)
ESP (yes | no)
add-lifetime (time/time) Added lifetime for the SA in format soft/hard

soft - time period after which ike will try to establish new SA
hard - time period after which SA is deleted
addtime (time) Date and time when this SA was added.
auth-algorithm (sha1 | md5) Shows currently used authentication algorithm
auth-key (string) Shows used authentication key
current-bytes (64-bit integer) Shows number of bytes seen by this SA.
dst-address (IP)
enc-algorithm (des | 3des | aes ...) Shows currently used encryption algorithm
pfs (yes | no)
replay (integer)
spi (string)
src-address (IP)
state (string) Shows the current state of the SA ("mature", "dying" etc)
Manual:IP/IPsec 18
Flushing SAs
Sometimes after incorrect/incomplete negotiations took place, it is required to flush manually the installed SA table
so that SA could be renegotiated. This option is provided by the /ip ipsec installed-sa flush
command.
This command accepts only one property:
sa-type (ah | all | esp; Default: all) Specifies SA types to flush:

ah - delete AH protocol SAs only
esp - delete ESP protocol SAs only
all - delete both ESP and AH protocols SAs
Remote Peers
Sub-menu: /ip ipsec remote-peers
This submenu provides you with various statistics about remote peers that currently have established phase 1
connections with this router. Note that if peer doesn't show up here, it doesn't mean that no IPsec traffic is being
exchanged with it.
Read only properties:
local-address (ip/ipv6 Local ISAKMP SA address on the router used by the peer
address)
remote-address (ip/ipv6 Remote peer's ip/ipv6 address

address)
side (initiator | responder) Shows which side initiated the Phase1 negotiation.
state (string) State of phase 1 negotiation with the peer. For example when phase1 and phase 2 are negotiated it will show
state "established".
established (time) How long peers are in established state.
Closing all IPsec connections

Menu has a command to quickly close all established ipsec connections. This command will clear all installed SAs
(Phase2) and remove all entries from remote-peers menu (Phase1).
Usage:
/ip ipsec remote-peers kill-connections
Statistics
Sub-menu: /ip ipsec statistics
This menu shows various ipsec statistics
Manual:IP/IPsec 19
in-errors (integer) All inbound errors that are not matched by other counters.
in-buffer-errors (integer) No free buffer.
in-header-errors (integer) Header error
in-no-states (integer) No state is found i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong
in-state-protocol-errors Transformation protocol specific error, for example SA key is wrong or hardware accelerator is
(integer) unable to handle amount of packets.
in-state-mode-errors (integer) Transformation mode specific error
in-state-sequence-errors Sequence number is out of window

(integer)
in-state-expired (integer) State is expired
in-state-mismatches (integer) State has mismatched option, for example UDP encapsulation type is mismatched.
in-state-invalid (integer) State is invalid
in-template-mismatches (integer) No matching template for states, e.g. Inbound SAs are correct but SP rule is wrong
in-no-policies (integer) No policy is found for states, e.g. Inbound SAs are correct but no SP is found
in-policy-blocked (integer) Policy discards
in-policy-errors (integer) Policy errors
out-errors (integer) All outbound errors that are not matched by other counters
out-bundle-errors (integer) Bundle generation error
out-bundle-check-errors (integer) Bundle check error
out-no-states (integer) No state is found
out-state-protocol-errors Transformation protocol specific error

(integer)
out-state-mode-errors (integer) Transformation mode specific error
out-state-sequence-errors Sequence errors, for example Sequence number overflow

(integer)
out-state-expired (integer) State is expired
out-policy-blocked (integer) Policy discards
out-policy-dead (integer) Policy is dead
out-policy-errors (integer) Policy error
Application Examples
Simple Mutual PSK XAuth Config

Server side config:
/ip ipsec peer

add address=2.2.2.1 auth-method=pre-shared-key-xauth secret="123" passive=yes
/ip ipsec user

add name=test password=345
Client side config:

Manual:IP/IPsec 20
/ip ipsec peer

add address=2.2.2.2 auth-method=pre-shared-key-xauth secret="123" \
xauth-login=test xauth-password=345
Note: On server side it is mandatory to set passive to yes when XAuth is used.
Road Warrior setup with Mode Conf

Consider setup where worker need to access other co-workers (workstations) and local office
server remotely. Office has two subnets:
192.168.55.0/24 for workstations
192.168.66.0/24 network that must not be reachable by RoadWarrior clients
10.5.8.0/24 for servers
And access to those networks should be secure.
Typically in RoadWarrior setups as this it is impossible to know from which address user will connect, so we need to
set up generate-policy parameter on the server side. However this leads to other problems, client can generate
any policy and access any network in the office. Even set 0.0.0.0/0 and deny internet access to office workers.
Mode Conf, policy group and policy templates will allow us to overcome these problems.
IpSec Server Config

At first we need a pool from which RoadWarrior will will get an address. Typically in office you set up DHCP
server for local workstations, the same DHCP pool can be used.
/ip pool
add name=ipsec-RW ranges=192.168.55.2-192.168.55.254
Next we need to set up what settings to send to the client using Mode Conf.
/ip ipsec mode-cfg

add address-pool=ipsec-RW name=RW-cfg split-include=\
10.5.8.0/24,192.168.55.0/24
Manual:IP/IPsec 21
As you can see we specified from which pool to give out address and two allowed subnets.
Now to allow only specific source/destination address in generated policies we will use policy group and create
policy templates:
/ip ipsec policy group

add name=RoadWarrior
/ip ipsec policy

add dst-address=192.168.55.0/24 group=RoadWarrior src-address=10.5.8.0/24 \
template=yes
add dst-address=192.168.55.0/24 group=RoadWarrior src-address=192.168.55.0/24 \
template=yes
Now we just add xauth users and peer with enabled Mode Conf and policy group.
/ip ipsec user

add name=user1 password=123
add name=user2 password=234
/ip ipsec peer

add auth-method=pre-shared-key-xauth generate-policy=port-strict mode-cfg=RW-cfg \
policy-group=RoadWarrior secret=123 passive=yes
RouterOS Client Config

/ip ipsec peer
add address=2.2.2.2 auth-method=pre-shared-key-xauth generate-policy=port-strict secret=123 \
xauth-login=user1 xauth-password=123
Shrew Client Config

n:version:2
n:network-ike-port:500
n:network-mtu-size:1380
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:0
n:client-banner-enable:0
n:network-notify-enable:0
n:client-wins-used:0
n:client-wins-auto:1
n:client-dns-used:1
n:client-dns-auto:0
n:client-splitdns-used:1
n:client-splitdns-auto:0
n:phase1-dhgroup:2
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:300
Manual:IP/IPsec 22
n:phase2-life-kbytes:0
n:policy-nailed:1
n:policy-list-auto:1
n:client-addr-auto:1
s:network-host:2.2.2.2
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:disable
s:network-frag-mode:disable
s:auth-method:mutual-psk-xauth
s:ident-client-type:address
s:ident-server-type:address
b:auth-mutual-psk:MTIz
s:phase1-exchange:main
s:phase1-cipher:3des
s:phase1-hash:md5
s:phase2-transform:esp-3des
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
s:policy-level:require
Road Warrior setup with RSA Authentication
Creating Certificates
All certificates will be created on RouterOS server using certificate manager
Make certificate templates
/certificate
add name=ca-template common-name=myCa
add name=server-template common-name=server
add name=client1-template common-name=client1
add name=client2-template common-name=client2
Now sign certificates and add CRL url. We will use IP address of the server as CRL URL.
/certificate
sign-ca template=ca-template ca-crl-host=10.5.101.16 name=myCa
sign-issued ca=myCa template=server-template name=server
sign-issued ca=myCa template=client1-template name=client1
sign-issued ca=myCa template=client2-template name=client2
Now set server and CA certificates as trusted so that we can use them
/certificate
set myCa trusted=yes
set server trusted=yes
And export client certificates with keys and ca, these will be uploaded to each client:
Manual:IP/IPsec 23
/certificate export myCa

/certificate export client1 export-passphrase=xxxxxxxx
/certificate export client2 export-passphrase=xxxxxxxx
If everything went well you should have something like this:
[admin@pe0] /certificate> print

Flags: K - private-key, D - dsa, L - crl, C - smart-card-key,
A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME FINGERPRINT
0 K L A T myCa myCa 7fa636e6576495fe78f1a4...
1 K I T server server cf0650a291bf4685f2fbd3...
2 K I client1 client1 26233de30e89b203b946ab...
3 K I client2 client2 cf172b62201befaf8d8966...
Note: Templates are automatically removed after signing certificate
Ipsec Server Config

/ip ipsec policy group
add name=test
/ip ipsec peer

add auth-method=rsa-signature certificate=server exchange-mode=main \
generate-policy=port-override passive=yes policy-group=test remote-certificate=none
/ip ipsec policy
add dst-address=172.16.1.0/24 group=test src-address=172.16.2.0/24 template=yes
Testing CRL
Now lets say client2 should not be able to connect anymore. We need to revoke its certificate so that it is excluded
from CRL list.
/certificate
issued-revoke client2
Notice R flag, which means that certificate is revoked
[admin@pe0] /certificate> print

Flags: K - private-key, D - dsa, L - crl, C - smart-card-key,
A - authority, I - issued, R - revoked, E - expired, T - trusted
# NAME COMMON-NAME FINGERPRINT
0 K L A T myCa myCa 7fa636e6576495fe78f1a4...
1 K I T server server cf0650a291bf4685f2fbd3...
2 K I client1 client1 26233de30e89b203b946ab...
3 K R client2 client2 cf172b62201befaf8d8966...
Now if you kill current connection client2 will no be able to establish phase1.
Manual:IP/IPsec 24
Site to Site IpSec Tunnel

Consider setup as illustrated below
Two remote office routers are connected to internet and office workstations behind routers are NATed. 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 needs secure
tunnel to local networks behind routers.
IP Connectivity
On both routers ether1 is used as wan port and ether2 is used to connect workstations. Also NAT rules are set tu
masquerade local networks.
Office1 router:
/ip address
add address=192.168.90.1/24 interface=ether1
/ip route
add gateway=192.168.90.254
/ip firewall nat

add chain=srcnat out-interface=ether1 action=masquerade
Office2 router:
/ip address
/ip route
add gateway=192.168.80.254
/ip firewall nat

Manual:IP/IPsec 25
add chain=srcnat out-interface=ether1 action=masquerade
IpSec Peer's config

Next step is to add peer's configuration. We need to specify peers address and port and pre-shared-key. Other
parameters are left to default values.
Office1 router:
/ip ipsec peer

add address=192.168.80.1/32 port=500 auth-method=pre-shared-key secret="test"
Office2 router:
/ip ipsec peer

add address=192.168.90.1/32 port=500 auth-method=pre-shared-key secret="test"
Policy and proposal

It is important that proposed authentication and encryption algorithms match on both routers. In this example we can
use predefined "default" proposal
[admin@MikroTik] /ip ipsec proposal> print

Flags: X - disabled
0 name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m
pfs-group=modp1024
As we already have proposal as a next step we need correct IpSec policy. We want to encrypt traffic coming form
10.1.202.0/24 to 10.1.101.0/24 and vice versa.
Office1 router:
/ip ipsec policy

add src-address=10.1.202.0/24 src-port=any dst-address=10.1.101.0/24 dst-port=any \
sa-src-address=192.168.90.1 sa-dst-address=192.168.80.1 \
tunnel=yes action=encrypt proposal=default
Office2 router:
/ip ipsec policy

add src-address=10.1.101.0/24 src-port=any dst-address=10.1.202.0/24 dst-port=any \
sa-src-address=192.168.80.1 sa-dst-address=192.168.90.1 \
tunnel=yes action=encrypt proposal=default
Note that we configured tunnel mode instead of transport, as this is site to site encryption.
Manual:IP/IPsec 26
NAT Bypass
At this point if you will try to establish IpSec tunnel it will not work, packets will be rejected. This is because both
routers have NAT rules that is changing source address after packet is encrypted. Remote router reiceves encrypted
packet but is unable to decrypt it because source address do not match address specified in policy configuration. For
more information see packet flow ipsec example.
To fix this we need to set up NAT bypass rule.
Office1 router:
/ip firewall nat

add chain=srcnat action=accept place-before=0 \
src-address=10.1.202.0/24 dst-address=10.1.101.0/24
Office2 router:
/ip firewall nat

add chain=srcnat action=accept place-before=0 \
src-address=10.1.101.0/24 dst-address=10.1.202.0/24
It is very important that bypass rule is placed at the top of all other NAT rules.
Note: If you previously tried to establish tunnel before NAT bypass rule was added, you have to clear
connection table from existing connection or restart the routers
Ipsec/L2TP behind NAT

Consider setup as illustrated below
Client needs secure connection to the office with public address 1.1.1.1, but server does not know what will be the
source address from which client connects. It is so called road-warrior setup. Our client will also be located behind
the router with enabled NAT.
For the setup RouterOS router will be used as the client device behind NAT (it can be any device: Windows PC,
Smartphone, Linux PC, etc.)
Manual:IP/IPsec 27
IP Connectivity
On the server:
/ip address
/ip route
add gateway=1.1.1.2
On the clients router:
/ip address
/ip route
add gateway=2.2.2.1
/ip firewall net

add chain=srcnat action=masquerade out-interface=ether1
On the client:
/ip address
L2TP Config
On the server:
/interface l2tp-server
set enabled=yes profil=default
/ip pool
add name=l2tp-pool ranges=192.168.1.2-192.168.1.20
/ppp profile
set default local-address=192.168.1.1 remote-address=l2tp-pool
/ppp secret
add name=l2tp-test password=test123456
On the client:
/interface l2tp-client
add connect-to=1.1.1.1 disabled=no name=l2tp-out1 password=password user=l2tp-test
Manual:IP/IPsec 28
IpSec Config
On server side:
/ip ipsec proposal

set [ find default=yes ] enc-algorithms=3des,aes-128,aes-192,aes-256
/ip ipsec peer
add generate-policy=yes hash-algorithm=sha1 nat-traversal=yes secret=test123456 \
send-initial-contact=no
RouterOS as client:
/ip ipsec proposal

set [ find default=yes ] enc-algorithms=aes-128
/ip ipsec peer
add address=1.1.1.1/32 hash-algorithm=sha1 nat-traversal=yes secret=test123456
/ip ipsec policy

add dst-address=1.1.1.1/32 protocol=udp sa-dst-address=1.1.1.1 \
sa-src-address=10.5.8.120 src-address=10.5.8.120/32
Notice that nat-traversal is enabled. This option is required because Ipsec connection will be established
through the NAT router otherwise Ipsec will not be able to establish phase2.
Note: Only one L2TP/ipsec connection can be established through the NAT. Which means that only one
client can connect to the sever located behind the same router.
Connecting with Shrew Client and allowing only Encrypted traffic

See example here
Manual:Interface/EoIP
Applies to RouterOS: 2.9, v3, v4+
Summary
Sub-menu: /interface eoip
Standards: GRE RFC 1701
Ethernet over IP (EoIP) Tunneling is a MikroTik RouterOS protocol that creates an Ethernet tunnel between two
routers on top of an IP connection. The EoIP tunnel may run over IPIP tunnel, PPTP tunnel or any other connection
capable of transporting IP.
When the bridging function of the router is enabled, all Ethernet traffic (all Ethernet protocols) will be bridged just
as if there where a physical Ethernet interface and cable between the two routers (with bridging enabled). This
protocol makes multiple network schemes possible.
Network setups with EoIP interfaces:
Possibility to bridge LANs over the Internet
Possibility to bridge LANs over encrypted tunnels
Possibility to bridge LANs over 802.11b 'ad-hoc' wireless networks
The EoIP protocol encapsulates Ethernet frames in GRE (IP protocol number 47) packets (just like PPTP) and sends
them to the remote side of the EoIP tunnel.
Properties
arp (disabled | enabled | Address Resolution Protocol mode.

proxy-arp | reply-only; Default: disabled - the interface will not use ARP
enabled) enabled - the interface will use ARP
proxy-arp - the interface will use the ARP proxy feature
reply-only - the interface will only reply to requests originated from matching IP address/MAC address
combinations which are entered as static entries in the "/ip arp" table. No dynamic entries will be
automatically stored in the "/ip arp" table. Therefore for communications to be successful, a valid static
entry must already exist.
keepalive (integer; Default: keep-alive timer, sets time interval (seconds) in what keep-alive messages should be received. If 3 messages are
not set) missed, interface running flag is removed. For this to work, keepalive has to be set to same value on both ends
of the tunnel, since one end is expecting messages from the other one and is sending keepalive messages in that
direction.
l2mtu (integer; Default: ) Layer2 Maximum transmission unit. Not configurable for EoIP. Read more>>
local-address (IP; Default: Source address of the tunnel packets, local on the router.
)
mac-address (MAC; Default: Media Access Control number of an interface. The address numeration authority IANA allows the use of MAC
) addresses in the range from 00:00:5E:80:00:00 - 00:00:5E:FF:FF:FF freely

remote-address (IP; IP address of remote end of EoIP tunnel

Default: )
tunnel-id (integer: 65536; Unique tunnel identifier, which must match other side of the tunnel
Default: )
Notes
tunnel-id is method of identifying tunnel. It must be unique for each EoIP tunnel.
mtu should be set to 1500 to eliminate packet refragmentation inside the tunnel (that allows transparent bridging of
Ethernet-like networks, so that it would be possible to transport full-sized Ethernet frame over the tunnel).
When bridging EoIP tunnels, it is highly recommended to set unique MAC addresses for each tunnel for the bridge
algorithms to work correctly. For EoIP interfaces you can use MAC addresses that are in the range from
00:00:5E:80:00:00 - 00:00:5E:FF:FF:FF , which IANA has reserved for such cases. Alternatively, you can set the
second bit of the first byte to modify the auto-assigned address into a 'locally administered address', assigned by the
network administrator and thus use any MAC address, you just need to ensure they are unique between the hosts
connected to one bridge.
Note: EoIP tunnel adds at least 42 byte overhead (8byte GRE + 14 byte Ethernet + 20 byte IP)
Setup examples
Let us assume we want to bridge two networks: 'Office LAN' and 'Remote LAN'. By using EoIP
setup can be made so that Office and Remote LANs are in the same Layer2 broadcast domain.
Consider following setup:
As you know wireless station cannot be bridged, to overcome this limitation (not involving WDS) we will create
EoIP tunnel over the wireless link and bridge it with interfaces connected to local networks.
We will not cover wireless configuration in this example, lets assume that wireless link is already established
At first we create EoIP tunnel on our gateway ...
[admin@Our_GW] interface eoip> add name="eoip-remote" tunnel-id=0 \

\... remote-address=10.0.0.2
[admin@Our_GW] interface eoip> enable eoip-remote

[admin@Our_GW] interface eoip> print
Flags: X - disabled, R - running
0 name=eoip-remote mtu=1500 arp=enabled remote-address=10.0.0.2 tunnel-id=0
[admin@Our_GW] interface eoip>
... and on Remote router
[admin@Remote] interface eoip> add name="eoip" tunnel-id=0 \

\... remote-address=10.0.0.1
[admin@Remote] interface eoip> enable eoip-main
[admin@Remote] interface eoip> print
0 name=eoip mtu=1500 arp=enabled remote-address=10.0.0.1 tunnel-id=0
[admin@Remote] interface eoip>
Next step is to bridge local interfaces with EoIP tunnel On Our GW ...
[admin@Our_GW] interface bridge> add

[admin@Our_GW] interface bridge> print
0 R name="bridge1" mtu=1500 arp=enabled mac-address=00:00:00:00:00:00
protocol-mode=none priority=0x8000 auto-mac=yes
admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
transmit-hold-count=6 ageing-time=5m
[admin@Our_GW] interface bridge> port add bridge=bridge1 interface=eoip-remote
[admin@Our_GW] interface bridge> port add bridge=bridge1 interface=office-eth
[admin@Our_GW] interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST
0 eoip-remote bridge1 128 10
1 office-eth bridge1 128 10
[admin@Our_GW] interface bridge>
... and Remote router:
[admin@Remote] interface bridge> add

[admin@Remote] interface bridge> print
0 R name="bridge1" mtu=1500 arp=enabled mac-address=00:00:00:00:00:00
protocol-mode=none priority=0x8000 auto-mac=yes
admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
transmit-hold-count=6 ageing-time=5m
[admin@Remote] interface bridge> port add bridge=bridge1 interface=ether
[admin@Remote] interface bridge> port add bridge=bridge1 interface=eoip-main
[admin@Remote] interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic
# INTERFACE BRIDGE PRIORITY PATH-COST
0 ether bridge1 128 10
1 eoip-main bridge1 128 10

[admin@Remote] interface bridge>
Now both sites are in the same Layer2 broadcast domain. You can set up IP addresses from the same network on
both sites.
Manual:Interface/Gre
Applies to RouterOS: v5+
Summary
Sub-menu: /interface gre
Standards: GRE RFC 1701
GRE (Generic Routing Encapsulation) is a tunnelling protocol that was originally developed by Cisco. It can
encapsulate a wide variety of protocols creating a virtual point-to-point link.
GRE is the same as IPIP and EoIP which were originally developed as stateless tunnels. Which means that if the
remote end of the tunnel goes down, all traffic that was routed over the tunnels will gets blackholed. To solve this
problem, RouterOS have added 'keepalive' feature for GRE tunnels.
GRE tunnel adds a 24 byte overhead (4-byte gre header + 20-byte IP header).
Note: GRE tunnel can forward only IP and IPv6 packets (ethernet type 800 and 86dd)
Properties
arp (disabled | enabled | Address Resolution Protocol mode

proxy-arp | reply-only; Default: disabled - the interface will not use ARP
) enabled - the interface will use ARP
proxy-arp - the interface will use the ARP proxy feature
reply-only - the interface will only reply to requests originated from matching IP address/MAC address
combinations which are entered as static entries in the "/ip arp" table. No dynamic entries will be
automatically stored in the "/ip arp" table. Therefore for communications to be successful, a valid static entry
must already exist.
comment (string; Default: ) Short description of the tunnel.
disabled (yes | no; Default: Enables/disables tunnel.

no)
dscp (inherit | integer [0-63]; Since v5.6, set dscp value in GRE header to a fixed value or inherit from dscp value taken from tunnelled traffic
Default: )
keepalive (integer Tunnel keepalive timeout in seconds. By default keepalive is disabled.

[1..4294967295]; Default: )
l2mtu (integer [0..65536]; Layer2 Maximum transmission unit.

Default: 65535)
local-address (IP; IP address that will be used for local tunnel end. If set to 0.0.0.0 then IP address of outgoing interface will be
Default: 0.0.0.0) used.
mtu (integer [0..65536]; Layer3 Maximum transmission unit.

Default: 1476)
name (string; Default: ) Name of the tunnel.
remote-address (IP; IP address of remote tunnel end.

Default: )
Setup examples
The goal of this example is to get Layer 3 connectivity between two remote sites over the internet.
We have two sites, Site1 with local network range 10.1.101.0/24 and Site2 with local network range 10.1.202.0/24.
First step is to create GRE tunnels. Router on site 1:
/interface gre add name=myGre remote-address=192.168.90.1 local-address=192.168.80.1
Router on site 2:
/interface gre add name=myGre remote-address=192.168.80.1 local-address=192.168.90.1
As you can see tunnel configuration is quite simple.

Note: In this example keepalive is not configured, so tunnel interface will have running flag even if remote
tunnel end is not reachable
Now we just need to set up tunnel addresses and proper routing. Router on site 1:
/ip address
add address=172.16.1.1/30 interface=myGre
/ip route
add dst-address=10.1.202.0/24 gateway=172.16.1.2
Router on site 2:
/ip address
add address=172.16.1.2/30 interface=myGre
/ip route
add dst-address=10.1.101.0/24 gateway=172.16.1.1
At this point both sites have Layer 3 connectivity over GRE tunnel.
Manual:Interface/IPIP
Applies to RouterOS: 2.9, v3, v4+
Summary
Sub-menu: /interface ipip
Standards: IPIP RFC 2003
The IPIP tunneling implementation on the MikroTik RouterOS is RFC 2003 compliant. IPIP tunnel is a simple
protocol that encapsulates IP packets in IP to make a tunnel between two routers. The IPIP tunnel interface appears
as an interface under the interface list. Many routers, including Cisco and Linux, support this protocol. This protocol
makes multiple network schemes possible.
IP tunnelling protocol adds the following possibilities to a network setups:
to tunnel Intranets over the Internet
to use it instead of source routing
Properties
dscp (inherit | integer [0-63]; Default: ) Set dscp value in IPIP header to a fixed value or inherit from dscp value taken from tunnelled traffic
local-address (IP; Default: ) IP address on a router that will be used by IPIP tunnel
remote-address (IP; Default: ) IP address of remote end of IPIP tunnel
Note: There is no authentication or 'state' for this interface. The bandwidth usage of the interface may be
monitored with the monitor feature from the interface menu.
IPv6
Sub-menu: /interface ipipv6
IP/IPv6 over IPv6 tunnel functionality is added in v5RC6 and is configurable from menu: /interface ipipv6
IPv6 version uses the same properties as IPv4 version.
Setup examples
Suppose we want to add an IPIP tunnel between routers R1 and R2:
At first, we need to configure IPIP interfaces and then add IP addresses to them.
The configuration for router R1 is as follows:
[admin@MikroTik] interface ipip> add

local-address: 10.0.0.1
remote-address: 22.63.11.6
[admin@MikroTik] interface ipip> print
# NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS
0 X ipip1 1480 10.0.0.1 22.63.11.6
[admin@MikroTik] interface ipip> en 0

[admin@MikroTik] interface ipip> /ip address add address=1.1.1.1/24 interface=ipip1
The configuration of the R2 is shown below:

[admin@MikroTik] interface ipip> add local-address=22.63.11.6 remote-address=10.

0.0.1
[admin@MikroTik] interface ipip> print
# NAME MTU LOCAL-ADDRESS REMOTE-ADDRESS
0 X ipip1 1480 22.63.11.6 10.0.0.1
[admin@MikroTik] interface ipip> enable 0

[admin@MikroTik] interface ipip> /ip address add address=1.1.1.2/24 interface=ipip1
Now both routers can ping each other:
[admin@MikroTik] interface ipip> /ping 1.1.1.2

[admin@MikroTik] interface ipip>
Manual:Interface/PPP
Summary
Standards: RFC 1661
Package: ppp
PPP Client
Sub-menu: /interface ppp-client
Manual:Interface/PPP 37
add-default-route (yes | no; Default: no) Whether to add default route to forward all traffic over the tunnel.
allow (pap | chap | mschap1 | mschap2; Default: Allowed protocols to use for authentication
pap,chap,mschap1,mschap2)
apn (string; Default: ) Service Provider's Access Point Name
comment (string; Default: ) Descriptive name of an item
data-channel (integer; Default: 0) Which of the port channels used for data transfer. Read more >>
default-route-distance (integer; Since v6.2, sets distance value applied to auto created default route, if
Default: 1) add-default-route is also selected
dial-command (string; Default: "ATDT") AT dial command to use. The default one sets tone dialing mode.
dial-on-demand (yes | no; Default: no) Enable/disable dial on demand
disabled (yes | no; Default: yes) Whether interface is disabled or not. By default it is disabled.
info-channel (integer; Default: 0) Which of the port channels used for info. Read more >>
keepalive-timeout (integer PPP keepalive timeout in seconds.

[0..4294967295]; Default: 30s)
max-mru (integer; Default: 1500) Maximum Receive Unit. Max packet size that PPP interface will be able to receive without
packet fragmentation.
max-mtu (integer; Default: 1500) Maximum Transmission Unit. Max packet size that PPP interface will be able to send without
modem-init (string; Default: "") Modem init string
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it
will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over the
tunnel. Read more >>
name (string; Default: ) Descriptive name of the interface.
null-modem (yes | no; Default: no) Enable/disable null-modem mode (when enabled, no modem initialization strings are sent)
password (string; Default: "") Password used for authentication.
phone (string; Default: "") Phone number for dial out.
pin (string; Default: "") SIM Cards Pin code.
port (string; Default: "") Serial or USB Port name where modem is connected. Read more >>
profile (name; Default: default) Used PPP profile.
remote-address (IP Address; Default: ) Remote IP Address
use-peer-dns (yes | no; Default: yes) Use DNS server settings from the remote server
user (string; Default: ) User name used for authentication.

Manual:Interface/PPPoE
Applies to RouterOS: v3, v4
Summary
The PPPoE (Point to Point Protocol over Ethernet) protocol provides extensive user management, network
management and accounting benefits to ISPs and network administrators. Currently PPPoE is used mainly by ISPs to
control client connections for xDSL and cable modems as well as plain Ethernet networks. PPPoE is an extension of
the standard Point to Point Protocol (PPP). The difference between them is expressed in transport method: PPPoE
employs Ethernet instead of serial modem connection.
Generally speaking, PPPoE is used to hand out IP addresses to clients based on authentication by username (and also
if required, by workstation) as opposed to workstation only authentication where static IP addresses or DHCP are
used. It is advised not to use static IP addresses or DHCP on the same interfaces as PPPoE for obvious security
reasons.
The PPPoE client and server work over any Layer2 Ethernet level interface on the router - wireless 802.11 (Aironet,
Cisco, WaveLan, Prism, Atheros), 10/100/1000 Mbit/s Ethernet, RadioLan and EoIP (Ethernet over IP tunnel).
Feature list
PPPoE server and client support;
Multilink PPP (MLPPP);
MLPPP over single link (ability to transmit full-sized frames);
BCP (Bridge Control Protocol) support - allows sending of raw Ethernet frames over PPP links;
MPPE 40bit and MPPE 128bit RSA encryption;
pap, chap, mschap v1/v2 authentication;
RADIUS support for client authentication and accounting.
Note that when RADIUS server is authenticating a user with CHAP, MS-CHAPv1 or MS-CHAPv2, the RADIUS
protocol does not use shared secret, it is used only in authentication reply. So if you have a wrong shared secret,
RADIUS server will accept the request. You can use /radius monitor command to see bad-replies parameter. This
value should increase whenever a client tries to connect.
Supported connections:
MikroTik RouterOS PPPoE client to any PPPoE server (access concentrator)
MikroTik RouterOS server (access concentrator) to multiple PPPoE clients (clients are available for almost all
operating systems and most routers)
Specifications
Packages required: ppp
License required: Level1 (limited to 1 interface) , Level3 (limited to 200 interfaces) , Level4 (limited to 200
interfaces) , Level5 (limited to 500 interfaces) , Level6 (unlimited)
Submenu level: /interface pppoe-server, /interface pppoe-client
Standards and Technologies: PPPoE (RFC 2516)
Hardware usage: PPPoE server may require additional RAM (uses approx. 9KiB (plus extra 10KiB for packet
queue, if data rate limitation is used) for each connection) and CPU power. Maximum of 65535 connections is
supported.
Quick Setup Guide

To configure MikroTik RouterOS to be a PPPoE client, just add a pppoe-client:
/interface pppoe-client
add name=pppoe-user-mike user=user password=passwd interface=wlan1 \
service-name=internet disabled=no
To configure MikroTik RouterOS to be an Access Concentrator (PPPoE Server):

add an address pool for the clients from 10.1.1.62 to 10.1.1.72;
add ppp profile;
add ppp secret (username/password);
add pppoe server itself.
/ip pool
add name="pppoe-pool" ranges=10.1.1.62-10.1.1.72
/ppp profile
add name="pppoe-profile" local-address=10.1.1.1 remote-address=pppoe-pool
/ppp secret
add name=user password=passwd service=pppoe profile=pppoe-profile
/interface pppoe-server server

add service-name=internet interface=wlan1 default-profile=pppoe-profile
PPPoE Operation
Stages
PPPoE has two stages:
Discovery stage - a client discovers all available access concentrators and selects one of them to establish PPPoE
session.This stage has four steps: initialization, offer, request and session confirmation . PPPoE Discovery uses
special Ethernet frames with their own Ethernet frame type 0x8863.
To initiate discovery, PPPoE client sends PADI frame to the broadcast Ethernet address (FF:FF:FF:FF:FF:FF) and
optionally may specify a service name.
When server receives PADI frame, it responds with PADO frame to Client's unicast Ethernet address. There can be
more than one server in broadcast range of the client. In such case client collects PADO frames and picks one (in
most cases it picks the server which responds first) to start session.
Client sends PADR frame to unicast Ethernet address of the server it chose. If server agrees to set up a session with
this particular client, it allocates resources to set up PPP session and assigns Session ID number. This number is sent
back to client in PADS frame. When client receives PADS frame, it knows servers mac address and Session ID, it
allocates resources and session can begin.
Session - When discovery stage is completed, both peers know PPPoE Session ID and other peer's Etehrnet
(MAC) address which together defines PPPoE session. PPP frames are encapsulated in PPPoE session frames,
which have Ethernet frame type 0x8864.
When server sends confirmation and client receives it, PPP Session stage is started that consists of following
steps:
LCP negotiation
Authentication
IPCP negotiation - where client is assigned an IP address.
PPPoE server sends Echo-Request packets to the client to determine the state of the session, otherwise server will not
be able to determine that session is terminated in cases when client terminates session without sending
Terminate-Request packet.
More detailed description of PPPoE protocol can be found in RFC 2516
Used Packet Types
Packet Description
PADI PPPoE Active Discovery Initialization

The PPPoE client sends out a PADI packet to the broadcast address. This packet can also populate the "service-name" field if a service
name has been entered in the dial-up networking properties of the PPPoE client. If a service name has not been entered, this field is not
populated
PADO PPPoE Active Discovery Offer

The PPPoE server, or Access Concentrator, should respond to the PADI with a PADO if the Access Concentrator is able to service the
"service-name" field that had been listed in the PADI packet. If no "service-name" field had been listed, the Access Concentrator will
respond with a PADO packet that has the "service-name" field populated with the service names that the Access Concentrator can service.
The PADO packet is sent to the unicast address of the PPPoE client
PADR PPPoE Active Discovery Request

When a PADO packet is received, the PPPoE client responds with a PADR packet. This packet is sent to the unicast address of the Access
Concentrator. The client may receive multiple PADO packets, but the client responds to the first valid PADO that the client received. If the
initial PADI packet had a blank "service-name" field filed, the client populates the "service-name" field of the PADR packet with the first
service name that had been returned in the PADO packet.
PADS PPPoE Active Discovery Session confirmation

When the PADR is received, the Access Concentrator generates a unique session identification (ID) for the Point-to-Point Protocol (PPP)
session and returns this ID to the PPPoE client in the PADS packet. This packet is sent to the unicast address of the client.
PADT PPPoE Active Discovery Terminate

can be sent anytime after a session is established to indicate that a PPPoE session terminated. It can be sent by either server or client.
MTU
Typically, the largest Ethernet frame that can be transmitted without fragmentation is 1500 bytes. PPPoE adds
another 6 bytes of overhead and PPP field adds two more bytes, leaving 1492 bytes for IP datagram. Therefore max
PPPoE MRU and MTU values must not be larger than 1492.
TCP stacks try to avoid fragmentation, so they use an MSS (Maximum Segment Size). By default MSS is chosen as
MTU of the outgoing interface minus the usual size of the TCP and IP headers (40 bytes), which results in 1460
bytes for an Ethernet interface. Unfortunately there may be intermediate links with lower MTU which will cause
fragmentation. In such case TCP stack performs path MTU discovery. Routers which cannot forward the datagram
without fragmentation are supposed to drop packet and send ICMP-Fragmentation-Required to originating host.
When host receives such ICMP packet, it tries to lower the MTU. This should work in the ideal world, however in
the real world many routers do not generate fragmentation-required datagrams, also many firewalls drop all ICMP
datagrams.
The workaround for this problem is to adjust MSS if it is too big. By default RouterOS adds mangle rules to
intercept TCP SYN packets and silently adjust any advertised MSS option so they will be appropriate for the PPPoE
link.
Additional information on maximum supported MTUs for RouterBoards are listed here.
PPPoE Client
Sub-menu: /interface pppoe-client
Properties
ac-name (string; Default: "") Access Concentrator name, this may be left blank and the client will connect to any access
concentrator on the broadcast domain
add-default-route (yes|no; Default: no) Enable/Disable whether to add default route automatically
allow (mschap2|mschap1|chap|pap; Default: allowed authentication methods, by default all methods are allowed
mschap2,mschap1,chap,pap)
default-route-distance (integer; sets distance value applied to auto created default route, if add-default-route is also
Default:1) selected
dial-on-demand (yes|no; Default: no) connects to AC only when outbound traffic is generated
interface (string; Default: ) interface name on which client will run
keepalive-timeout (integer; Default:60) Sets keepalive timeout in seconds.
max-mru (integer; Default: 1460) Maximum Receive Unit
max-mtu (integer; Default: 1460) Maximum Transmission Unit
mrru (integer: 512..65535|disabled; Default: maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it
disabled) will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over the
name (string; Default: pppoe-out[i]) name of the PPPoE interface, generated by RouterOS if not specified
password (string; Default: ) password used to authenticate
profile (string; Default: default) default profile for the connection defined in /ppp profiles
service-name (string; Default: "") specifies the service name set on the access concentrator, can be left blank to connect to any
PPPoE server
use-peer-dns (yes|no; Default: no) enable/disable getting DNS settings from the peer
user (string; Default: "") username used for authentication
Status
Command /interface pppoe-client monitor will display current PPPoE status.
Available read only properties:
ac-mac (MAC address) MAC address of the access concentrator (AC) the client is connected to
ac-name (string) name of the Access Concentrator
active-links (integer) Number of bonded MLPPP connections, ('1' if not using MLPPP)
encoding (string) encryption and encoding (if asymmetric, separated with '/') being used in this connection
local-address (IP Address) IP Address allocated to client
remote-address (IP Address) Remote IP Address allocated to server (ie gateway address)
mru (integer) effective MRU of the link
mtu (integer) effective MTU of the link

service-name (string) used service name
status (string) current link status. Available values are:

dialing,
verifying password...,
connected,
disconnected.
uptime (time) connection time displayed in days, hours, minutes and seconds
Scanner
Starting from v3.21 RouterOS has new tool - PPPoE Scanner. It allows you to scan all active PPPoE servers in
broadcast domain. Command to run scanner is as follows /interface pppoe-client scan
<interface>
service (string) Service name configured on server
mac-address (MAC) Mac address of detected server
ac-name (string) name of the Access Concentrator
Notes
Note for Windows. Some connection instructions may use the form where the "phone number", such as
"MikroTik_AC\mt1", is specified to indicate that "MikroTik_AC" is the access concentrator name and "mt1" is the
service name.
Specifying MRRU means enabling MP (Multilink PPP) over single link. This protocol is used to split big packets
into smaller ones. Under Windows it can be enabled in Networking tab, Settings button, "Negotiate multi-link for
single link connections". MRRU is hardcoded to 1614 on Windows. This setting is useful to overcome PathMTU
discovery failures. The MP setting should be enabled on both peers.
Example
To add and enable PPPoE client on the ether1 interface connecting to the AC that provides 'testSN' service using
user name user with the password 'passwd':
[admin@RemoteOffice] interface pppoe-client> add interface=ether1 service-name=testSN user=user
password=passwd disabled=no
[admin@RemoteOffice] interface pppoe-client> print
0 R name="pppoe-out1" max-mtu=1480 max-mru=1480 mrru=disabled interface=ether1
user="user" password="passwd" profile=default service-name="testSN"
ac-name="" add-default-route=no dial-on-demand=no use-peer-dns=no
allow=pap,chap,mschap1,mschap2
[admin@MikroTik] interface pppoe-client> monitor pppoe-out1

status: "connected"
uptime: 6s
idle-time: 6s
encoding: "MPPE128 stateless"

service-name: "testSN"
ac-name: "MikroTik"
ac-mac: 00:0C:42:04:00:73
mtu: 1480
mru: 1480
Additional Resources
PPPoE Clients:
RASPPPoE [1]for Windows 95, 98, 98SE, ME, NT4, 2000, XP, .NET
PPPoE Server Setup (Access Concentrator)

Sub-menu: /interface pppoe-server server
The PPPoE server (access concentrator) supports multiple servers for each interface - with differing service names.
Currently the throughput of the PPPoE server has been tested to 160 Mb/s on a Celeron 600 CPU. Using higher
speed CPUs, throughput should increase proportionately.
The access concentrator name and PPPoE service name are used by clients to identity the access concentrator to
register with. The access concentrator name is the same as the identity of the router displayed before the command
prompt. The identity may be set within the /system identity submenu.
Note that if no service name is specified in WindowsXP, it will only use a service with no name! So if you want to
serve WindowsXP clients, leave your service name empty.
Properties
authentication ( mschap2 | mschap1 | chap | Authentication algorithm

pap; Default: "mschap2, mschap1, chap, pap")
default-profile (string; Default: "default") Default user profile to use
interface (string; Default: "") Interface that the clients are connected to
keepalive-timeout (time; Default: "10") Defines the time period (in seconds) after which the router is starting to send keepalive packets
every second. If there is no traffic and no keepalive responses arrive for that period of time
(i.e. 2 * keepalive-timeout), the non responding client is proclaimed disconnected.
max-mru (integer; Default: "1480") Maximum Receive Unit. The optimal value is the MTU of the interface the tunnel is working
over reduced by 20 (so, for 1500-byte Ethernet link, set the MTU to 1480 to avoid
fragmentation of packets)
max-mtu (integer; Default: "1480") Maximum Transmission Unit. The optimal value is the MTU of the interface the tunnel is
working over reduced by 20 (so, for 1500-byte Ethernet link, set the MTU to 1480 to avoid
fragmentation of packets)
max-sessions (integer; Default: "0") Maximum number of clients that the AC can serve. '0' = no limitations.
mrru (integer: 512..65535 | disabled; Default: Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU,
"disabled") it will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over
the tunnel. Read more >>
one-session-per-host (yes | no; Default: Allow only one session per host (determined by MAC address). If a host tries to establish a
"no") new session, the old one will be closed.
service-name (string; Default: "") The PPPoE service name. Server will accept clients which sends PADI message with
service-names that matches this setting or if service-name field in PADI message is not set.
Notes
The default keepalive-timeout value of 10s is OK in most cases. If you set it to 0, the router will not disconnect
clients until they explicitly log out or the router is restarted. To resolve this problem, the one-session-per-host
property can be used.
Note: Security issue: do not assign an IP address to the interface you will be receiving the PPPoE requests on.
Specifying MRRU means enabling MP (Multilink PPP) over a single link. This protocol is used to
split big packets into smaller ones. Under Windows it can be enabled in Networking tag, Settings
button, "Negotiate multi-link for single link connections". Their MRRU is hardcoded to 1614. This
setting is useful to overcome PathMTU discovery failures. The MP setting should be enabled on
both peers.
Example
To add PPPoE server on ether1 interface provided with a service-name of "ex" and allowing only one connection per
host:
[admin@MikroTik] interface pppoe-server server> add interface=ether1 service-name=ex

one-session-per-host=yes
[admin@MikroTik] interface pppoe-server server> print
Flags: X - disabled
0 X service-name="ex" interface=ether1 mtu=1480 mru=1480 mrru=disabled
authentication=mschap2,mschap,chap,pap keepalive-timeout=10
one-session-per-host=yes max-sessions=0 default-profile=default
[admin@MikroTik] interface pppoe-server server>
PPPoE Server
Sub-menu: /interface pppoe-server
There are two types of interface (tunnel) items in PPTP server configuration - static users and dynamic connections.
An interface is created for each tunnel established to the given server. Static interfaces are added administratively if
there is a need to reference the particular interface name (in firewall rules or elsewhere) created for the particular
user. Dynamic interfaces are added to this list automatically whenever a user is connected and its username does not
match any existing static entry (or in case the entry is active already, as there can not be two separate tunnel
interfaces referenced by the same name - set one-session-per-host value if this is a problem). Dynamic
interfaces appear when a user connects and disappear once the user disconnects, so it is impossible to reference the
tunnel created for that use in router configuration (for example, in firewall), so if you need a persistent rules for that
user, create a static entry for him/her. Otherwise it is safe to use dynamic configuration. Note that in both cases PPP
users must be configured properly - static entries do not replace PPP configuration.
encoding (read-only: text) - encryption and encoding (if asymmetric, separated with '/') being used in this
connection
mru (read-only: integer) - client's MRU
mtu (read-only: integer) - client's MTU
name (name) - interface name
remote-address (read-only: MAC address) - MAC address of the connected client
service (name) - name of the service the user is connected to
uptime (read-only: time) - shows how long the client is connected
user (name) - the name of the connected user (must be present in the user darabase anyway)
Example
To view the currently connected users:
[admin@MikroTik] interface pppoe-server> print

Flags: X - disabled, D - dynamic, R - running
# NAME USER SERVICE REMOTE... ENCODING UPTIME
0 DR <pppoe-ex> user ex 00:0C:... MPPE12... 40m45s
[admin@MikroTik] interface pppoe-server>
To disconnect the user ex:
[admin@MikroTik] interface pppoe-server> remove [find user=ex]

[admin@MikroTik] interface pppoe-server> print
[admin@MikroTik] interface pppoe-server>
PPPoE in a multipoint wireless 802.11g network

In a wireless network, the PPPoE server may be attached to an Access Point (as well as to a regular station of
wireless infrastructure). Either our RouterOS client or Windows PPPoE clients may connect to the Access Point for
PPPoE authentication. Further, for RouterOS clients, the radio interface may be set to MTU 1600 so that the PPPoE
interface may be set to MTU 1500. This optimizes the transmission of 1500 byte packets and avoids any problems
associated with MTUs lower than 1500. It is not discussed here, how to change the MTU of the Windows wireless
interface.
Let us consider the following setup where the MikroTik Wireless AP offers wireless clients transparent access to the
local network with authentication:
First of all, the wireless interface should be configured:
[admin@PPPoE-Server] interface wireless> set 0 mode=ap-bridge \

frequency=2442 band=2.4ghz-b/g ssid=mt disabled=no
[admin@PPPoE-Server] interface wireless> print
0 X name="wlan1" mtu=1500 mac-address=00:0C:42:18:5C:3D arp=enabled
interface-type=Atheros AR5413 mode=ap-bridge ssid="mt" frequency=2442
band=2.4ghz-b/g scan-list=default antenna-mode=ant-a wds-mode=disabled
wds-default-bridge=none wds-ignore-ssid=no default-authentication=yes
default-forwarding=yes default-ap-tx-limit=0 default-client-tx-limit=0
hide-ssid=no security-profile=default compression=no
[admin@PPPoE-Server] interface wireless>
Now, configure the Ethernet interface, add the IP address and set the default route:
[admin@PPPoE-Server] ip address> add address=10.1.0.3/24 interface=Local

[admin@PPPoE-Server] ip address> print
0 10.1.0.3/24 10.1.0.0 10.1.0.255 Local
[admin@PPPoE-Server] ip address> /ip route
[admin@PPPoE-Server] ip route> add gateway=10.1.0.1
[admin@PPPoE-Server] ip route> print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC G GATEWAY DISTANCE INTER...
0 ADC 10.1.0.0/24 10.1.0.3 0 Local

1 A S 0.0.0.0/0 r 10.1.0.1 1 Local
[admin@PPPoE-Server] ip route> /interface ethernet
[admin@PPPoE-Server] interface ethernet> set Local arp=proxy-arp
[admin@PPPoE-Server] interface ethernet> print
# NAME MTU MAC-ADDRESS ARP
0 R Local 1500 00:0C:42:03:25:53 proxy-arp
[admin@PPPoE-Server] interface ethernet>
We should add PPPoE server to the wireless interface:
[admin@PPPoE-Server] interface pppoe-server server> add interface=wlan1 \

service-name=mt one-session-per-host=yes disabled=no
[admin@PPPoE-Server] interface pppoe-server server> print
Flags: X - disabled
0 service-name="mt" interface=wlan1 max-mtu=1480 max-mru=1480 mrru=disabled
authentication=pap,chap,mschap1,mschap2 keepalive-timeout=10
one-session-per-host=yes max-sessions=0 default-profile=default
[admin@PPPoE-Server] interface pppoe-server server>
Finally, we can set up PPPoE clients:
[admin@PPPoE-Server] ip pool> add name=pppoe ranges=10.1.0.100-10.1.0.200

[admin@PPPoE-Server] ip pool> print
# NAME RANGES
0 pppoe 10.1.0.100-10.1.0.200
[admin@PPPoE-Server] ip pool> /ppp profile
[admin@PPPoE-Server] ppp profile> set default use-encryption=yes \
local-address=10.1.0.3 remote-address=pppoe
[admin@PPPoE-Server] ppp profile> print
Flags: * - default
0 * name="default" local-address=10.1.0.3 remote-address=pppoe
use-compression=no use-vj-compression=no use-encryption=yes only-one=no
change-tcp-mss=yes
1 * name="default-encryption" use-compression=default
use-vj-compression=default use-encryption=yes only-one=default
change-tcp-mss=default
[admin@PPPoE-Server] ppp profile> .. secret
[admin@PPPoE-Server] ppp secret> add name=w password=wkst service=pppoe
[admin@PPPoE-Server] ppp secret> add name=l password=ltp service=pppoe
[admin@PPPoE-Server] ppp secret> print
Flags: X - disabled
# NAME SERVICE CALLER-ID PASSWORD PROFILE REMOTE-ADDRESS
0 w pppoe wkst default 0.0.0.0
1 l pppoe ltp default 0.0.0.0
[admin@PPPoE-Server] ppp secret>
We have now completed the configuration and added two users: w and l who are able to connect to Internet, using
PPPoE client software.
Note that Windows XP built-in client supports encryption, but RASPPPOE does not. So, if it is planned to support
Windows clients older than Windows XP, it is recommended not to require encryption. In either case, the server is
able to support clients that cannot encrypt the data.
Troubleshooting
I can connect to my PPPoE server. I can even ping through it, but I still cannot open web pages
Make sure that you have specified a valid DNS server in the router (in /ip dns or in /ppp profile the dns-server
parameter).
The PPPoE server shows more than one active user entry for one client, when the clients disconnect, they
are still shown and active
Set the keepalive-timeout parameter (in the PPPoE server configuration) to 10 if you want clients to be
considered logged off if they do not respond for 10 seconds.
Note that if the keepalive-timeout parameter is set to 0 and the only-one parameter (in PPP profile
settings) is set to 'yes' then the clients may be able to connect only the once. To resolve this problem
one-session-per-host parameter in PPPoE server configuration should be set to 'yes'
My Windows XP client cannot connect to the PPPoE server
You have to specify the "Service Name" in the properties of the XP PPPoE client. If the service name is not set, or it
does not match the service name of the MikroTik PPPoE server, you get the "line is busy" errors, or the system
shows "verifying password - unknown error"
I want to have logs for PPPoE connection establishment
Configure the logging feature under the /system logging facility and enable the PPP type logs. Read more >>
References
[1] http:/ / www. raspppoe. com/
Manual:Interface/PPTP
Applies to RouterOS: v3, v4, v5+
Summary
Standards: RFC 2637
PPTP is a secure tunnel for transporting IP traffic using PPP. PPTP encapsulates PPP in virtual lines that run over IP.
PPTP incorporates PPP and MPPE (Microsoft Point to Point Encryption) to make encrypted links. The purpose of
this protocol is to make well-managed secure connections between routers as well as between routers and PPTP
clients (clients are available for and/or included in almost all OSs including Windows).
Multilink PPP (MP) is supported in order to provide MRRU (the ability to transmit full-sized 1500 and larger
packets) and bridging over PPP links (using Bridge Control Protocol (BCP) that allows to send raw Ethernet frames
over PPP links). This way it is possible to setup bridging without EoIP. The bridge should either have an
administratively set MAC address or an Ethernet-like interface in it, as PPP links do not have MAC addresses.
PPTP includes PPP authentication and accounting for each PPTP connection. Full authentication and accounting of
each connection may be done through a RADIUS client or locally.
MPPE 40bit RC4 and MPPE 128bit RC4 encryption are supported.
PPTP traffic uses TCP port 1723 and IP protocol GRE (Generic Routing Encapsulation, IP protocol ID 47), as
assigned by the Internet Assigned Numbers Authority (IANA). PPTP can be used with most firewalls and routers by
enabling traffic destined for TCP port 1723 and protocol 47 traffic to be routed through the firewall or router.
PPTP connections may be limited or impossible to setup though a masqueraded/NAT IP connection. Please see the
Microsoft and RFC links listed below for more information.
PPTP Client
Sub-menu: /interface pptp-client
Properties
add-default-route (yes | no; Default: no) Whether to add PPTP remote address as a default route.
allow (mschap2 | mschap1 | chap | pap; Allowed authentication methods.

Default: mschap2, mschap1, chap, pap)
connect-to (IP; Default: ) Remote address of PPTP server
dial-on-demand (yes | no; Default: no)
disabled (yes | no; Default: yes) Whether interface is disabled or not. By default it is disabled
max-mru (integer; Default: 1460) Maximum Receive Unit. Max packet size that PPTP interface will be able to receive without
max-mtu (integer; Default: 1460) Maximum Transmission Unit. Max packet size that PPTP interface will be able to send without
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it
will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over the
profile (name; Default: default-encryption) Used PPP profile.
Quick example
This example demonstrates how to set up PPTP client with username "pptp-hm", password "123" and server
10.1.101.100
[admin@dzeltenais_burkaans] /interface pptp-client>add name=pptp-hm user=pptp-hm password=123 \
\... connect-to=10.1.101.100 disabled=no
[admin@dzeltenais_burkaans] /interface pptp-client> print detail
0 name="pptp-hm" max-mtu=1460 max-mru=1460 mrru=disabled
connect-to=10.1.101.100 user="pptp-hm" password="123"
profile=default-encryption add-default-route=no dial-on-demand=no
PPTP Server
Sub-menu: /interface pptp-server
This sub-menu shows interfaces for each connected PPTP clients.
An interface is created for each tunnel established to the given server. There are two types of interfaces in PPTP
server's configuration
Static interfaces are added administratively if there is a need to reference the particular interface name (in firewall
rules or elsewhere) created for the particular user.
Dynamic interfaces are added to this list automatically whenever a user is connected and its username does not
interfaces referenced by the same name).
Dynamic interfaces appear when a user connects and disappear once the user disconnects, so it is impossible to
reference the tunnel created for that use in router configuration (for example, in firewall), so if you need a persistent
rules for that user, create a static entry for him/her. Otherwise it is safe to use dynamic configuration.
Note: in both cases PPP users must be configured properly - static entries do not replace PPP configuration.
Server configuration
Sub-menu: /interface pptp-server server
Properties
authentication (pap | chap | mschap1 Authentication methods that server will accept.
| mschap2; Default: mschap1,mschap2)
default-profile (name; Default:

default-encryption)
enabled (yes | no; Default: no) Defines whether PPTP server is enabled or not.
keepalive-timeout (time; Default: 30) If server during keepalive period does not receive any packet, it will send keepalive packets every
second five times. If the server does not receives response from the client, then disconnect after 5
seconds. Logs will show 5x "LCP missed echo reply" messages and then disconnect.
max-mru (integer; Default: 1460) Maximum Receive Unit. Max packet size that PPTP interface will be able to receive without packet
fragmentation.
max-mtu (integer; Default: 1460) Maximum Transmission Unit. Max packet size that PPTP interface will be able to send without
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it will
be split into multiple packets, allowing full size IP or Ethernet packets to be sent over the tunnel.
Read more >>
To enable PPTP server:
[admin@MikroTik] interface pptp-server server> set enabled=yes

[admin@MikroTik] interface pptp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
authentication: mschap2,mschap1
keepalive-timeout: 30
default-profile: default
[admin@MikroTik] interface pptp-server server>
Monitoring
Monitor command can be used to monitor status of the tunnel on both client and server.
[admin@dzeltenais_burkaans] /interface pptp-client> monitor 0

status: "connected"
uptime: 7h24m18s
idle-time: 6h21m4s
mtu: 1460
mru: 1460
Read-only properties
status () Current PPTP status. Value other than "connected" indicates that there are some problems estabising tunnel.
uptime (time) Elapsed time since tunnel was established.
idle-time (time) Elapsed time since last activity on the tunnel.
encoding () Used encryption method
mtu (integer) Negotiated and used MTU
mru (integer) Negotiated and used MRU
Connecting Remote Client

The following example shows how to connect a computer to a remote office network over PPTP encrypted tunnel
giving that computer an IP address from the same network as the remote office has (without need of bridging over
EoIP tunnels)
Consider following setup
Office router is connected to internet through ether1. Workstations are connected to ether2. Laptop is connected to
the internet and can reach Office router's public IP (in our example it is 192.168.80.1).
First step is to create a user
[admin@RemoteOffice] /ppp secret> add name=Laptop service=pptp password=123

local-address=10.1.101.1 remote-address=10.1.101.100
[admin@RemoteOffice] /ppp secret> print detail
Flags: X - disabled
0 name="Laptop" service=pptp caller-id="" password="123" profile=default
local-address=10.1.101.1 remote-address=10.1.101.100 routes==""
[admin@RemoteOffice] /ppp secret>

Notice that pptp local address is the same as routers address on local interface and remote address is form the same
range as local network (10.1.101.0/24).
Next step is to enable pptp server and pptp client on the laptop.
[admin@RemoteOffice] /interface pptp-server server> set enabled=yes

[admin@RemoteOffice] /interface pptp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
authentication: mschap2
[admin@RemoteOffice] /interface pptp-server server>
PPTP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.
Please, consult the respective manual on how to set up a PPTP client with the software You are using.
At this point (when pptp client is successfully connected) if you will try to ping any workstation form the laptop,
ping will time out, because Laptop is unable to get ARPs from workstations. Solution is to set up proxy-arp on
local interface
[admin@RemoteOffice] /interface ethernet> set Office arp=proxy-arp

[admin@RemoteOffice] /interface ethernet> print
0 R ether1 1500 00:30:4F:0B:7B:C1 enabled
1 R ether2 1500 00:30:4F:06:62:12 proxy-arp
[admin@RemoteOffice] interface ethernet>
After proxy-arp is enabled client can successfully reach all workstations in local network behind the router.
Site-to-Site PPTP
The following is an example of connecting two Intranets using PPTP tunnel over the Internet.
Office and Home routers are connected to internet through ether1, workstations and laptops are connected to ether2.
Both local networks are routed through pptp client, thus they are not in the same broadcast domain. If both networks
should be in the same broadcast domain then you need to use BCP and bridge pptp tunnel with local interface.
[admin@RemoteOffice] /ppp secret> add name=Home service=pptp password=123
local-address=172.16.1.1 remote-address=172.16.1.2 routes="10.1.202.0/24 172.16.1.2 1"
Flags: X - disabled
0 name="Home" service=pptp caller-id="" password="123" profile=default
local-address=172.16.1.1 remote-address=172.16.1.2 routes=="10.1.202.0/24 172.16.1.2 1"
Notice that we set up pptp to add route whenever client connects. If this option is not set, then you will need static
routing configuration on the server to route traffic between sites through pptp tunnel.
Next step is to enable pptp server on the office router and configure pptp client on the Home router.
[admin@RemoteOffice] /interface pptp-server server> set enabled=yes

[admin@RemoteOffice] /interface pptp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
[admin@RemoteOffice] /interface pptp-server server>
[admin@Home] /interface pptp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no

[admin@Home] /interface pptp-client> print
0 name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connect-to=192.168.80.1 user="Home"
password="123" profile=default-encryption add-default-route=no dial-on-demand=no
[admin@Home] /interface pptp-client>
Now we need to add route to reach local network behind Home router
[admin@RemoteOffice] /ip route> add dst-address=10.1.101.0/24 gateway=pptp-out1
Now after tunnel is established and routes are set, you should be able to ping remote network.
Read More
BCP (Bridge Control Protocol)
http://msdn.microsoft.com/library/backgrnd/html/understanding_pptp.htm
http://support.microsoft.com/support/kb/articles/q162/8/47.asp
http://www.ietf.org/rfc/rfc2637.txt?number=2637
Manual:Interface/L2TP
Applies to RouterOS: v3, v4, v5+
Summary
Standards: RFC 2661
L2TP is a secure tunnel protocol for transporting IP traffic using PPP. L2TP encapsulates PPP in virtual lines that
run over IP, Frame Relay and other protocols (that are not currently supported by MikroTik RouterOS). L2TP
incorporates PPP and MPPE (Microsoft Point to Point Encryption) to make encrypted links. The purpose of this
protocol is to allow the Layer 2 and PPP endpoints to reside on different devices interconnected by a
packet-switched network. With L2TP, a user has a Layer 2 connection to an access concentrator - LAC (e.g., modem
bank, ADSL DSLAM, etc.), and the concentrator then tunnels individual PPP frames to the Network Access Server -
NAS. This allows the actual processing of PPP packets to be separated from the termination of the Layer 2 circuit.
From the user's perspective, there is no functional difference between having the L2 circuit terminate in a NAS
directly or using L2TP.
It may also be useful to use L2TP just as any other tunneling protocol with or without encryption. The L2TP
standard says that the most secure way to encrypt data is using L2TP over IPsec (Note that it is default mode for
Microsoft L2TP client) as all L2TP control and data packets for a particular tunnel appear as homogeneous UDP/IP
data packets to the IPsec system.
Multilink PPP (MP) is supported in order to provide MRRU (the ability to transmit full-sized 1500 and larger
packets) and bridging over PPP links (using Bridge Control Protocol (BCP) that allows to send raw Ethernet frames
over PPP links). This way it is possible to setup bridging without EoIP. The bridge should either have an
administratively set MAC address or an Ethernet-like interface in it, as PPP links do not have MAC addresses.
L2TP includes PPP authentication and accounting for each L2TP connection. Full authentication and accounting of
each connection may be done through a RADIUS client or locally.
MPPE 40bit RC4 and MPPE 128bit RC4 encryption are supported.
L2TP traffic uses UDP protocol for both control and data packets. UDP port 1701 is used only for link
establishment, further traffic is using any available UDP port (which may or may not be 1701). This means that
L2TP can be used with most firewalls and routers (even with NAT) by enabling UDP traffic to be routed through the
firewall or router.
L2TP Client
Sub-menu: /interface l2tp-client
add-default-route (yes | no; Default: no) Whether to add L2TP remote address as a default route.
allow (mschap2 | mschap1 | chap | pap; Default: Allowed authentication methods.

mschap2, mschap1, chap, pap)
connect-to (IP; Default: ) Remote address of L2TP server
comment (string; Default: ) Short description of the tunnel.
default-route-distance (integer; Default: Since v6.2, sets distance value applied to auto created default route, if
) add-default-route is also selected
dial-on-demand (yes | no; Default: no) connects only when outbound traffic is generated
disabled (yes | no; Default: yes) Enables/disables tunnel.
keepalive-timeout (integer Since v6.0rc13, tunnel keepalive timeout in seconds.

[1..4294967295]; Default: 60s)
max-mru (integer; Default: 1460) Maximum Receive Unit. Max packet size that L2TP interface will be able to receive without
max-mtu (integer; Default: 1460) Maximum Transmission Unit. Max packet size that L2TP interface will be able to send
without packet fragmentation.
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU,
it will be split into multiple packets, allowing full size IP or Ethernet packets to be sent over
the tunnel. Read more >>
This example demonstrates how to set up L2TP client with username "l2tp-hm", password "123" and server
10.1.101.100
[admin@dzeltenais_burkaans] /interface l2tp-client>add name=l2tp-hm user=l2tp-hm password=123 \
[admin@dzeltenais_burkaans] /interface l2tp-client> print detail
0 name="l2tp-hm" max-mtu=1460 max-mru=1460 mrru=disabled

connect-to=10.1.101.100 user="l2tp-hm" password="123"
profile=default-encryption add-default-route=no dial-on-demand=no
L2TP Server
Sub-menu: /interface l2tp-server
This sub-menu shows interfaces for each connected L2TP clients.
An interface is created for each tunnel established to the given server. There are two types of interfaces in L2TP
reference the tunnel created for that use in router configuration (for example, in firewall), so if you need persistent
Sub-menu: /interface l2tp-server server
Properties
authentication (pap | chap | Authentication methods that server will accept.

mschap1 | mschap2; Default:
mschap1,mschap2)
default-profile (name; Default: default profile to use

default-encryption)
enabled (yes | no; Default: no) Defines whether L2TP server is enabled or not.
max-mru (integer; Default: 1460) Maximum Receive Unit. Max packet size that L2TP interface will be able to receive without packet
fragmentation.
keepalive-timeout (integer; If server during keepalive-timeout period does not receive any packets, it will send keepalive
Default: 30) packets every second, five times. If the server still does not receive any response from the client, then the
client will be disconnected after 5 seconds. Logs will show 5x "LCP missed echo reply" messages and
then disconnect. Available starting from v5.22 and v6rc3.
max-mtu (integer; Default: 1460) Maximum Transmission Unit. Max packet size that L2TP interface will be able to send without packet
fragmentation.
mrru (disabled | integer; Default: Maximum packet size that can be received on the link. If a packet is bigger than tunnel MTU, it will be
disabled) split into multiple packets, allowing full size IP or Ethernet packets to be sent over the tunnel. Read
more >>
To enable L2TP server:
[admin@MikroTik] interface l2tp-server server> set enabled=yes

[admin@MikroTik] interface l2tp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
authentication: pap,chap,mschap1,mschap2
default-profile: default-encryption
[admin@MikroTik] interface l2tp-server server>
Monitoring
[admin@dzeltenais_burkaans] /interface l2tp-client> monitor 0

status: "connected"
uptime: 7h24m18s
idle-time: 6h21m4s
mtu: 1460
mru: 1460
status () Current L2TP status. Value other than "connected" indicates that there are some problems establishing tunnel.
dialing - attempting to make a connection
verifying password - connection has been established to the server, password verification in progress
connected - tunnel is successfully established
terminated - interface is not enabled or the other side will not establish a connection
encoding () Used encryption method
local-address (IP Address) IP Address of local interface
remote-address (IP Address) IP Address of remote interface
mru (integer) Negotiated and used MRU


The following example shows how to connect a computer to a remote office network over L2TP encrypted tunnel
giving that computer an IP address from the same network as the remote office has (without any need of bridging
over EoIP tunnels)
[admin@RemoteOffice] /ppp secret> add name=Laptop service=l2tp password=123

Flags: X - disabled
0 name="Laptop" service=l2tp caller-id="" password="123" profile=default
Notice that L2TP local address is the same as routers address on local interface and remote address is from the same
Next step is to enable L2TP server and L2TP client on the laptop.
[admin@RemoteOffice] /interface l2tp-server server> set enabled=yes

[admin@RemoteOffice] /interface l2tp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
[admin@RemoteOffice] /interface l2tp-server server>
L2TP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.
Please, consult the respective manual on how to set up a L2TP client with the software you are using.
Note: By default Windows sets up L2TP with IPsec. To disable IpSec, registry modifications are required.
Read more >>
At this point (when L2TP client is successfully connected) if you will try to ping any workstation
from the laptop, ping will time out, because Laptop is unable to get ARPs from workstations.
Solution is to set up proxy-arp on local interface
[admin@RemoteOffice] interface ethernet> set ether2 arp=proxy-arp

[admin@RemoteOffice] interface ethernet> print
After proxy-arp is enabled client can now successfully reach all workstations in local network behind the router.
Site-to-Site L2TP
The following is an example of connecting two Intranets using a L2TP tunnel over the Internet.
Both local networks are routed through L2TP client, thus they are not in the same broadcast domain. If both
networks should be in the same broadcast domain then you need to use BCP and bridge L2TP tunnel with local
interface.
[admin@RemoteOffice] /ppp secret> add name=Home service=l2tp password=123

[admin@RemoteOffice] ppp secret> print detail
Flags: X - disabled
0 name="Home" service=l2tp caller-id="" password="123" profile=default
Notice that we set up L2TP to add route whenever client connects. If this option is not set, then you will need static
routing configuration on the server to route traffic between sites through L2TP tunnel.
Next step is to enable L2TP server on the office router and configure L2TP client on the Home router.
[admin@RemoteOffice] /interface l2tp-server server> set enabled=yes

[admin@RemoteOffice] /interface l2tp-server server> print
enabled: yes
max-mtu: 1460
max-mru: 1460
mrru: disabled
[admin@RemoteOffice] /interface l2tp-server server>
[admin@Home] /interface l2tp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no

[admin@Home] /interface l2tp-client> print
0 R name="l2tp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connect-to=192.168.80.1 user="Home"
password="123" profile=default-encryption add-default-route=no dial-on-demand=no
[admin@Home] /interface l2tp-client>
On home router if you wish traffic for the remote office to go over tunnel you will need to add a specific static route
as follows:
[admin@Home] /ip route> add dst-address=10.1.101.0/24 gateway=l2tp-out1
After tunnel is established and routes are set, you should be able to ping remote network.
Read More
Disable IpSec used with L2TP on Windows [1]
MikroTik RouterOS and Windows XP IPSec/L2TP
References
[1] http:/ / support. microsoft. com/ default. aspx?scid=kb%3Ben-us%3B258261. php
Manual:Interface/SSTP
Summary
Standards: SSTP specification [1]
Package: ppp
Secure Socket Tunneling Protocol (SSTP) is the way to transport PPP tunnel over SSL 3.0 channel. The use of SSL
over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.
SSTP connection mechanism
TCP connection is established from client to server (by default on port 443);
SSL validates server certificate. If certificate is valid connection is established otherwise connection is torn down.
The client sends SSTP control packets within the HTTPS session which establishes the SSTP state machine on
both sides.
PPP negotiation over SSTP. Client authenticates to the server and binds IP addresses to SSTP interface
SSTP tunnel is now established and packet encapsulation can begin.
If both client and server are Mikrotik routers, then it is possible to establish SSTP tunnel without certificates and
with any available authentication type. Otherwise to establish secure tunnels mschap authentication and client/server
certificates from the same chain should be used. Read more>>
Note: Starting from v5.0beta2 SSTP does not require certificates to operate. This feature will work only
between two MikroTik routers, as it is not according to standards.
Currently, SSTP clients exist only in Windows Vista, Windows 7 and RouterOS.
Note: While connecting to SSTP server, Windows does CRL (certificate revocation list) checking on server
certificate which can introduce significant delay to complete connection or even prevent user from accessing
sstp server at all if Windows is unable to access CRL distribution point! Custom generated CA which does
not include CRLs can be used to minimize connection delays and certificate costs (signed certificates with
known CA usually are not for free), but this custom CA must be imported into each Windows client
individually. It is possible to disable CRL check in Windows registry, but it is supported only by Windows Server 2008 http:/ /
support.microsoft.com/kb/947054
Certificates
Note: Starting from RouterOS v6rc10 SSTP respects CRL
To set up secure SSTP tunnel, certificates are required. On the server authentication is done only
by username and password, but on the client - server is authenticated using server certificate. It is
also used by client to cryptographicly bind SSL and PPP authentication, meaning - the clients
sends a special value over SSTP connection to server, this value is derived from the key data that
is generated during PPP authentication and server certificate, this allows server to check if both channels are secure.
If sstp clients are Windows PCs then only way to set up secure SSTP tunnel when using self-signed certificate is by
importing "server" certificate on SSTP server and on windows PC add CA certificate in trusted root [2].
Note: If your server certificate is issued by CA which is known by Windows, then Windows client will work
witout any additional certificates.
Warning: RSA Key length must be at least 472 bits if certificate is used by SSTP. Shorter keys are
considered as security threats.
Similar configuration on RouterOS client would be, importing CA certificate and enabling
verify-server-certificate option. In this scenario Man-in-the-Middle attacks are not possible.
Between two Mikrotik routers it is also possible to set up insecure tunnel by not using certificates
at all. In this case data going through SSTP tunnel is using anonymous DH and Man-in-the-Middle attacks are easily
accomplished. This scenario is not compatible with Windows clients.
It is also possible to make secure SSTP tunnel by adding additional authorization with client certificate.
Configuration requirements are:
certificates on both server and client
verification options enabled on server and client
This scenario is also not possible with Windows clients, because there is no way to set up client certificate on
Windows.
Certificate error messages

When ssl handshake fails, you will see one of the following certificate errors:
certificate is not yet valid - notBefore date is after the current time.
certificate has expired - notAfter date is before the current time.
invalid certificate purpose - the supplied certificate cannot be used for the specified purpose.
self signed certificate in chain - the certificate chain could be built up using the untrusted certificates but the root
could not be found locally.
unable to get issuer certificate locally - CA certificate is not imported locally.
server's IP address does not match certificate - server address verification is enabled, but address provided in
certificate does not match servers address.
Hostname verification
Starting from v5.6 when server ceritificate verification is enabled on sstp client, additionally IP addresses found in
certificate's subjectAltName and then issuer CN will be compared to the real address. DNS names are ignored. v5.7
adds new parameter verify-server-address-from-certificate to disable/enable hostname
verification.
SSTP Client
Sub-menu: /interface sstp-client
Properties
add-default-route (yes | no; Default: no) Whether to add SSTP remote address as a default route.
authentication (mschap2 | mschap1 | chap | pap; Default: Allowed authentication methods.

mschap2, mschap1, chap, pap)
certificate (string | none; Default: none)
connect-to (IP:Port; Default: 0.0.0.0:443) Remote address and port of SSTP server.
dial-on-demand (yes | no; Default: no)
keepalive-timeout (integer | disabled; Default: 60)
max-mru (integer; Default: 1500) Maximum Receive Unit. Max packet size that SSTP interface will be able to
receive without packet fragmentation.
max-mtu (integer; Default: 1500) Maximum Transmission Unit. Max packet size that SSTP interface will be
able to send without packet fragmentation.
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger
than tunnel MTU, it will be split into multiple packets, allowing full size IP
or Ethernet packets to be sent over the tunnel. Read more >>
proxy (IP:Port; Default: 0.0.0.0:443) Address and port of HTTP proxy server.

verify-server-certificate (yes | no; Default: no) If set to yes, then client checks whether certificate belongs to the same
certificate chain as server's certificate. To make it work CA certificate must
be imported.
verify-server-address-from-certificate (yes | no; If set to yes, server's IP address will be compared to one set in certificate.
Default: yes) Read More >>
Quick example
This example demonstrates how to set up SSTP client with username "sstp-test", password "123" and server
10.1.101.1
[admin@MikroTik] /interface sstp-client>add user=sstp-test password=123 \

[admin@MikroTik] /interface sstp-client> print
0 R name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connect-to=10.1.101.1:443
user="sstp-test" password="123" proxy=0.0.0.0:443 profile=default
certificate=none keepalive-timeout=60 add-default-route=no dial-on-demand=no
authentication=pap,chap,mschap1,mschap2
SSTP Server
Sub-menu: /interface sstp-server
This sub-menu shows interfaces for each connected SSTP clients.
An interface is created for each tunnel established to the given server. There are two types of interfaces in SSTP
Sub-menu: /interface sstp-server server
Properties:
authentication (pap | chap | mschap1 | Authentication methods that server will accept.
mschap2; Default: pap,chap,mschap1,mschap2)
certificate (name | none; Default: none) Name of the certificate that SSTP server will use.
default-profile (name; Default: default)
enabled (yes | no; Default: no) Defines whether SSTP server is enabled or not.
force-aes (yes | no; Default: no) Force AES encryption. If enabled windows clients (supports only RC4) will be unable to
connect.
keepalive-timeout (integer | disabled; Default: If server during keepalive period does not receive any packet, it will send keepalive packets
60) every second five times. If the server does not receives response from the client, then
disconnect after 5 seconds. Logs will show 5x "LCP missed echo reply" messages and then
disconnect.
max-mru (integer; Default: 1500) Maximum Receive Unit. Max packet size that SSTP interface will be able to receive
max-mtu (integer; Default: 1500) Maximum Transmission Unit. Max packet size that SSTP interface will be able to send
mrru (disabled | integer; Default: disabled) Maximum packet size that can be received on the link. If a packet is bigger than tunnel
MTU, it will be split into multiple packets, allowing full size IP or Ethernet packets to be
sent over the tunnel. Read more >>
verify-client-certificate (yes | no; If set to yes, then server checks whether client's certificate belongs to the same certificate
Default: no) chain.
[admin@MikroTik] /interface sstp-server server> set certificate=server

[admin@MikroTik] /interface sstp-server server> set enabled=yes
[admin@MikroTik] /interface sstp-server server> print
enabled: yes
port: 443
max-mtu: 1500
max-mru: 1500
mrru: disabled
certificate: server
verify-client-certificate: no
[admin@MikroTik] /interface sstp-server server>
Warning: It is very important that date on the router is in the range of certificate's date of expiration . To
overcome any certificate verification problems, enable NTP date synchronization on both server and client.
Monitoring
[admin@dzeltenais_burkaans] /interface sstp-server> monitor 0

status: "connected"
uptime: 17m47s
idle-time: 17m47s
user: "sstp-test"
caller-id: "10.1.101.18:43886"
mtu: 1500
status () Current SSTP status. Value other than "connected" indicates that there are some problems estabising tunnel.
user (string) Username used to establish the tunnel.
caller-id (IP:ID)

The following example shows how to connect a computer to a remote office network over secure SSTP encrypted
tunnel giving that computer an IP address from the same network as the remote office has (without need of bridging
over EoIP tunnels)
Before you begin to configure SSTP you need to create a server certificate and import it to the router (instructions
here).
Now it is time to create a user
[admin@RemoteOffice] /ppp secret> add name=Laptop service=sstp password=123


Flags: X - disabled
0 name="Laptop" service=sstp caller-id="" password="123" profile=default
Notice that SSTP local address is the same as routers address on local interface and remote address is form the same
Next step is to enable sstp server and sstp client on the laptop.
[admin@RemoteOffice] /interface sstp-server server> set certificate=server

[admin@RemoteOffice] /interface sstp-server server> set enabled=yes
[admin@RemoteOffice] /interface sstp-server server> set authentication=mschap2
[admin@RemoteOffice] /interface sstp-server server> print
enabled: yes
port: 443
max-mtu: 1500
max-mru: 1500
mrru: disabled
certificate: server
verify-client-certificate: no
[admin@RemoteOffice] /interface sstp-server server>
Notice that authentication is set to mschap. These are the only authentication options that are valid to establish
secure tunnel.
SSTP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.
Please, consult the respective manual on how to set up a SSTP client with the software You are using. If you set up
SSTP client on Windows and self-signed certificates are used, then CA certificate should be added to trusted root [2].
Note: Currently SSTP is supported on Windows 2008, Windows Vista and Vista SP1. Other OS will not be
able to connect to SSTP server
To verify if sstp client is connected
[admin@RemoteOffice] /interface sstp-server> print

Flags: X - disabled, D - dynamic, R - running
# NAME USER MTU CLIENT-ADDRESS UPTIME ENCODING
0 DR <sstp-... Laptop 1500 10.1.101.18:43886 1h47s
[admin@RemoteOffice] /interface sstp-server>monitor 0

status: "connected"
uptime: 1h45s
idle-time: 1h45s
user: "Laptop"
caller-id: "192.168.99.1:43886"
mtu: 1500
At this point (when SSTP client is successfully connected) if you will try to ping any workstation form the laptop,
ping will time out, because Laptop is unable to get ARPs from workstations. Solution is to set up proxy-arp on
local interface
[admin@RemoteOffice] /interface ethernet> set ether2 arp=proxy-arp

[admin@RemoteOffice] /interface ethernet> print
After proxy-arp is enabled client can successfully reach all workstations in local network behind the router.
Site-to-Site SSTP
The following is an example of connecting two Intranets using SSTP tunnel over the Internet.
In this example both local networks are routed through sstp client, thus they are not in the same broadcast domain.
To overcome this problem as any other ppp tunnel SSTP also supports BCP which allows to bridge SSTP tunnel
with local interface.
[admin@RemoteOffice] /ppp secret> add name=Home service=sstp password=123
[admin@RemoteOffice] ppp secret> print detail
Flags: X - disabled
0 name="Home" service=sstp caller-id="" password="123" profile=default

Notice that we set up SSTP to add route whenever client connects. If this option is not set, then you will need static
routing configuration on the server to route traffic between sites through SSTP tunnel.
Now we need to upload and import CA and server/client certificates. Assume that files are already uploaded use
following commands:
admin@RemoteOffice] /certificate> import file-name=ca.crt

passphrase:
admin@RemoteOffice] /certificate> import file-name=server.crt
passphrase: ****
admin@RemoteOffice] /certificate> import file-name=server.key
passphrase: ****
Set up proper names:

admin@RemoteOffice] /certificate>set 0 name=CA
admin@RemoteOffice] /certificate>set 1 name=server
admin@RemoteOffice] /certificate> print
Flags: K - decrypted-private-key, Q - private-key, R - rsa, D - dsa
0 D name="CA" subject=C=LV,ST=RI,L=Riga,O=MT,CN=MT CA,emailAddress=xx@mt.lv
issuer=C=LV,ST=RI,L=Riga,O=MT,CN=MT CA,emailAddress=xx@mt.lv
serial-number="DF626FA846090BCC" email=xx@mt.lv invalid-before=jun/25/2008 07:23:50
invalid-after=jun/23/2018 07:23:50 ca=yes
1 KR name="server" subject=C=LV,ST=RI,L=Riga,O=MT,CN=server,emailAddress=xx@mt.lv
issuer=C=LV,ST=RI,L=Riga,O=MT,CN=MT CA,emailAddress=xx@mt.lv serial-number="01"
email=xx@mt.lv invalid-before=jun/25/2008 07:24:33 invalid-after=jun/23/2018 07:24:33
ca=yes
Do the same on client side, but instead of server's certificate import client's certificate.
Next step is to enable SSTP server on the office router and configure SSTP client on the Home router.
[admin@RemoteOffice] /interface sstp-server server> set certificate=server

[admin@RemoteOffice] /interface sstp-server server> set enabled=yes
[admin@RemoteOffice] /interface sstp-server server> set verify-client-certificate=yes
[admin@RemoteOffice] /interface sstp-server server> print
enabled: yes
port: 443
max-mtu: 1500
max-mru: 1500
mrru: disabled
certificate: server
verify-client-certificate: yes
[admin@Home] /interface sstp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no

certificate=client verify-server-certificate=yes
[admin@Home] /interface sstp-client> print
0 R name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connect-to=192.168.80.1:443
user="Home" password="123" proxy=0.0.0.0:443 profile=default certificate=client
keepalive-timeout=60 add-default-route=no dial-on-demand=no
authentication=pap,chap,mschap1,mschap2 verify-server-certificate=yes
[admin@Home] /interface sstp-client>
Now we need to add static route on Home router to reach local network behind Office router
[admin@Home] /ip route> add dst-address=10.1.101.0/24 gateway=sstp-out1
After tunnel is established you should be able to ping remote network.
Troubleshooting
After Windows 7 upgrade SSTP is unable to connect (windows error 631) ?
MS Patch KB2585542 changes cypher to RC4 which was not supported on RouterOS. Starting from RouterOS
v5.13 RC4 is the preferred cipher and AES will be used only if peer does not advertise RC4.
I get following error when trying to connect Windows 7 client. Error 0x80070320 The oplock that was associated
with this handle is now associated with a different handle.
Disable verify-client-certificate option on the server.
Read More
Creating Certificates
http://technet.microsoft.com/en-us/library/cc731352(WS.10).aspx
Free trusted Class1 certificates [3] online
References
[1] http:/ / msdn. microsoft. com/ en-us/ library/ cc247338(PROT. 10). aspx
[2] http:/ / technet. microsoft. com/ en-us/ library/ dd458982. aspx
[3] http:/ / www. startssl. com/
Manual:Interface/OVPN
Applies to RouterOS: v5+
Summary
Standards:
Package: ppp
Note: RouterOS supports only TCP mode. LZO compression is not supported and username/password
authentication is required
OVPN Client
Sub-menu: /interface ovpn-client
Properties
add-default-route (yes | no; Default: no) Whether to add OVPN remote address as a default route.
auth (md5 | none | sha1; Default: sha1) Allowed authentication methods.
certificate (string | none; Default: none) Name of the client certificate imported into certificate list.
cipher (aes128 | aes192 | aes256 | blowfish128 | none; Allowed ciphers.

Default: blowfish128)
connect-to (IP; Default: 0.0.0.0) Remote address of the OVPN server.
mac-address (MAC; Default: ) Mac address of OVPN interface. Will be auto generated if not specified.
max-mtu (integer; Default: 1500) Maximum Transmission Unit. Max packet size that OVPN interface will be able to
send without packet fragmentation.
mode (ip | ethernet; Default: ip) Layer3 or layer2 tunnel mode (alternatively tun, tap)
port (integer; Default: 1194) Port to connect to.
profile (name; Default: default) Used PPP profile.

Quick example
This example demonstrates how to set up OVPN client with username "test", password "123" and server 10.1.101.1
[admin@bumba] /interface ovpn-client> add connect-to=10.1.101.1 user=test password=123 disabled=no
[admin@bumba] /interface ovpn-client> print
0 name="ovpn-out1" mac-address=FE:7B:9C:F9:59:D0 max-mtu=1500 connect-to=10.1.101.1
port=1194 mode=ip user="test" password="123" profile=default certificate=none auth=sha1
cipher=blowfish128 add-default-route=no
OVPN Server
Sub-menu: /interface ovpn-server
This sub-menu shows interfaces for each connected OVPN clients.
An interface is created for each tunnel established to the given server. There are two types of interfaces in OVPN
rule for that user, create a static entry for him/her. Otherwise it is safe to use dynamic configuration.
Sub-menu: /interface ovpn-server server
Properties:
auth (; Default: sha1,md5) Authentication methods that server will accept.
certificate (name | none; Default: none) Name of the certificate that OVPN server will use.
cipher (aes128 | none; Default: Allowed ciphers.

aes128,blowfish128)
default-profile (name; Default: Default profile to use.

default)
enabled (yes | no; Default: no) Defines whether OVPN server is enabled or not.
keepalive-timeout (integer | disabled; Defines the time period (in seconds) after which the router is starting to send keepalive packets
Default: 60) every second. If no traffic and no keepalive responses has came for that period of time (i.e. 2 *
keepalive-timeout), not responding client is proclaimed disconnected
mac-address (MAC; Default: ) Auto Generated MAC address of the server.
max-mtu (integer; Default: 1500) Maximum Transmission Unit. Max packet size that OVPN interface will be able to send without
mode (ip | ethernet; Default: ip) Layer3 or layer2 tunnel mode (alternatively tun, tap)
netmask (integer; Default: 24) Subnet mask to be applied to client.

port (integer; Default: 1194) Port to run server on.
require-client-certificate (yes | If set to yes, then server checks whether client's certificate belongs to the same certificate chain.
no; Default: no)
[admin@bumba] /interface ovpn-server server set enabled=yes

[admin@bumba] /interface ovpn-server server set certificate=server
[admin@bumba] /interface ovpn-server server print
enabled: yes
port: 1194
mode: ip
netmask: 24
mac-address: FE:A5:57:72:9D:EC
max-mtu: 1500
certificate: server
require-client-certificate: no
auth: sha1,md5
cipher: blowfish128,aes128
Warning: It is very important that the date on the router is within the range of the installed certificate's date
of expiration. To overcome any certificate verification problems, enable NTP date synchronization on both
server and client.
Monitoring
Monitor command can be used to monitor the status of the tunnel on both client and server.
[admin@dzeltenais_burkaans] /interface ovpn-server monitor 0

status: "connected"
uptime: 17m47s
idle-time: 17m47s
user: "test"
caller-id: "10.1.101.18:43886"
mtu: 1500
status () Current status. Value other than "connected" indicates that there are some problems establishing tunnel.
user (string) Username used to establish the tunnel.
caller-id (IP:ID) Source IP and Port of client.
Basic OVPN setup
Manual:BCP bridging (PPP tunnel bridging)

Applies to RouterOS: v3, v4
Summary
RouterOS supports BCP (Bridge Control Protocol) for PPP, PPTP, L2TP and PPPoE interfaces. BCP allows to
bridge Ethernet packets through the PPP link. Established BCP is independent part of the PPP tunnel, it is not related
to any IP address of PPP interface, bridging and routing can happen at the same time independently. BCP can be
used instead of EoIP + used VPN Tunnel or WDS link over the wireless network.
Requirements
BCP (Bridge Control Protocol) should be enabled on both sides (PPP server and PPP client) to make it work.
MikroTik RouterOS can be used with other PPP device, that supports BCP accordingly to the standards, but BCP
enabled is necessary.
Configuration Example
We need to interconnect two remote offices and make them in one Ethernet network. We have requirement to use
encryption to protect data exchange between two offices. Let's see, how it is possible with PPTP tunnel and BCP
protocol usage
Configuration Diagramm
Simple configuration is like this. We have two offices, which are remotely located. Office I is going to be used as
PPTP server, Office 2 is going to be used PPTP client. Below you will see how to set configuration using Winbox
and CLI.
BCP Configuration (CLI)
Office 1 configuration
First we need to create bridge interface and make sure that bridge will always have MAC address of existing
interface. Reason for that is simple - when BCP is used PPP bridge port do not have any MAC address.
/interface bridge add name=bridge_local protocol-mode=rstp

/interface bridge port add bridge=bridge_local interface=ether1_local
/interface bridge set bridge_local admin-mac=xx:xx:xx:xx:xx:xx
//// where xx:xx:xx:xx:xx:xx is MAC address of the ether1_local interface
Now we can assign local and public addresses to proper interfaces.
/ip address add address=192.168.88.1/24 interface=bridge_local

/ip address add address=1.1.1.1/24 interface=ether2_public
In case you use PPP only for bridging, configuration of the ppp profile and secret is very easy - just assign user name
and password in secret) and specify bridge option in the profile. Even if PPP is bridged local and remote addresses
on server side must be specified.
/ppp profile add name=ppp_bridging bridge=bridge_local use-encryption=yes

/ppp secret add profile=ppp_bridging name=ppp1 password=ppp1
When bridging packets PPP tunnel need to pass packets with Layer-2 (MAC) header included , so default interface
MTU (in case of pptp it is 1460) is not sufficient for this task. To ensure proper operation itis suggested to override
the value by specifying MRRU option in server settings to a higher value.
MRRU allows to enable multi-link support over single link, it divides the packet to multiple channels therefore
increasing possible MTU and MRU (up to 65535 bytes)
/interface pptp-server server set enabled=yes mrru=1600
Office 2 configuration
First we need to create bridge interface and make sure that bridge will always have MAC address of existing
interface. Reason for that is simple - when BCP is used PPP bridge port do not have any MAC address.
/interface bridge add name=bridge_local protocol-mode=rstp

/interface bridge port add bridge=bridge_local interface=ether1_local
/interface bridge set bridge_local admin-mac=xx:xx:xx:xx:xx:xx
//// where xx:xx:xx:xx:xx:xx is MAC address of the ether1_local interface
Assign local and public addresses to proper interfaces.
/ip address add address=192.168.88.254/24 interface=bridge_local

/ip address add address=2.2.2.2/24 interface=ether2_public
Configure ppp profile so it will corespond to the profile used on the server side.
/ppp profile add name=ppp_bridging bridge=bridge_local use-encryption=yes
Create an pptp-client interface. Do not forget to specify MRRU option to ensure that bridged frames get trough the
ppp tunnel.
/interface pptp-client
add profile=ppp_bridging mrru=1600 connect-to=1.1.1.1 user=ppp1 password=ppp1 disabled=no
BCP Configuration (Winbox)
Office 1 Configuration
Bridge Configuration:
Add Bridge,
Add Bridge Port,

Add Bridge MAC-address,
Assign IP addresses,
Create PPP profile for bridging,
Add PPP client,

Enable PPTP-server,
Office 2 Configuration
The client router configuration is the same, except that you need to configure and enable PPTP client,
Add PPTP client,
Manual:MLPPP over single and multiple links

Summary
Standards: RFC 1990
Package: ppp
Multi-Link Point to Point Protocol (MP, Multi-Link PPP, MultiPPP or MLPPP) is a method of splitting,
recombining, and sequencing data across multiple logical data links.
In a situation where we have multiple DSL links a pair of devices, performance by widening the pipe between two
devices can be increased by using Multi-Link PPP, without going to a newer, more expensive technology.
Large packets are actually split into bits and sent evenly over ALL logical data links. This is done instantaneously
with NO loss of bandwidth. It is important to understand that other end of the link needs to use the same protocol to
recombine your data.
Multilink is based on an LCP option negotiation that allows to indicate to its peer that it is capable of combining
multiple physical links.
MLPPP over single link

Typically size of the packet sent over PPP link is reduced due to overhead. MP can be used to transmit and receive
full frame over single ppp link. To make it work the Multilink Protocol uses additional LCP configuration options
Multilink Maximum Received Reconstructed Unit (MRRU)
To enable Multi-link PPP over single link you must specify MRRU (Maximum Receive Reconstructed Unit) option.
If both sides support this feature there are no need for MSS adjustment (in firewall mangle). Study shows that
MRRU is less CPU expensive that 2 mangle rules per client. MRRU allows to divide packet to multiple channels
therefore increasing possible MTU and MRU (up to 65535 bytes)
Under Windows it can be enabled in Networking tag, Settings button, "Negotiate multi-link for single link
connections". Their MRRU is hard coded to 1614.
Note: MTU will be reduced by 4 bytes to work properly when MPPE encryption is enabled
Let's configure pppoe server compatible with Windows clients and MRRU enabled.
[admin@RB800] /interface pppoe-server server> add service-name=myPPP interface=ether1 mrru=1614

[admin@RB800] /interface pppoe-server server> print
Flags: X - disabled
0 service-name="myPPP" interface=ether1 max-mtu=1480 max-mru=1480 mrru=1614
authentication=pap,chap,mschap1,mschap2 keepalive-timeout=10 one-session-per-host=no
max-sessions=0 default-profile=default
In short - standard PPP link - just specify MRRU in both sides :)

MLPPP over multiple links

MLPPP over multiple links allow to create a single ppp link over multiple physical connections. All PPP links must
come from the same server (server must have MLPPP over multiple links support) and all PPP links must have same
user name and password.
And to enable MLPPP you just need to create PPP client and specify multiple interfaces instead of single interface.
Mikrotik RouterOS have MLPPP clent support starting from version 3.10. Presently there are no MLPPP server
support available.
ISP gives to its client two physical links (DSL lines) 1Mbps each. To get aggregated 2Mbps pipe we have to set up
MLPPP. Consider ISP router is pre-configured to support MLPPP.
Configuration on Mikorotik router (R1) is:
/interface pppoe-client
add service-name=ISP interface=ether1,ether2 user=xxx password=yyy disabled=no \
add-default-route=yes use-peer-dns=yes
[admin@RB800] /interface pppoe-client> print

0 name="pppoe-out1" max-mtu=1480 max-mru=1480 mrru=disabled interface=ether1,ether2
user="xxx" password="yyy" profile=default service-name="ISP" ac-name="" add-default-route=yes
dial-on-demand=no use-peer-dns=yes allow=pap,chap,mschap1,mschap2
Now when pppoe client is connected we can set up rest of configuration, local network address, enable dns requests,
set up masquerade and firewall
/ip address add address=192.168.88.1/24 interface=local
/ip dns set allow-remote-request=yes
/ip firewall nat

add chain=src-nat action=masquerade out-interface=pppoe-out1
/ip firewall filter

add chain=input connection-state=invalid action=drop \
comment="Drop Invalid connections"
add chain=input connection-state=established action=accept \
comment="Allow Established connections"
add chain=input protocol=icmp action=accept \
comment="Allow ICMP"
add chain=input src-address=192.168.88.0/24 action=accept \
in-interface=!pppoe-out1
add chain=input action=drop comment="Drop everything else"
For more advanced router and customer protection check firewall examples.
See Also
PPPOE
Firewall and NAT
Manual:Interface/VPLS
Applies to RouterOS: v3, v4 +
Summary
Virtual Private Lan Service (VPLS) interface can be considered tunnel interface just like EoIP interface. To achieve
transparent ethernet segment forwarding between customer sites.
MikroTik RouterOS implements following VPLS features:
LDP signaling (RFC 4762), see LDP based VPLS
pseudowire fragmentation and reassembly (RFC 4623)
MP-BGP based autodiscovery and signaling (RFC 4761), see BGP based VPLS
Since version 3.17:
Cisco style static VPLS pseudowires (RFC 4447 FEC type 0x80), see static Cisco VPLS
Cisco VPLS BGP-based auto-discovery (draft-ietf-l2vpn-signaling-08), see BGP based Cisco style VPLS
support for multiple import/export route target extended communities for BGP based VPLS (both, RFC 4761 and
draft-ietf-l2vpn-signaling-08)
General
Sub-menu: /interface vpls
List of all VPLS interfaces. This menu shows also dynamically created BGP based VPLS interfaces.
Properties
advertised-l2mtu (integer; Default: 1500) L2MTU value advertised to remote peer.
arp (disabled | enabled | proxy-arp | reply-only; Address Resolution Protocol

Default: enabled)
cisco-style (yes | no; Default: no) Specifies whether to use cisco style VPLS.
cisco-style-id (integer; Default: 0) VPLS tunnel ID, used if cisco-style is set to yes.
comment (string; Default: ) Short description of the item
disable-running-check (yes | no; Specifies whether to detect if interface is running or not. If set to no interface will always have
Default: no) running flag.
disabled (yes | no; Default: yes) Defines whether item is ignored or used. By default VPLS interface is disabled.
l2mtu (integer; Default: 1500)
mac-address (MAC; Default: )
mtu (integer; Default: 1500)
name (string; Default: ) Name of the interface
pw-type (raw-ethernet | tagged-ethernet; Pseudowire type.

Default: raw-ethernet)
remote-peer (IP; Default: ) IP address of remote peer.
use-control-word (yes | no | default; Enables/disables Control Word usage. Default values for regular and cisco style VPLS tunnels
Default: default) differ. Cisco style by default has control word usage disabled. Read more >>.
vpls-id (AsNum | AsIp; Default: ) Unique number that identifies VPLS tunnel. Encoding is 2byte+4byte or 4byte+2byte number.
cisco-bgp-signaled (yes | no)
vpls (string) name of the bgp-vpls instance used to create dynamic vpls interface
Monitoring
Command /interface vpls monitor [id] will display current VPLS interface status
For example:
[admin@10.0.11.23] /interface vpls> monitor vpls2

remote-label: 800000
local-label: 43
remote-status:
transport: 10.255.11.201/32
transport-nexthop: 10.0.11.201
imposed-labels: 800000
imposed-label (integer) VPLS imposed label
local-label (integer) Local VPLS label
remote-group ()
remote-label (integer) Remote VPLS label
remote-status (integer)
transport-nexthop (IP prefix) Shows used transport address (typically Loopback address).
transport (string) Name of the transport interface. Set if VPLS is running over Traffic Engineering tunnel.
BGP VPLS
Sub-menu: /interface vpls bgp-vpls
List of BGP signaled VPLS instances. Configured instance makes router advertise VPLS BGP NLRI that advertises
that particular router belongs to some VPLS.
Properties
bridge (none | string; Default: If set to none VPLS interface is not added to bridge ports.
none)
bridge-cost (integer; Default:

50)
bridge-horizon (none | If set to none bridge horizon will not be used.

integer; Default: none)
disabled (yes | no; Default: no) Defines whether item is ignored or used.
export-route-target Setting is used to tag BGP NLRI with one or more route targets.
(AsNum | AsIp; Default: )
import-route-target Setting is used to determine if BGP NLRI is related to particular VPLS, by comparing route targets received
(AsNum | AsIp; Default: ) from BGP NLRI.
pw-mtu (integer[32..65535]; Advertised pseudowire MTU value.

Default: 1500)
pw-type (raw-ethernet | Parameter is available starting from v5.16. It allows to choose advertised encapsulation in NLRI used only for
tagged-ethernet | vpls; Default: comparison. It does not affect functionality of the tunnel. See pw-type usage example >>
vpls)
route-distinguisher Specifies value that gets attached to VPLS NLRI so that receiving routers can distinguish advertisements that
(AsNum | AsIp; Default: ) may otherwise look the same. This implies that unique route-distinguisher for every VPLS must be used. It is
not necessary to use the same route distinguisher for some VPLS on all routers forming that VPLS as
distinguisher is not used for determining if some BGP NLRI is related to particular VPLS (Route Target
attribute is used for this), but it is mandatory to have different distinguishers for different VPLSes.
site-id (integer; Default: 1) Unique site identifier. Each site must have unique site-id.
use-control-word (yes | no; Enables/disables Control Word usage. Read more >>
Default: yes)
Cisco Style BGP VPLS

Sub-menu: /interface cisco-bgp-vpls
Properties
bridge (none | string; Default: If set to none VPLS interface is not added to bridge ports.
none)
bridge-cost (integer;
Default: 50)
bridge-horizon (none | If set to none bridge horizon will not be used.

integer; Default: none)
disabled (yes | no; Default: Defines whether item is ignored or used.

no)
export-route-target Setting is used to tag BGP NLRI with one or more route targets.
(AsNum | AsIp; Default: )
import-route-target Setting is used to determine if BGP NLRI is related to particular VPLS, by comparing route targets received
(AsNum | AsIp; Default: ) from BGP NLRI.
l2router-id (IP; Default:

0.0.0.0)
pw-mtu (integer[32..65535]; Advertised pseudo-wire MTU.

Default: 1500)
route-distinguisher Specifies value that gets attached to VPLS NLRI so that receiving routers can distinguish advertisements that
(AsNum | AsIp; Default: ) may otherwise look the same. This implies that unique route-distinguisher for every VPLS must be used. It is not
necessary to use the same route distinguisher for some VPLS on all routers forming that VPLS as distinguisher is
not used for determining if some BGP NLRI is related to particular VPLS (Route Target attribute is used for
this), but it is mandatory to have different distinguishers for different VPLSes.
use-control-word (yes | Enables/disables Control Word usage. Read more >>

no; Default: yes)
vpls-id (integer; Default: ) Unique number that identifies VPLS tunnel.

Article Sources and Contributors 90
Article Sources and Contributors

Manual:Interface/VLAN Source: http://wiki.mikrotik.com/index.php?oldid=19562 Contributors: Janisk, Kirshteins, Marisb
Manual:IP/IPsec Source: http://wiki.mikrotik.com/index.php?oldid=25938 Contributors: Eep, Eugene, Janisk, Marisb, Normis, SacXs2, Sergejs, SergejsB
Manual:Interface/EoIP Source: http://wiki.mikrotik.com/index.php?oldid=25948 Contributors: Eugene, HarvSki, Huri, Janisk, Kirshteins, Marisb, Nest
Manual:Interface/Gre Source: http://wiki.mikrotik.com/index.php?oldid=25952 Contributors: Marisb, Nest
Manual:Interface/IPIP Source: http://wiki.mikrotik.com/index.php?oldid=25955 Contributors: Janisk, Kirshteins, Marisb, Nest
Manual:Interface/PPP Source: http://wiki.mikrotik.com/index.php?oldid=25959 Contributors: Marisb, Nest
Manual:Interface/PPPoE Source: http://wiki.mikrotik.com/index.php?oldid=25960 Contributors: Janisk, Marisb, Nest, Normis
Manual:Interface/PPTP Source: http://wiki.mikrotik.com/index.php?oldid=25091 Contributors: Janisk, Marisb, Sergejs, SergejsB
Manual:Interface/L2TP Source: http://wiki.mikrotik.com/index.php?oldid=25958 Contributors: Becs, Janisk, Marisb, Nest
Manual:Interface/SSTP Source: http://wiki.mikrotik.com/index.php?oldid=25092 Contributors: Janisk, Marisb, Normis
Manual:Interface/OVPN Source: http://wiki.mikrotik.com/index.php?oldid=25957 Contributors: Marisb, Nest
Manual:BCP bridging (PPP tunnel bridging) Source: http://wiki.mikrotik.com/index.php?oldid=22208 Contributors: Janisk, Marisb, Megis, SergejsB
Manual:MLPPP over single and multiple links Source: http://wiki.mikrotik.com/index.php?oldid=25654 Contributors: Marisb, Megis, Normis
Manual:Interface/VPLS Source: http://wiki.mikrotik.com/index.php?oldid=25391 Contributors: Janisk, Marisb

Image Sources, Licenses and Contributors 91
Image Sources, Licenses and Contributors

Image:Version.png Source: http://wiki.mikrotik.com/index.php?title=File:Version.png License: unknown Contributors: Normis
Image:image12001.gif Source: http://wiki.mikrotik.com/index.php?title=File:Image12001.gif License: unknown Contributors: Andriss
Image:Icon-note.png Source: http://wiki.mikrotik.com/index.php?title=File:Icon-note.png License: unknown Contributors: Marisb, Route
File:Slash32.png Source: http://wiki.mikrotik.com/index.php?title=File:Slash32.png License: unknown Contributors: Janisk
Image:Icon-warn.png Source: http://wiki.mikrotik.com/index.php?title=File:Icon-warn.png License: unknown Contributors: Marisb, Route
file:ipsec-road-warrior.png Source: http://wiki.mikrotik.com/index.php?title=File:Ipsec-road-warrior.png License: unknown Contributors: Marisb
file:site-to-site-ipsec-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Site-to-site-ipsec-example.png License: unknown Contributors: Marisb
file:ipsec-l2tp-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Ipsec-l2tp-example.png License: unknown Contributors: Marisb
File:eoip-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Eoip-example.png License: unknown Contributors: Marisb
File:site-to-site-gre-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Site-to-site-gre-example.png License: unknown Contributors: Marisb
Image:ipip-sample.png Source: http://wiki.mikrotik.com/index.php?title=File:Ipip-sample.png License: unknown Contributors: Marisb
Image:pppoe-discovery.png Source: http://wiki.mikrotik.com/index.php?title=File:Pppoe-discovery.png License: unknown Contributors: Marisb
File:pppoe-apex.png Source: http://wiki.mikrotik.com/index.php?title=File:Pppoe-apex.png License: unknown Contributors: Marisb
File:pptp-rem-offoce.png Source: http://wiki.mikrotik.com/index.php?title=File:Pptp-rem-offoce.png License: unknown Contributors: Marisb
File:site-to-site-pptp-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Site-to-site-pptp-example.png License: unknown Contributors: Marisb
File:l2tp-rem-office.png Source: http://wiki.mikrotik.com/index.php?title=File:L2tp-rem-office.png License: unknown Contributors: Marisb
File:site-to-site-l2tp-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Site-to-site-l2tp-example.png License: unknown Contributors: Marisb
File:sstp-how-works.png Source: http://wiki.mikrotik.com/index.php?title=File:Sstp-how-works.png License: unknown Contributors: Marisb
File:sstp-rem-office.png Source: http://wiki.mikrotik.com/index.php?title=File:Sstp-rem-office.png License: unknown Contributors: Marisb
File:site-to-site-sstp-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Site-to-site-sstp-example.png License: unknown Contributors: Marisb
Image:BCP.png Source: http://wiki.mikrotik.com/index.php?title=File:BCP.png License: unknown Contributors: SergejsB
Image:BCP10.png Source: http://wiki.mikrotik.com/index.php?title=File:BCP10.png License: unknown Contributors: SergejsB
File:mlppp.png Source: http://wiki.mikrotik.com/index.php?title=File:Mlppp.png License: unknown Contributors: Marisb

Mikrotik - VPN

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Mikrotik - VPN

Загружено:

Авторское право:

Доступные форматы

Contents

arp (disabled | enabled | proxy-arp | reply-only; Address Resolution Protocol mode

mtu (integer; Default: 1500) Layer3 Maximum transmission unit

name (string; Default: ) Interface name

use-service-tag (yes | no; Default: ) 802.1ad compatible Service Tag

Configuration for R2 and R4 is shown below:

[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no

[admin@MikroTik] /interface vlan> print

[admin@MikroTik] /interface vlan> add name=VLAN2 vlan-id=2 interface=ether1 disabled=no

[admin@MikroTik] /interface vlan> print

The next step is to assign IP addresses to the VLAN interfaces.

[admin@MikroTik] ip address> add address=10.10.10.3/24 interface=VLAN2

[admin@MikroTik] ip address> add address=10.10.10.5/24 interface=VLAN2

'''Ping from R2 to R4:'''

[admin@MikroTik] ip address> /ping 10.10.10.5

10.10.10.5 64 byte ping: ttl=255 time=4 ms

10.10.10.5 64 byte ping: ttl=255 time=1 ms

2 packets transmitted, 2 packets received, 0% packet loss

round-trip min/avg/max = 1/2.5/4 ms

[admin@MikroTik] ip address> /ping 10.10.10.3

[admin@MikroTik] ip address> /ping 10.10.10.2

Create trunks and implement routing between VLANs

Add IP addresses to VLANs:

RouterOS /32 and IP unnumbered addresses

/ip address add address=10.22.0.1/24 interface=ether1

/ip address add address=10.23.0.1/24 interface=ether1

[ Top | Back to Content ]

Authentication Header (AH)

Encapsulating Security Payload

/queue interface set [find] queue=only-hardware-queue

/system resource irq rps disable [find]

/system resource irq

disable connection tracking

Internet Key Exchange Protocol

Diffie-Hellman Group Name Reference

Group 1 768 bit MODP group RFC 2409

Group 2 1024 bits MODP group RFC 2409

Group 3 EC2N group on GP(2^155) RFC 2409

Group 4 EC2N group on GP(2^185) RFC 2409

Group 5 1536 bits MODP group RFC 3526

comment (string; Default: )

name (string; Default: )

auth-method (pre-shared-key | Authentication method:

comment (string; Default: ) Short description of the peer.

dh-group (ec2n155 | ec2n185 | modp1024 | Diffie-Hellman group (cipher strength)

enc-algorithm (3des | aes-128 | aes-192 | Encryption algorithm.

proposal-check (claim | exact | obey | Phase 2 lifetime check logic:

xauth-login (string; Default: ) initiator (client) XAuth username

xauth-password (string; Default: ) initiator (client) XAuth password

[admin@PoETik] /ip ipsec key> print

import (file-name; name) Import key from file.

comment (string; Default: ) Short description of the policy

dst-address (IP/IPv6 prefix; Default: Destination address to be matched in packets.

manual-sa (string | none; Default: none) Name of the manual SA template

src-address (ip/ipv6 prefix; Default: Source IP prefix

src-port (any | integer:0..65535; Default: any) Source Port of the packet

ph2-state (expired | no-phase2 | established) Indication of the progress of key establishing.

/ip ipsec policy dump-kernel-policies

[admin@test-host] >/log print

name (string; Default: )

comment (string; Default: )

auth-algorithms (md5|sha1|null|sha256|sha512; Default: sha1) Allowed

comment (string; Default: ) Short

disabled (yes | no; Default: no) Whether