v7.1beta2 [development] is released!

Wireguard is working well, except for that minor winbox issue with the endpoint port. With how easy it was to setup, I totally get the Wireguard hype now. IPSEC has a frustrating amount of knobs to turn.

Between a couple hAP ac² routers, I was getting about 280 Mbps UDP. When I changed out one of those hAP ac² routers with an older RB951G-2HnD, I was getting about 75 Mbps. That’s probably better than I’d get out of IPSEC on the same device!

Wireguard is included in the beta, that’s awesome. Thank you to all the devs for the addition, looking forward to setting it up then I get home.

P.S. One thing I would really like to see in the new RouterOS v7 MPLS implementation is MPLS mangle for QoS purposes - specifically, “mark packet” and “set priority” actions for MPLS. Right now to do MPLS QoS on RouterOS we have to create a bunch of extra bridges and use bridge filters for QoS. A simple MPLS mangle table would allow us to get rid of those extra bridges.

Also, please add “set priority” to the IPv6 Mangle. We have to use bridge filters as a workaround for that too at the moment.

Here is the preliminary testing we have done on this version with two CHRs on ProxMox that are each on a different VLAN and the CRS317 routes between the VLANs

This is very quick UDP test - we will do more work using TCP with traffic generator and iperf3

4 to 5 Gbps with UDP and 0 to 3% CPU load


We are waiting for the usual stuff:

  1. airtime fairness improvvements (http://blog.cerowrt.org/post/real_results/, https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002)
  2. MU-MIMO
  3. 802.11 k/v/r

3Com 4800G switch from 2009 is my bread and butter switch: IS-IS, BGP, OSPF, VRF; PIM-SSM all running with full IPv4 and IPv6 support.

For sure we’ll get those features on ROS just wait till WiFi 7 gets announced xD

I have no problem pushing ~9.3Gbit/s IPv4 in a single thread using iperf3 between two hosts routed on the CRS317 with L3 offloading enabled. IPv6 is, as expected, another story - it gives me ~370Mbit/s.

You’d be a fool to reimplement it yourself. Have a look at the Wireguard site and code and see for yourself how carefully it’s been developed. Mikrotik would/might have only done some interface changes to make it work the ROS way.

Can’t add key in wireguard via cli with “=” at the end. But can add it later via edit and can add it via gui.

I still cannot get MACSEC running between devices(“Gets to negotiating only”).
Any suggestions ?

/interface macsec
add cak=4cb39ed149d0e0dbea5fad4b91e5456f ckn=f98446584e49ad9e2cd99b2aff00adb73e0b4109eb916b8d5bbe208dda274abb \
    disabled=no interface=ether5 name=macsec1 profile=default



[admin@under desk] /interface/macsec> print
Flags: I - inactive, X - disabled, R - running 
 0   name="macsec1" interface=ether5 status="negotiating" cak=4cb39ed149d0e0dbea5fad4b91e5456f 
     ckn=f98446584e49ad9e2cd99b2aff00adb73e0b4109eb916b8d5bbe208dda274abb profile=default 
[admin@under desk] /interface/macsec>

OpenVPN UDP still broken in this release. :frowning:
For anyone else wondering, 7.0beta5 is the latest version that has OpenVPN UDP working. 7.1beta1 and and 7.1beta2 both have kernel crashes when you attempt to use it.

I reported it to Mikrotik and it has been acknowledged but it seemingly did not make it into this release.

Put the key value between quotes, you may find the correct syntax using the export command.

[admin@MikroTik] /interface/wireguard> add private-key="EMjwk8mpDylWKGU0c/z9TR1e5u1D75OUz2jsv3lZu3k="
[admin@MikroTik] /interface/wireguard> peers/
[admin@MikroTik] /interface/wireguard/peers> add allowed-address=10.20.30.40 public-key="ObVREVOUlpRvqPxshivdYGiirVhb/U/dt1T7rQE2WFk=" interface=wireguard1

[admin@MikroTik] /interface/wireguard/peers> export 
# aug/22/2020 09:10:46 by RouterOS 7.1beta2
/interface wireguard peers
add allowed-address=10.20.30.40/32 interface=wireguard1 public-key="ObVREVOUlpRvqPxshivdYGiirVhb/U/dt1T7rQE2WFk="

By the way, there’s no “export” command under new /routing menus :frowning:

I tried to setup point-to-point OSPF via SSTP tunnel, and in /routing/route/print I see duplicated routes without gateway. WAIDW?

Flags: I - INACTIVE, U - UNREACHABLE, A - ACTIVE; c - CONNECT, o - OSPF, d - DHCP, l - LDP-MAPPING
Columns: DST-ADDRESS, GATEWAY, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
      DST-ADDRESS               GATEWAY         DIS  SC  TA  IMMEDIATE-GW   
  Ad  0.0.0.0/0                 10.0.0.1          1  30  10  10.0.0.1%ether1
  Io  10.0.0.0/23                               110  20  10                 
  Ao  10.0.0.0/23               sstp-odesskaya  110  20  10  sstp-odesskaya 
  Ac  10.0.0.0/24               ether1            0  10      ether1         
  Io  10.52.56.0/24                             110  20  10                 
  Ao  10.52.56.0/24             sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.0                                110  20  10                 
  Ao  100.64.0.0                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.1                                110  20  10                 
  Ao  100.64.0.1                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.2                                110  20  10                 
  Ao  100.64.0.2                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.3                                110  20  10                 
   o  100.64.0.3                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Ac  100.64.0.3                sstp-odesskaya    0  10      sstp-odesskaya 
  Io  100.64.0.4                                110  20  10                 
  Ao  100.64.0.4                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.5                                110  20  10                 
  Ao  100.64.0.5                sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.0.6                                110  20  10                 
  Io  100.64.1.0/24                             110  20  10                 
  Ao  100.64.1.0/24             sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.3.0/24                             110  20  10                 
  Ao  100.64.3.0/24             sstp-odesskaya  110  20  10  sstp-odesskaya 
  Io  100.64.6.0/24                             110  20  10                 
  Ao  100.64.6.0/24             sstp-odesskaya  110  20  10  sstp-odesskaya

The config is the simplest one:

/routing ospf instance
add name=ospf_v2 router-id=100.64.0.7 version=2
/routing ospf area
add area-id=0.0.0.0 instance=ospf_v2 name=backbone_v2
/routing ospf interface
add area=backbone_v2 network=sstp-odesskaya network-type=point-to-point

Is there any examples on how to configure wireguard as client on mikrotik? I’d like to connect my mikrotik router to an existing wireguard server. Also, while setting up the peer endpoint, only IP addresses are allowed? Can’t I use a domain name?

Thanks!

When you don’t like that, just don’t turn the knobs!
It is always easy (at least at first) to create something as a single supplier and focus on a single use-case, and make it look simple. Look at Microsoft Windows.
But as more and more features are added (e.g. multiple different encryption methods, as in IPsec), it becomes more complicated over time.
See how it went with OpenVPN, that was also simple at first but got more complicated on the way, especially because there was little forethought on how to accomodate future flexibility in the initial protocol.
IMHO the same will happen with wireguard.
In IPsec it happened right from the start because lots of options for lots of selections were there all the time. But without that, it would have been even more difficult to introduce stronger encryption and hashing protocols, for example.

One thing that need to be done is to allow Wireguard to use FQDN instead of just IP addresses. For two reasons, basically:

  1. Not everyone have a static IP
  2. With IPv6, DNS names will make a huge difference. So much easier to remember and to check the spelling…

Yes, yes, I know. Wireguard doesn’t do FQDNs. It doesn’t matter: just put the name on the configuration, and do a DNS lookup at connection time. Exactly like we have with IPSEC today.

So announcement says CRS309-1G-8S+IN, CRS312-4C+8XG-RM, CRS326-24S+2Q+RM and CRS354-48G-4S+2Q+RM for L3 offload but CRS317 mentioned above as working.

I have CRS326-24G-2S+ (arm). Will it take advantage of L3 offloading? If so, what else will?

For CRS317 it was added earlier.