Mikrotik VPN

Mikrotik
VPN
PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Sat, 12 Feb 2011 02:03:40 UTC
Manual:BCP bridging (PPP tunnel bridging) 1
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. PPP bridging does NOT require any IP addresses,
but when normal PPP is necessary, specify local and remote addresses on server side as normally.
/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:IP/IPsec 9
Manual:IP/IPsec
Applies to RouterOS: v4.5 +
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 IP network.
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.
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 (ESP)

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 AS. Instead of having just a header, it divides its fields into three
components:
• ESP Header - Comes before the encrypted data and its placement depends on whether ESP is used in transport
mode or tunnel mode.
Manual:IP/IPsec 10
• 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 traler 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
Internet Key Exchange (IKE)

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.
• 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).
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.
Manual:IP/IPsec 11
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 Name Reference

Group
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 12
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.
Property Description
address (IP[/Netmask]:port; Default: Address prefix. If remote peer's address matches this prefix, then this peer configuration is used in
0.0.0.0/32:500) 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
certificate (string; Default: ) Name of a certificate on the local side (signing packets; the certificate must have private key).
Applicable if RSA signature authentication method is used.
dh-group (ec2n155 | ec2n185 | modp1024 | Diffie-Hellman group (cipher strength)

modp1536 | modp768; Default: modp1024)
dpd-interval (disable-dpd | time; Default: Dead peer detection interval. If set to disable-dpd, dead peer detection will not be used.
disable-dpd)
dpd-maximum-failures (integer: 1..100; Maximum count of failures until peer is considered to be dead.
Default: 5)
enc-algorithm (3des | aes-128 | aes-192 | Encryption algorithm. blowfish, camellia algorithms are supported starting from v4.5.
aes-256 | des | blowfish | camellia-128 |
camellia-192 | camellia-256; Default: 3des)
exchange-mode (aggressive | base | main; Different ISAKMP phase 1 exchange modes according to RFC 2408. Do not use other modes then
Default: main) main unless you know what you are doing.
generate-policy (yes | no; Default: no) Allow this peer to establish SA for non-existing policies. Such policies are created dynamically for
the lifetime of SA. This way it is possible, 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.
hash-algorithm (md5 | sha1; Default: md5) Hashing algorithm. SHA (Secure Hash Algorithm) is stronger, but slower.
lifebytes (Integer: 0..4294967295; Default: Phase 1 lifetime: specifies how much bytes can be transferred before SA is discarded. If set to 0, SA
0) will not be discarded due to byte count excess.
lifetime (time; Default: 1d) Phase 1 lifetime: specifies how long the SA will be valid
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 signes 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.
proposal-check (claim | exact | obey | strict; Phase 2 lifetime check logic:

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 for authenticating the remote side (validating packets; no private key required).
Applicable if RSA signature authentication method is used
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; Default: yes) Specifies whether to send initial IKE information or wait for remote side.
Manual:IP/IPsec 13
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.
Policy
Sub-menu: /ip ipsec policy
Policy table is needed 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
dst-address (IP/Mask:Port; Default: Destination prefix and port.

0.0.0.0/32:any)
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
priority (Integer: -2147483646..2147483647; Policy ordering classificator (signed integer). Larger number means higher priority.
Default: 0)
proposal (string; Default: default) Name of proposal information 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; Default: 0.0.0.0) SA destination IP address (remote peer).
sa-src-address (IP; Default: 0.0.0.0) SA source IP address (local peer).
src-address (IP/Mask:Port; Default: Source IP prefix

0.0.0.0/32:any)
tunnel (yes | no; Default: no) Specifies whether to use tunnel mode
Command /ip ipsec policy print stats will show current status of the policy. Additional read-only parameters will be
printed.
Manual:IP/IPsec 14
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.
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.
Proposal settings
Sub-menu: /ip ipsec proposal
Proposal information that will be sent by IKE daemon to establish SAs for this policy. Configured proposals are set
in policy configuration.
auth-algorithms (md5|sha1|null; Default: sha1) Allowed algorithms for authorization.
enc-algorithms (null|des|3des|aes-128|aes-192|aes-256|blowfish|camellia-128 | camellia-192 | Allowed algorithms and key lengths to

camellia-256 | twofish; Default: 3des) use for SAs.
lifetime (time; Default: 30m) How long to use SA before throwing it

out.
pfs-group (ec2n155 | ec2n185 | modp1024 | modp1536 | modp768 | ...; Default: modp1024) Diffie-Helman group used for Perfect
Forward Secrecy.
Installed SA
Sub-menu: /ip ipsec installed-sa
This facility provides information about installed security associations including the keys.
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
Manual:IP/IPsec 15
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) Local ISAKMP SA address.
remote-address (IP) Peer's IP address.
side (initiator | responder) Shows which side initiated the Phase1 negotiation.
state (string) State of phase 1 negotiation with the peer.
Statistics
Sub-menu: /ip ipsec statistics
(needs editing)
Application Examples
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.
Manual:IP/IPsec 16
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

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:500 auth-method=pre-shared-key secret="test"
Office2 router:
/ip ipsec peer

add address=192.168.90.1/32: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.
Manual:IP/IPsec 17
Office1 router:
/ip ipsec policy

add src-address=10.1.202.0/24:any dst-address=10.1.101.0/24: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:any dst-address=10.1.202.0/24: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.
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.
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
[Back to Content]
Manual:Interface/EoIP 18
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 tunne 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 | proxy-arp | Address Resolution Protocol mode

reply-only; Default: enabled)
l2mtu (integer; Default: ) Layer2 Maximum transmission unit. Not configurable for EoIP. Read more>>
mac-address (MAC; Default: ) Media Access Control number of an interface. The address numeration authority allows to use MAC
addresses in the range from 00:00:5E:80:00:00 - 00:00:5E:FF:FF:FF freely
mtu (integer; Default: 1500) Layer3 Maximum transmission unit
name (string; Default: ) Interface name
remote-address (IP; Default: ) IP address of remote end of EoIP tunnel
tunnel-id (integer: 65536; Default: ) Unique tunnel identifier, which must match other side of the tunnel
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 mark the address as locally administered address, assigned by network administrator,
and use any MAC address, you just need to ensure they are unique between the hosts connected to one bridge.
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 cower 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.
[Back to Content]
Manual:Interface/IPIP 21
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 based, support this protocol. This
protocol makes multiple network schemes possible.
IP tunneling protocol adds the following possibilities to a network setups:
• to tunnel Intranets over the Internet
• to use it instead of source routing
Properties
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 another 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

1.1.1.2 64 byte ping: ttl=64 time=24 ms
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 19/21.0/24 ms
[admin@MikroTik] interface ipip>
[Back to Content]
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
Manual:Interface/L2TP 24
add-default-route (yes | no; Default: no) Whether to add L2TP 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 L2TP 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
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 >>
name (string; Default: ) Descriptive name of the interface.
password (string; Default: "") Password used for authentication.
profile (name; Default: default-encryption) Used PPP profile.
user (string; Default: ) User name used for authentication.
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 \
\... connect-to=10.1.101.100 disabled=no
[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
allow=pap,chap,mschap1,mschap2
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
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
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).
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.
Sub-menu: /interface l2tp-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.
max-mru (integer; Default: 1460) Maximum Receive Unit. Max packet size that PPTP interface will be able to receive 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 >>
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
Monitor command can be used to monitor status of the tunnel on both client and server.
[admin@dzeltenais_burkaans] /interface l2tp-client> monitor 0

status: "connected"
uptime: 7h24m18s
idle-time: 6h21m4s
encoding: "MPPE128 stateless"
mtu: 1460
mru: 1460
Read-only properties
status () Current L2TP status. Value other than "connected" indicates that there are some problems estabising 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
uptime (time) Elapsed time since tunnel was established.
idle-time Elapsed time since last activity on the tunnel.

(time)
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 L2TP 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=l2tp 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=l2tp 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 L2TP 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 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
authentication: mschap2
[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
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
# NAME MTU MAC-ADDRESS ARP
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 L2TP
The following is an example of connecting two Intranets using L2TP 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 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
local-address=172.16.1.1 remote-address=172.16.1.2 routes="10.1.101.0/24 172.16.1.1 1"
[admin@RemoteOffice] ppp secret> print detail
Flags: X - disabled
0 name="Home" service=l2tp caller-id="" password="123" profile=default
local-address=172.16.1.1 remote-address=172.16.1.2 routes=="10.1.101.0/24 172.16.1.1 1"
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 pptp 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="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 l2tp-client>
Now we need to add route to reach local network behind Home router
[admin@RemoteOffice] /ip route> add dst-address=10.1.202.0/24 gateway=172.16.1.2
After tunnel is established and routes are set, you should be able to ping remote network.
Read More
• BCP (Bridge Control Protocol)
• Disable IpSec used with L2TP on Windows [1]
[Back to Content]
References
[1] http:/ / support. microsoft. com/ default. aspx?scid=kb%3Ben-us%3B258261. php
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.
Manual:Interface/PPTP 30
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
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.
password (string; Default: "") Password used for authentication.
profile (name; Default: default-encryption) Used PPP profile.
user (string; Default: ) User name used for authentication.
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
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).
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) Defines the time period (in seconds) after which the router is starting to send keepalive packets 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
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 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 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
encoding: "MPPE128 stateless"
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 Elapsed time since last activity on the tunnel.

(time)
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)
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).
[admin@RemoteOffice] /ppp secret> add name=Laptop service=pptp password=123

local-address=10.1.101.1 remote-address=10.1.101.100
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==""
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
[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
# NAME MTU MAC-ADDRESS ARP
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.101.0/24 172.16.1.1 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.202.0/24 gateway=172.16.1.2
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
[Back to Content]
Manual:Interface/VLAN 36
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
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>>
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
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK BROADCAST INTERFACE
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
'''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
[Back to Content]
References
[1] http:/ / standards. ieee. org/ getieee802/ download/ 802. 1Q-1998. pdf
Manual:TE Tunnels Example 42
Manual:TE Tunnels Example

Application example
Consider following setup:
IP Connectivity and LDP

R1
ether1 connects to R2, ether2 connects to R5
/system identity set name=R1
/interface bridge add name=lo0
/ip address
add address=10.255.1.1/32 interface=lo0
/routing ospf instance

set default router-id=10.255.1.1
/routing ospf network

add network=192.168.55.0/24 area=backbone
/mpls ldp
set enabled=yes lsr-id=10.255.1.1 transport-address=10.255.1.1
/mpls ldp interface

add interface=ether1
R2
/ip address


/mpls ldp
/mpls ldp interface

R3
/ip address


/mpls ldp
/mpls ldp interface

R4
/ip address


/mpls ldp
/mpls ldp interface

R5
/ip address


/mpls ldp
/mpls ldp interface

After OSPF and LDP setup ensure that ospf is working properly
[admin@R1] /routing ospf neighbor> print

0 instance=default router-id=10.255.1.5 address=192.168.55.17 interface=ether2
priority=1 dr-address=192.168.55.17 backup-dr-address=192.168.55.18
state="Full" state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=32m17s
1 instance=default router-id=10.255.1.2 address=192.168.55.2 interface=ether1

priority=1 dr-address=192.168.55.2 backup-dr-address=192.168.55.1
state="Full" state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=32m17s
[admin@R1] /routing ospf neighbor>
[admin@R1] /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 GATEWAY DISTANCE
0 ADS 0.0.0.0/0 10.1.101.1 0
1 ADC 10.1.101.0/24 10.1.101.9 ether3 0
2 ADC 10.255.1.1/32 10.255.1.1 lo0 0
3 ADo 10.255.1.2/32 192.168.55.2 110
4 ADo 10.255.1.3/32 192.168.55.2 110
5 ADo 10.255.1.4/32 192.168.55.17 110
6 ADo 10.255.1.5/32 192.168.55.17 110
7 ADC 192.168.55.0/30 192.168.55.1 ether1 0
8 ADo 192.168.55.4/30 192.168.55.2 110
9 ADo 192.168.55.8/30 192.168.55.2 110
192.168.55.17
10 ADo 192.168.55.12/30 192.168.55.17 110
11 ADC 192.168.55.16/30 192.168.55.18 ether2 0
[admin@R1] /ip route>
Also make sure MPLS forwarding-table has label bindings
[admin@R1] /mpls forwarding-table> print

Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-LABELS DESTINATION I NEXTHOP
0 expl-null
1 L 16 10.255.1.5/32 e 192.168.55.17
2 L 17 19 192.168.55.8/30 e 192.168.55.2
3 L 18 19 10.255.1.4/32 e 192.168.55.17
4 L 19 21 10.255.1.3/32 e 192.168.55.2
5 L 20 192.168.55.12/30 e 192.168.55.17
6 L 21 192.168.55.4/30 e 192.168.55.2
7 L 22 10.255.1.2/32 e 192.168.55.2
VPLS tunnel
ether4 goes to CE routers
R1
/interface bridge add name=vpn
/interface vpls
add remote-peer=10.255.1.3 vpls-id=3:3
/interface bridge port

add interface=ether4 bridge=vpn
add interface=vpls1 bridge=vpn
R3
/interface bridge add name=vpn
/interface vpls
add remote-peer=10.255.1.1 vpls-id=3:3
/interface bridge port

add interface=ether4 bridge=vpn
add interface=vpls1 bridge=vpn
Make sure that VPLS tunnel is established and running
[admin@R1] /interface vpls> monitor 0 once

remote-label: 23
local-label: 23
remote-status:
transport: 10.255.1.3/32
transport-nexthop: 192.168.55.2
imposed-labels: 21,23
[admin@R1] /interface vpls>

TE Support
Traffic engineering needs RSVP protocol enabled on head end, tail end and forwarding routers. And additional setup
to use CSPF.
In our example all routers have the same configuration:
# set up CSPF
set default mpls-te-area=backbone mpls-te-router-id=lo0
# add interfaces on which to run RSVP

/mpls traffic-eng interface
add interface=ether1 bandwidth=10Mbps
add interface=ether2 bandwidth=10Mbps
TE Tunnels
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)
Manual:Interface/VPLS 48
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; Default: Address Resolution Protocol

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; Default: no) Specifies whether to detect if interface is running or not. If set to no interface will
always have 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; Default: Pseudowire type.

raw-ethernet)
remote-peer (IP; Default: ) IP address of remote peer.
vpls-id (AsNum | AsIp; Default: ) Unique number that identifies VPLS tunnel.
Monitoring
Command /interface vpls monitor [id] will display current VPLS interface status
Available read only properties:
mm ()
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; If set to none VPLS interface is not added to bridge ports.
Default: none)
bridge-cost (integer;
Default: 50)
bridge-horizon (none | If set to none bridge horizon will not be used.

integer; Default: none)
comment (string; Short description of the item

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

Default: 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 from BGP
(AsNum | AsIp; Default: ) NLRI.
name (string; Default: )
route-distinguisher Specifies value that gets attached to VPLS NLRI so that receiving routers can distinguish advertisements that may
(AsNum | AsIp; Default: ) 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: Unique site identifier. Each site must have unique site-id.
1)
Cisco Style BGP VPLS

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

integer; Default: none)
comment (string; Short description of the item

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

Default: 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 from BGP
(AsNum | AsIp; Default: ) NLRI.
l2router-id (IP; Default:

0.0.0.0)
name (string; Default: )
route-distinguisher Specifies value that gets attached to VPLS NLRI so that receiving routers can distinguish advertisements that may
(AsNum | AsIp; Default: ) 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.
vpls-id (integer; Default: Unique number that identifies VPLS tunnel.

)
See also
• MPLSVPLS
• BGP based VPLS
• Cisco style BGP based VPLS
[Back to Content]
Article Sources and Contributors 51
Article Sources and Contributors

Manual:BCP bridging (PPP tunnel bridging) Source: http://wiki.mikrotik.com/index.php?oldid=16955 Contributors: Janisk, Marisb, Megis, SergejsB
Manual:IP/IPsec Source: http://wiki.mikrotik.com/index.php?oldid=20172 Contributors: Eep, Eugene, Janisk, Marisb, Normis, SacXs2, SergejsB
Manual:Interface/EoIP Source: http://wiki.mikrotik.com/index.php?oldid=17771 Contributors: Eugene, HarvSki, Huri, Janisk, Marisb
Manual:Interface/IPIP Source: http://wiki.mikrotik.com/index.php?oldid=19955 Contributors: Janisk, Kirshteins, Marisb
Manual:Interface/L2TP Source: http://wiki.mikrotik.com/index.php?oldid=20160 Contributors: Janisk, Marisb
Manual:Interface/PPTP Source: http://wiki.mikrotik.com/index.php?oldid=17223 Contributors: Janisk, Marisb
Manual:Interface/VLAN Source: http://wiki.mikrotik.com/index.php?oldid=19562 Contributors: Janisk, Kirshteins, Marisb
Manual:TE Tunnels Example Source: http://wiki.mikrotik.com/index.php?oldid=19203 Contributors: Marisb
Manual:Interface/VPLS Source: http://wiki.mikrotik.com/index.php?oldid=17227 Contributors: Janisk, Marisb

Image Sources, Licenses and Contributors 52
Image Sources, Licenses and Contributors

Image:Version.png Source: http://wiki.mikrotik.com/index.php?title=File:Version.png License: unknown Contributors: Normis
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
Image:Icon-warn.png Source: http://wiki.mikrotik.com/index.php?title=File:Icon-warn.png License: unknown Contributors: Marisb, Route
Image:Icon-note.png Source: http://wiki.mikrotik.com/index.php?title=File:Icon-note.png License: unknown Contributors: Marisb, Route
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:eoip-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Eoip-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
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: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
Image:image12001.gif Source: http://wiki.mikrotik.com/index.php?title=File:Image12001.gif License: unknown Contributors: Andriss
File:Slash32.png Source: http://wiki.mikrotik.com/index.php?title=File:Slash32.png License: unknown Contributors: Janisk
File:mpls-te-example.png Source: http://wiki.mikrotik.com/index.php?title=File:Mpls-te-example.png License: unknown Contributors: Marisb

Mikrotik VPN

Загружено:

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

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

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

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

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

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

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

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

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

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

Mikrotik VPN

Загружено:

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

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

Mikrotik

Manual:BCP bridging (PPP tunnel bridging)

BCP Configuration (CLI)

/interface bridge add name=bridge_local protocol-mode=rstp

Now we can assign local and public addresses to proper interfaces.

/ip address add address=192.168.88.1/24 interface=bridge_local

/ppp profile add name=ppp_bridging bridge=bridge_local use-encryption=yes

/interface pptp-server server set enabled=yes mrru=1600

/interface bridge add name=bridge_local protocol-mode=rstp

Assign local and public addresses to proper interfaces.

/ip address add address=192.168.88.254/24 interface=bridge_local

/ppp profile add name=ppp_bridging bridge=bridge_local use-encryption=yes

BCP Configuration (Winbox)

• Add Bridge Port,

• Add Bridge MAC-address,

• Create PPP profile for bridging,

• Add PPP client,

Encapsulating Security Payload (ESP)

Internet Key Exchange (IKE)

Diffie-Hellman 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

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

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

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

dst-address (IP/Mask:Port; Default: Destination prefix and port.

sa-dst-address (IP; Default: 0.0.0.0) SA destination IP address (remote peer).

sa-src-address (IP; Default: 0.0.0.0) SA source IP address (local peer).

src-address (IP/Mask:Port; Default: Source IP prefix

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

auth-algorithms (md5|sha1|null; Default: sha1) Allowed algorithms for authorization.

enc-algorithms (null|des|3des|aes-128|aes-192|aes-256|blowfish|camellia-128 | camellia-192 | Allowed algorithms and key lengths to

lifetime (time; Default: 30m) How long to use SA before throwing it

sa-type (ah | all | esp; Default: all) Specifies SA types to flush.

local-address (IP) Local ISAKMP SA address.

remote-address (IP) Peer's IP address.

state (string) State of phase 1 negotiation with the peer.

Site to Site IpSec Tunnel

/ip firewall nat

/ip firewall nat

IpSec Peer's config

/ip ipsec peer

/ip ipsec peer

Policy and proposal

[admin@MikroTik] /ip ipsec proposal> print

/ip ipsec policy

/ip ipsec policy

/ip firewall nat

/ip firewall nat

arp (disabled | enabled | proxy-arp | Address Resolution Protocol mode

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

name (string; Default: ) Interface name

remote-address (IP; Default: ) IP address of remote end of EoIP tunnel

[admin@Our_GW] interface eoip> add name="eoip-remote" tunnel-id=0 \

... and on Remote router

[admin@Remote] interface eoip> add name="eoip" tunnel-id=0 \

[admin@Remote] interface eoip>

[admin@Our_GW] interface bridge> add

... and Remote router:

[admin@Remote] interface bridge> add

local-address (IP; Default: ) IP address on a router that will be used by IPIP