Mikrotik - VPN - Download as PDF File (.pdf), Text File (.txt) or read online. ... Creating Certificates All certificate...
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
1
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.
Manual:Interface/VLAN
1
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.
Manual:Interface/VLAN
2
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 interface=vlan1
If any packet is sent over "vlan2" interface, two vlan tags will be added to ethernet header - "11" and "12".
Properties Property reply-only;; arp (disabled | enabled | proxy-arp | reply-only
Description Address Resolution Protocol mode
Default: enabled) enabled) name; Default: ) interface (name;
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>>
1500 ) mtu (integer ; Default: 1500)
Layer3 Maximum transmission unit
name (string; string; Default: )
Interface name
use-service-tag ( yes yes | no; no; Default: )
802.1ad compatible Service Tag
4095; Default: 1) vlan-id (integer: 4095;
Vir tu tu al al LA LAN id iden ti tif ie ier or or ta tag th th at at is is us used to to di disting ui uish VL VLANs. Mu Must be be eq equ al al fo for al all computers that belong to the same VLAN.
Manual:Interface/VLAN
3
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 # 0 R
NAME
MTU
VLAN2
1500
ARP enabled
VLAN-ID INTERFACE 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 # 0 R
NAME
MTU
VLAN2
1500
ARP enabled
VLAN-ID INTERFACE 2
ether1
Manual:Interface/VLAN
4
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 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
'''From R4 to R2:''' [admin@MikroTik] ip address> /ping 10.10.10.3 10.10.10.3 64 byte ping: ttl=255 time=6 ms 10.10.10.3 64 byte ping: ttl=255 time=1 ms 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 1/3.5/6 ms
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.
Manual:Interface/VLAN
'''From R2 to R1:''' [admin@MikroTik] ip address> /ping 10.10.10.2 10.10.10.2 ping timeout 10.10.10.2 ping timeout 3 packets transmitted, 0 packets received, 100% packet loss
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 i nter-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 name=VLAN3 vlan-id=3 interface=ether1 disabled=no add name=VLAN4 vlan-id=4 interface=ether1 disabled=no
5
Manual:Interface/VLAN
Add IP addresses to VLANs: /ip address add address=10.10.20.1/24 interface=VLAN2 add address=10.10.30.1/24 interface=VLAN3 add address=10.10.40.1/24 interface=VLAN4
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
6
Manual:IP/IPsec
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:
7
Manual:IP/IPsec
€ 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]
8
Manual:IP/IPsec
€ 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
9
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.
Property
Description
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.
Property address ( IP/IPv6 Prefix; Default: 0.0.0.0/0)
Description 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
dh-group (ec2n155 | ec2n185 | modp1024 |
12
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.
hash-algorithm (md5 | sha1 | sha256 |
€
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
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 | strict ; Default: obey)
Phase 2 lifetime check logic: €
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 str in g (in case pr e-sh ared 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
1024-bit
R pub
Commands
Manual:IP/IPsec
14
Property export-pub-key ( file-name;
Description 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. Property
Description
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)
C reates a template and assigns it to specified po licy gro up 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)
tunnel ( yes | no; Default: no)
€
protocol - protocol to match, if set to all, then any protocol is accepted
€
proposal - SA parameters used for this template.
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. Property
Description
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 man y ou tgoing packets wer e encryp ted (ESP) and/or verified ( AH) b y the p olicy.
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 Property
Description
name (string; Default: ) 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. Property auth-algorithms (md5|sha1|null|sha256|sha512 ; Default: sha1)
Description 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 (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 Default: aes-128-cbc)
Allowed ; algorithms 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. Property
Description
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. Property
Description
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: Property
Description
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: Property local-address (ip/ipv6
Description 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 n eg otiatio n with the peer . For examp le wh en ph ase1 and phase 2 are neg otiated 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
Property
Description
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 f oun d i.e. Either in bou nd SPI, add ress, o r IPsec p rotoco l at SA is wr ong
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 fou nd for states, e.g . Inb oun d SAs are co rrect but no SP is f ound
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
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
21
Manual:IP/IPsec
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:
22
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
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 add address=10.1.202.1/24 interface=ether2 /ip route add gateway=192.168.90.254 /ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade
Office2 router: /ip address add address=192.168.80.1/24 interface=ether1 add address=10.1.101.1/24 interface=ether2 /ip route add gateway=192.168.80.254 /ip firewall nat
24
Manual:IP/IPsec
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.
25
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
IP Connectivity On the server: /ip address add address=1.1.1.1/24 interface=ether1 /ip route add gateway=1.1.1.2
On the clients router: /ip address add address=2.2.2.2/24 interface=ether1 add address=10.5.8.0/24 interface=ether2 /ip route add gateway=2.2.2.1 /ip firewall net add chain=srcnat action=masquerade out-interface=ether1
On the client: /ip address add address=10.5.8.120/24 interface=ether1
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
27
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 [ Top | Back to Content ]
Manual:Interface/EoIP
29
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 Property
Description
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: ) mtu (integer ; Default: 1500) name (string; 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 Layer3 Maximum transmission unit Interface name
Manual:Interface/EoIP
30
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
Manual:Interface/EoIP
31
[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 Flags: X - disabled, R - running 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 Flags: X - disabled, R - running 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 Flags: X - disabled, R - running 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
Manual:Interface/EoIP
1
32
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. [ Top | Back to Content ]
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 Property
Description
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: )
Manual:Interface/Gre
33
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:
Manual:Interface/Gre
/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. [ Top | Back to Content ]
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
34
Manual:Interface/IPIP
35
Property
Description
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: ) mtu (integer ; Default: 1500)
IP address on a router that will be used by IPIP tunnel Layer3 Maximum transmission unit
name (string; Default: )
Interface name
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 Flags: X - disabled, R - running #
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:
Manual:Interface/IPIP
36
[admin@MikroTik] interface ipip> add local-address=22.63.11.6 remote-address=10. 0.0.1 [admin@MikroTik] interface ipip> print Flags: X - disabled, R - running #
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 1.1.1.2 64 byte ping: ttl=64 time=19 ms 1.1.1.2 64 byte ping: ttl=64 time=20 ms 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 19/21.0/24 ms [admin@MikroTik] interface ipip>
[ Top | Back to Content ]
Manual:Interface/PPP Applies to RouterOS: v5, v6+
Summary Standards: RFC 1661 Package: ppp
PPP Client Sub-menu: /interface ppp-client
Manual:Interface/PPP
37
Property add-default-route ( yes | no; Default: no)
Description 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 in ter face will be ab le to receive with out packet fragmentation.
max-mtu (integer ; Default: 1500)
Maximum Transmission Unit. Max packet size that PPP interface will be able to send without packet fragmentation.
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.
[ Top | Back to Content ]
Manual:Interface/PPPoE
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)
38
Manual:Interface/PPPoE
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
39
Manual:Interface/PPPoE
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
40
Manual:Interface/PPPoE
41
Terminate-Request packet. More detailed description of PPPoE protocol can be found in RFC 2516
Used Packet Types Packet PADI
Description 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.
Manual:Interface/PPPoE
42
PPPoE Client Sub-menu: /interface pppoe-client
Properties Property ac-name (string; Default: "")
Description Access C oncentrato r name, th is may be left blank and th e clien t will con nect 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 tunnel. Read more >>
name (string; Default: pppoe-out[i])
n ame of th e PPPoE in terf ace, generated by RouterOS if no t 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)
en able/disable g etting DNS settin gs from th e peer
user (string; Default: "")
username used for authentication
Status Command /interface pppoe-client monitor will display current PPPoE status. Available read only properties: Property
Description
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
Manual:Interface/PPPoE
43
service-name (string)
used service name
status (string)
current link status. Available values are:
uptime (time)
€
dialing,
€
verifying password...,
€
connected,
€
disconnected.
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
Available read only properties: Property service (string)
Description Service name configured on server
mac-address ( MAC ) Mac address of detected server ac-name (string)
n ame of th e Access C on cen tr ato r
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 Flags: X - disabled, R - running 0
R name="pppoe-out1 " max-mtu=1480 max-mru=1480 mrru=disabled interface=ether1 user="user" password="passw d" profile=default service-name="tes tSN" ac-name="" add-default-rout e=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
Manual:Interface/PPPoE
44
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 Property
Description
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.
Manual:Interface/PPPoE
45
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.
Manual:Interface/PPPoE
46
Property Description € encoding encoding (read-only: (read-only: text) text) - encryption encryption and encoding encoding (if asymmetric, asymmetric, separated separated with with '/') being used used in this connection € mru (read (read-on -only: ly: inte integer ger)) - client client's 's MRU MRU € mtu (rea (read-o d-only nly:: intege integer) r) - clien client's t's MTU MTU € name name (na (name me)) - inte interf rfac acee name name € remote-addre remote-address ss (read-only: (read-only: MAC MAC address) address) - MAC address address of of the connected connected client client € service service (name) (name) - name of the service service the user is is connected connected to € uptime (read-only: (read-only: time) - shows how long long the client is connecte connected d € user (name) (name) - the name of the the connected connected user user (must be present present in the user user darabase darabase anyway) anyway) Example To view the currently connected users: [admin@MikroTik] interface pppoe-server> print Flags: X - disabled, D - dynamic, R - running # 0
NAME
USER
DR user
SERVICE
REMOTE... ENCODING
UPTIME
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>
Application Examples 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:
Manual:Interface/PPPoE
47
First of all, the wireless interface should be configured: [admin@PPPoE-Server] interface wireless> set 0 mode=ap-bridge \ frequency=2442 frequency=244 2 band=2.4ghz-b/g band=2.4ghz-b /g ssid=mt disabled=no [admin@PPPoE-Server] interface wireless> print Flags: X - disabled, R - running 0 X
name="wlan1" mtu=1500 mac-address=00:0C:42:18:5 mac-address= 00:0C:42:18:5C:3D C:3D arp=enabled interface-type=Atheros interface-ty pe=Atheros AR5413 mode=ap-bridge mode=ap-bridg e ssid="mt" frequency=2442 frequency=24 42 band=2.4ghz-b/g band=2.4ghz- b/g scan-list=default scan-list=def ault antenna-mode=ant-a antenna-mode= ant-a wds-mode=disabled wds-mode=di sabled wds-default-bridge=none wds-default- bridge=none wds-ignore-ssid=no wds-ignore-s sid=no default-authentication=yes default-authe ntication=yes default-forwarding=yes default-forw arding=yes default-ap-tx-limit=0 default-ap-tx -limit=0 default-client-tx-limit=0 default-clien t-tx-limit=0 hide-ssid=no security-profile=default security-pro file=default compression=no compression=n o
[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 Flags: X - disabled, I - invalid, D - dynamic #
ADDRESS
NETWORK
BROADCAST
INTERFACE
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] [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...
Manual:Interface/PPPoE
48
0 ADC
10.1.0.0/24
1 A S
0.0.0.0/0
10.1.0.3 r 10.1.0.1
0
Local
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 Flags: X - disabled, R - running # 0
NAME R Local
MTU
MAC-ADDRESS
ARP
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>
Manual:Interface/PPPoE
49
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 >> [ Top | Back to Content ]
References [1] http:/ / www.raspppoe.com/
Manual:Interface/PPTP
50
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 Property
Description
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) max-mru (integer ; Default: 1460)
Whether interface is disabled or not. By default it is disabled 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.
Manual:Interface/PPTP
mrru (disabled | integer ; Default: disabled)
51
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: ) password (string; Default: "")
Descriptive name of the interface. 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 Flags: X - disabled, R - running 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 allow=pap,chap,mschap1,mschap2
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
Manual:Interface/PPTP
52
Property
Description
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 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 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
Manual:Interface/PPTP
53
Property
Description
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
Application Examples 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>
Manual:Interface/PPTP
54
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 keepalive-timeout: 30 default-profile: default [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 Flags: X - disabled, R - running #
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.
Manual:Interface/PPTP
55
Site-to-Site PPTP The following is an example of connecting two Intranets using PPTP tunnel over the Internet. Consider following setup
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. First step is to create a user [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" [admin@RemoteOffice] /ppp secret> print detail 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"
[admin@RemoteOffice] /ppp secret>
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 authentication: mschap2 keepalive-timeout: 30 default-profile: default [admin@RemoteOffice] /interface pptp-server server>
Manual:Interface/PPTP
[admin@Home] /interface pptp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no [admin@Home] /interface pptp-client> print Flags: X - disabled, R - running 0
name="pptp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connect-to=192.16 8.80.1 user="Home" password="123" profile=default-encryption add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2
[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 € http:/ / www.ietf.org/ rfc/ rfc3078.txt?number=3078 € http:/ / www.ietf.org/ rfc/ rfc3079.txt?number=3079 [ Top | 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.
56
Manual:Interface/L2TP
57
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 Property add-default-route ( yes | no; Default: no)
Description 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)
Maximu m Receive Unit. Max packet size that L2 TP in terface will be able to receive withou t packet fragmentation.
max-mtu (integer ; Default: 1460)
Maximu m Transmission Un it. 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 >>
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 Flags: X - disabled, R - running
Manual:Interface/L2TP
0
58
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 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 l2tp-server server Properties Property authentication ( pap | chap |
Description 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) max-mru (integer ; Default: 1460)
Defines whether L2TP server is enabled or not. 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: 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
Manual:Interface/L2TP
59
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 Property status ()
Description Cu rrent L2 TP status. Valu e other th an "conn ected" ind icates that there are some prob lem s establishin g tun nel. €
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 (time)
Elapsed time since last activity on the tunnel.
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
Manual:Interface/L2TP
60
Application Examples 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 any 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 from 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
Manual:Interface/L2TP
61
default-profile: default-encryption [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 Flags: X - disabled, R - running #
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 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. Consider following setup:
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. First step is to create a user
Manual:Interface/L2TP
62
[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.202.0/24 172.16.1.2 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.202.0/24 172.16.1.2 1"
[admin@RemoteOffice] /ppp secret>
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 authentication: mschap2 default-profile: default-encryption [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 Flags: X - disabled, R - running 0 R
name="l2tp-out1" max-mtu=1460 max-mru=1460 mrru=disabled connect-to=192.16 8.80.1 user="Home" password="123" profile=default-encryption add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2
[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 € BCP (Bridge Control Protocol) € Disable IpSec used with L2TP on Windows
[1]
€ MikroTik RouterOS and Windows XP IPSec/L2TP [ Top | Back to Content ]
References [1] http:/ / support.microsoft.com/ default.aspx?scid=kb%3Ben-us%3B258261.php
Manual:Interface/SSTP
63
Manual:Interface/SSTP Applies to RouterOS: v5, v6+
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.
Manual:Interface/SSTP
64
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.
Manual:Interface/SSTP
65
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 r eal address. DNS names are ignored. v5.7 adds
new
parameter
to
verify-server-address-from-certificate
disable/enable
hostname
verification.
SSTP Client Sub-menu: /interface sstp-client
Properties Property
Description
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) comment (string; Default: )
Descriptive name of an item
connect-to ( IP:Port ; Default: 0.0.0.0:443)
Remote address and port of SSTP server.
dial-on-demand ( yes | no; Default: no) disabled ( yes | no; Default: yes)
Whether interface is disabled or not. By default it is disabled.
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 >>
name (string; Default: )
Descriptive name of the interface.
password (string; Default: "")
Password used for authentication.
profile (name; Default: default-encryption)
Used PPP profile.
proxy ( IP:Port ; Default: 0.0.0.0:443)
Address and port of HTTP proxy server.
user (string; Default: )
User name used for authentication.
Manual:Interface/SSTP
66
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;
Default: yes)
If set to yes, server's IP address will be compared to one set in certificate. 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 \
\... connect-to=10.1.101.1 disabled=no [admin@MikroTik] /interface sstp-client> print Flags: X - disabled, R - running 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 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 sstp-server server Properties:
Manual:Interface/SSTP
67
Property
Description
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 encry ption. If enab led win dows clien ts (sup ports on ly RC 4) will be un able 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 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 >>
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 keepalive-timeout: 60 default-profile: default certificate: server verify-client-certificate: no authentication: pap,chap,mschap1,mschap2 [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 Monitor command can be used to monitor status of the tunnel on both client and server. [admin@dzeltenais_burkaans] /interface sstp-server> monitor 0 status: "connected" uptime: 17m47s idle-time: 17m47s
Manual:Interface/SSTP
68
user: "sstp-test" caller-id: "10.1.101.18:43886" mtu: 1500
Read-only properties Property
Description
status ()
Current SSTP 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.
user (string)
Username u sed to estab lish the tu nnel.
mtu (integer )
Negotiated and used MTU
caller-id ( IP:ID)
Application Examples Connecting Remote Client 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) 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). 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 local-address=10.1.101.1
remote-address=10.1.101.100
Manual:Interface/SSTP
69
[admin@RemoteOffice] /ppp secret> print detail Flags: X - disabled 0
name="Laptop" service=sstp 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 SSTP 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 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 keepalive-timeout: 60 default-profile: default certificate: server verify-client-certificate: no authentication: mschap2 [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 # 0
NAME
USER
DR monitor 0 status: "connected" uptime: 1h45s idle-time: 1h45s
UPTIME
ENCODING
Manual:Interface/SSTP
70
user: "Laptop" caller-id: "192.168.99.1:43886" "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 Flags: X - disabled, R - running #
NAME
MTU
MAC-ADDRESS
ARP
0
R ether1
1500
00:30:4F:0B:7B:C1 00:30:4F:0B:7 B:C1 enabled
1
R ether2
1500
00:30:4F:06:62:12 00:30:4F:06:6 2: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 SSTP The following is an example of connecting two Intranets using SSTP tunnel over the Internet. Consider following setup
Office and Home routers are connected to internet through ether1, ether1, workstations and laptops are connected to ether2. ether2. 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. First step is to create a user [admin@RemoteOffice] [admin@RemoteOffi ce] /ppp secret> add name=Home service=sstp password=123 local-address=172.16.1.1 local-address=172 .16.1.1 remote-address=172.16.1.2 routes="10.1.202.0/24 172.16.1.2 1" [admin@RemoteOffice] [admin@RemoteOffi ce] ppp secret> print detail Flags: X - disabled
Manual:Interface/SSTP
0
71
name="Home" service=sstp caller-id="" password="123" profile=default local-address=172.16.1.1 local-address=172 .16.1.1 remote-address=17 remote-address=172.16.1.2 2.16.1.2 routes=="10.1.20 routes=="10.1.202.0/24 2.0/24 172.16.1.2 1"
[admin@RemoteOffice] [admin@RemoteOffi ce] /ppp secret>
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] admin@RemoteOffic e] /certificate>set 0 name=CA admin@RemoteOffice] admin@RemoteOffic e] /certificate>set 1 name=server admin@RemoteOffice] admin@RemoteOffic e] /certificate> print Flags: K - decrypted-private-key, Q - private-key, R - rsa, D - dsa 0
D name="CA" name="CA" subject=C=LV,ST=RI,L subject=C=LV,ST=RI,L=Riga,O=MT,CN=MT =Riga,O=MT,CN=MT CA,emailAddress=x CA,
[email protected] [email protected] issuer=C=LV,ST=RI,L=Riga,O=MT,CN= issuer=C=LV,ST=RI ,L=Riga,O=MT,CN=MT MT CA,emailAddress=x CA,
[email protected] [email protected] serial-number="DF626FA846090BCC" serial-number="DF 626FA846090BCC"
[email protected] invalid-before=j invalid-before=jun/25/2008 un/25/2008 07:23:50 invalid-after=jun/23/2018 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,emailA subject=C=LV,ST=RI,L=Riga,O=MT,CN=server,
[email protected] [email protected] issuer=C=LV,ST=RI,L=Riga,O=MT,CN= issuer=C=LV,ST=RI ,L=Riga,O=MT,CN=MT MT CA,emailAddress=x CA,
[email protected] [email protected] serial-number="01 serial-number="01" "
[email protected] invalid-before=jun/25/2008 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 keepalive-timeout: 60 default-profile: default certificate: server verify-client-certificate: yes authentication: pap,chap,mschap1,mschap2
Manual:Interface/SSTP
72
[admin@Home] /interface sstp-client> add user=Home password=123 connect-to=192.168.80.1 disabled=no certificate=cli ent verify-server-c ertificate=yes [admin@Home] /interface sstp-client> print Flags: X - disabled, R - running 0
R name="sstp-out1" max-mtu=1500 max-mru=1500 mrru=disabled connect-to=192.16 8.80.1:443 user="Home" password="123" proxy=0.0.0.0:443 profile=default certificate=client keepalive-timeo ut=60 add-default-rout e=no dial-on-demand=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 dst-address=10.1.101.0/24 /24 gateway=sstp-out1 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 € Crea Creatin ting g Cer Certi tifi fica cate tess € BCP (Bridg (Bridgee Cont Control rol Protoco Protocol) l) € http:/ / technet.microsoft.com/ technet.microsoft.com/ en-us/ en-us/ library/ library/ cc731352(WS.10).aspx cc731352(WS.10).aspx € Free Free trust trusted ed Clas Class1 s1 cert certifi ificat cates es
[3]
online
[ Top | Back to Content ]
References [1] [1] http http:/ :/ / msdn.microsoft.com/ msdn. microsoft.com/ en-us/ en-us/ library/ library/ cc247338(PROT.10). cc247338(PROT. 10).aspx aspx [2] [2] http http:/ :/ / technet.microsoft. technet.microsoft.com/ com/ en-us/ en-us/ library/ library/ dd458982.aspx dd458982. aspx [3] [3] http http:/ :/ / www.startssl.com/ www.startssl.com/
Manual:Interface/OVPN
73
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 Property
Description
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) comment (string; Default: )
Descriptive name of an item
connect-to ( IP; Default: 0.0.0.0)
Remote address of the OVPN server.
disabled ( yes | no; Default: yes)
Whether interface is disabled or not. By default it is disabled.
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) name (string; Default: )
Layer3 or layer2 tunnel mode (alternatively tun, tap) Descriptive name of the interface.
password (string; Default: "")
Password used for authentication.
port (integer ; Default: 1194)
Port to connect to.
profile (name; Default: default)
Used PPP profile.
user (string; Default: )
User name used for authentication.
Manual:Interface/OVPN
74
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 Flags: X - disabled, R - running 0
name="ovpn-out1" mac-address=FE:7 B: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 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 rule 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 ovpn-server server Properties: Property auth (; Default: sha1,md5)
Description 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 packet fragmentation.
mode (ip | ethernet ; Default: ip) netmask (integer ; Default: 24)
Layer3 or layer2 tunnel mode (alternatively tun, tap) Subnet mask to be applied to client.
Manual:Interface/OVPN
75
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 keepalive-timeout: 60 default-profile: default 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
Read-only properties
Manual:Interface/OVPN
76
Property
Description
status ()
Current status. Value other than "connected" indicates that there are some problems establishing tunnel.
uptime (time)
Elapsed time since tunnel was established.
idle-time (time)
Elapsed time since last activity on the tunnel.
user (string)
Username used to estab lish th e tu nnel.
mtu (integer )
Negotiated and used MTU
caller-id ( IP:ID) Source IP and Port of client.
Application Examples € Basic OVPN setup [ Top | Back to Content ]
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
Manual:BCP bridging (PPP tunnel bridging)
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.
77
Manual:BCP bridging (PPP tunnel bridging)
78
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
Manual:BCP bridging (PPP tunnel bridging)
BCP Configuration (Winbox) Office 1 Configuration Bridge Configuration: € Add Bridge,
€ Add Bridge Port,
79
Manual:BCP bridging (PPP tunnel bridging)
€ Add Bridge MAC-address,
€ Assign IP addresses,
80
Manual:BCP bridging (PPP tunnel bridging)
€ Create PPP profile for bridging,
€ Add PPP client,
81
Manual:BCP bridging (PPP tunnel bridging)
€ Enable PPTP-server,
82
Manual:BCP bridging (PPP tunnel bridging)
Office 2 Configuration The client router configuration is the same, except that you need to configure and enable PPTP client, € Add PPTP client,
83
Manual:MLPPP over single and multiple links
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 l ogical 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
Configuration Example 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="m yPPP" interface=ether 1 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 :)
84
Manual:MLPPP over single and multiple links
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.
Configuration Example
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 Flags: X - disabled, R - running 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=n o use-peer-dns=ye s allow=pap,chap,ms chap1,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
85
Manual:MLPPP over single and multiple links
/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 [ Top | Back to Content ]
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)
86
Manual:Interface/VPLS
87
General Sub-menu: /interface vpls List of all VPLS interfaces. This menu shows also dynamically created BGP based VPLS interfaces.
Properties Property
Description
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)
Defin es whether item is ign ored 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.
Read-only properties Property
Description
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: [
[email protected]] /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
Manual:Interface/VPLS
88
Available read only properties: Property
Description
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 Property bridge (none | string; Default:
Description 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) comment (string; Default: )
Short description of the item
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.
name (string; Default: ) pw-mtu (integer[32..65535];
Advertised pseudowire MTU value.
Default: 1500) pw-type (raw-ethernet | tagged-ethernet | vpls; Default:
Parameter is available starting from v5.16. It allows to choose advertised encapsulation in NLRI used only for 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)
Manual:Interface/VPLS
89
Cisco Style BGP VPLS Sub-menu: /interface cisco-bgp-vpls
Properties Property
Description
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) comment (string; Default: )
Short description of the item
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) name (string; Default: ) 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
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
90
