Mikrotik 6.45.2 is out

What’s new in 6.45.2 (2019-Jul-17 10:04):

Important note!!!
Due to removal of compatibility with old version passwords in this version, downgrading to any version prior to v6.43 (v6.42.12 and older) will clear all user passwords and allow password-less authentication. Please secure your router after downgrading.
Old API authentication method will also no longer work, see documentation for new login procedure:

*) bonding – fixed bonding running status after reboot when using other bonds as slave interfaces (introduced in v6.45);
*) cloud – properly stop “time-zone-autodetect” after disable;
*) interface – fixed missing PWR-LINE section on PL7411-2nD and PL6411-2nD (introduced v6.44);
*) ipsec – added “connection-mark” parameter for mode-config initiator;
*) ipsec – allow peer argument only for “encrypt” policies (introduced in v6.45);
*) ipsec – fixed peer configuration migration from versions older than v6.43 (introduced in v6.45);
*) ipsec – improved stability for peer initialization (introduced in v6.45);
*) ipsec – show warning for policies with “unknown” peer;
*) ospf – fixed possible busy loop condition when accessing OSPF LSAs;
*) profile – added “internet-detect” process classificator;
*) radius – fixed “User-Password” encoding (introduced in v6.45);
*) ssh – do not enable “none-crypto” if “strong-crypto” is enabled on upgrade (introduced in v6.45);
*) ssh – fixed executed command output printing (introduced in v6.45);
*) supout – fixed supout file generation outside of internal storage with insufficient space;
*) upgrade – fixed “auto-upgrade” to use new style authentication (introduced in v6.45);
*) vlan – fixed “slave” flag for non-running interfaces (introduced in v6.45);
*) wireless – improved 802.11ac stability for all ARM devices with wireless;
*) wireless – improved range selection when distance set to “dynamic”;

Printing Mikrotik BGP received routes

This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
To view this content, you must be a member of Justin Wilson's Patreon at "Patrons Only" or higher tier

Common Question: Wisps, Public IPs, and assigning

So a question I get on a fairly regular basis is how do I assign IPs to my customers out of this /29 block my ISP gave me. As many of you know, IPV4 public addresses, commonly known as globally routable IPV4 addresses, are in short supply and obtaining more is usually very expensive. You have three options to obtain IP addresses.

Option #1 is getting them from whoever is supplying your bandwidth.  These IPs are known as Provider Assigned IP Space or PI space for short.  Typically these IP addresses are leased to you for a price or just allocated to you because you are a customer. The key here they are tied to the provider.  If you leave for someone else, your IPs are typically not portable.

Option#2 is going to the open market to buy or lease IP addresses.  There are several companies out there which sell or rent IP addresses. For business continuity buying your addresses is the best way to go.  As of this writing, IPV4 addresses in the ARIN region at going for $17-21 an Ip address.  This pricing means the smallest block you can get costs you around $5,600.

Option #3 is asking ARIN or whatever Regional Internet Registry (RIR) you fall under and getting put on a waiting list.  This wait can take quite some time and you may be waiting for a very long time.

Most startup ISPs get a small block of addresses from their provider.  The block can be a /29 ,or sometimes they can get a /28 or larger. The upstream ISP routes the block(s) to the startup. Here is where the problem comes up.  If an ISP gets a /29 this means they have 1 block of 6 IPs to use or two blocks of two IPs they can use in the form of two /30’s.  For those of you not familiar with subnetting, each time you “break down” a block of IP addresses you always lose 2 to the network and broadcast addresses.

if you want to learn about subnetting the following Youtube Videos will be helpful. Be warned there is a lot of numbers and math involved, but it’s necessary to learn about subnetting and proper IP planning.

Imagine an ISP has two customers on different towers that want a public IP address.  These addresses are for cameras, VPNs, or any number of uses. In order to assign IPs to each of those customers out of your /29 you have to either break it apart into two /30’s and route that to the appropriate router of yours the customer is attached to.  With small blocks assigned to you, this becomes very inefficient.  Even with large blocks, it can be inefficient. The below diagram shows how we can properly subnet this out given the limited IP block you have.

subnet example

We broke out into the following subnets.

We still have the same number of IP addresses we had before, but due to the way subnetting works we lost a total of 4 addresses to the network and broadcast addresses.  Think of these as the beginning and end of the subnet.  We can’t use them to assign to devices, but we need them as part of the subnet.  We can note these as the following – Network Address – FIrst assignable address – Second Assignable address – Broadcast address

The next subnet would be 4,5,6,7 in the same order.  The rules of subnetting say we can not assign the network and broadcast addresses to devices or else we start breaking things.

Now if both of these customers were on the same tower, behind the same ISP router we would not necessarily have to subnetted the /29 out. We could have routed the /29 to the router and customer 1 has the .2 IP address and customer 2 has the .3 IP address.  the subnet would have IPs 4-6 available, but only for customers on the same tower.

The other way to save on public IP addresses is to do a 1:1 nat.  Natting involves doing port forwarding from the public IP to a private IP address at the customer location. If you want to learn about 1:1 Nat here are some links:

So what is the real problem? If you have a /29 you can only break that down twice into the two /30s for customers going through different routers. Your network is routed instead of bridged right?

So how does the startup WISP overcome this without spending lots of money on IP addresses? You can do the 1:1 nat for each customer as explained above.  In my experience, this works 98% of the time. It is also something most I.T. folks are not familiar with.  I have had to spend hours on the phone with customers over the years explaining how a 1:1 nat works and they do have a public address to connect to, even though they have a private IP address on their router. Customers who do not get the 1:1 nat concept seem to be very leary of it and often blame the 1:1 nat when things go wrong.  Now if you are an ISP that provides a managed router, the customer does not see this layer.

Your other option is an MPLS network with VPLS tunnels.  MPLS with VPLS allows you to bridge your sites together to share an IP address pool.  However,  bridging is bad is what you hear.  MPLS has things like split-horizon built into the protocol to make bridging things together not so bad of a thing.

Another option is PPPoE.  PPPoE creates a tunnel utilizing a /32 (one ip address).  Many providers are using a shared pool to hand out IP addresses to customers who are given Public Ip addresses.

But my provider also gave me a /30 that is between my router and their’s. Can I use this?
The short answer is this is the “Glue” between you and the upstream provider.  The only real use for this is to Nat traffic out the Ip assigned to your side.  Doing this is not scalable though.

I have briefly touched on things like PPPoE, MPLS, and other things in this article.  These are such large topics there was no way this single post could do them justice.  I wanted to present the problem, a solution, and other methods to research to solve it. I will go into these in later blog posts.

Dot1x in Routeros 6.45.1

Some of you may have noticed a new menu item pop up in winbox labeled dot1x

Dot1x is implementation of IEEE 802.1X standard in RouterOS. Main purpose is to provide port-based network access control using EAP over LAN also known as EAPOL. 802.1X consists of a supplicant, an authenticator and an authentication server (RADIUS server). Currently both authenticator and supplicant sides are supported in RouterOS. Supported EAP methods for supplicant are EAP-TLS, EAP-TTLS, EAP-MSCHAPv2 and PEAPv0/EAP-MSCHAPv2.

Looking at how to use this?

RouterOS 6.45.1 Out – Security Fixes

Mikrotik has released RouterOS 6.45.1 with some security vulnerability fixes.  Some of these have been known and fixed before, while others are new fixes

!) dot1x – added support for IEEE 802.1X Port-Based Network Access Control;
!) ike2 – added support for EAP authentication methods (eap-tls, eap-ttls, eap-peap, eap-mschapv2) as initiator;
!) security – fixed vulnerabilities CVE-2018-1157, CVE-2018-1158;
!) security – fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479;
!) security – fixed vulnerability CVE-2019-13074;
!) user – removed insecure password storage;

Important note!!!
Due to removal of compatibility with old version passwords in this version, downgrading to any version prior to v6.43 (v6.42.12 and older) will clear all user passwords and allow password-less authentication. Please secure your router after downgrading.

Some notes on the security Fixes
Mikrotik RouterOS before 6.42.7 and 6.40.9 is vulnerable to a memory exhaustion vulnerability. An authenticated remote attacker can crash the HTTP server and in some circumstances reboot the system via a crafted HTTP POST request.

Mikrotik RouterOS before 6.42.7 and 6.40.9 is vulnerable to a stack exhaustion vulnerability. An authenticated remote attacker can crash the HTTP server via recursive parsing of JSON.

Jonathan Looney discovered that the TCP_SKB_CB(skb)->tcp_gso_segs value was subject to an integer overflow in the Linux kernel when handling TCP Selective Acknowledgments (SACKs). A remote attacker could use this to cause a denial of service. This has been fixed in stable kernel releases 4.4.182, 4.9.182, 4.14.127, 4.19.52, 5.1.11, and is fixed in commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff.

Jonathan Looney discovered that the Linux kernel default MSS is hard-coded to 48 bytes. This allows a remote peer to fragment TCP resend queues significantly more than if a larger MSS were enforced. A remote attacker could use this to cause a denial of service. This has been fixed in stable kernel releases 4.4.182, 4.9.182, 4.14.127, 4.19.52, 5.1.11, and is fixed in commits 967c05aee439e6e5d7d805e195b3a20ef5c433d6 and 5f3e2bf008c2221478101ee72f5cb4654b9fc363.

This has been reserved and not been made widely public yet. Although a CVE ID may have been assigned by either CVE or a CAN, it will not be available in the NVD if it has a status of RESERVED by CVE.  This is traditionally done to give the vendor, in this case, Mikrotik and possibly others, a chance to fix this before the exploit is released to the general public.

Rest of the Changelog available at https://www.mikrotik.com/download

Mikrotik RouterOS 6.43 and older notes

For those of you running newer routerOS versions you should be aware of this.

Downgrading to any version prior to v6.43 (v6.42.12 and older) will clear all user passwords and allow password-less authentication. Please secure your router after downgrading.

I am not sure when this actually started as it shows up in the changelog of 6.45beta62. I am going to assume this starts at 6.45 once it’s released.

Mikrotik LoRaWAN products

Taken directly from Mikrotik newsletter 89.

R11e-LoRa8EU – a new LoRaWAN  concentrator Gateway card in miniPCIe form factor

based on Semtech SX1301 chipset. It enables LoRaWAN connectivity for any MikroTik product that has miniPCIe slot with connected USB lines.

With the support of 8 different channels in 868EU band, Listen Before Talk (LBT) and Spectral scan features this product will astound you with its enticing price point – under $100. Max output TX power – 16 dBm, max sensitivity level on SF12 rate – 134 dBm

wAP LoRa8 kit – an out-of-the-box solution to use LoRaWAN gateway. This kit contains

wAP 2nD device with 2.4 GHz WLAN interface and Ethernet port that could be used as a backend connection and pre-installed UDP packet forwarder to any public or private LoRa servers. You can attach an external antenna (see below) or use internal 2.5 dBi antenna. Once again the price is a real bargain – under $200!

LoRa Antenna kit with a 6.5 dBi Omni antenna for 824 – 960 MHz, 1 m long SMA cable and mechanical holder for quick and easy mast attachment – when you need that extra network coverage.

These products are ready to work with ‘The Things Network’ – the famous open-source infrastructure that provides free LoRaWAN network coverage and has tons of apps for your needs. The Things Network helps you get started with the Internet of things in a day. Cattle tracking, smart irrigation and thermostats, smart metering and so on – the possibilities are endless. The setup is so simple, anyone can get started really quickly. With an SLA backed service by ‘The Things Industries’, it has never been easier to deploy secure and scalable LoRaWAN solutions. There is a global community of developers, businesses and enthusiasts – you will never be alone with your questions and ideas regarding LoRaWAN network. No need to reinvent the wheel – join The Things Network to save time and energy with smart solutions!