wap 60G ap udp both up to 850Mbps ! very nice this Beta61

Since I've spent some time restoring VPN functionality.. here are my 6.44beta61 IKEv2 settings for iOS, macOS and Windows clients.
Windows only seems to work with identity my-id=auto and remote-id=auto.
Afaik you cannot add a secondary peer for Windows default ipsec settings, so you should alter these using powershell.

Certificate generation:


(Certificates don't have to be trusted)

Certificate export:


IKEv2 server setup:


Peer setup:


Identity setup:


iOS setup:


macOS setup:


Windows client setup (you need Powershell to set hash/enc/dh/pfs, so I scripted all):

The next version will have some more changes for IPsec Identities to make it more clearer what you are actually matching. First of all, in beta61 it is pointless to specify remote-certificate on responder - certificate matching is not yet implemented. To match certain remote IDs, you have to check the IPsec debug logs and find out what actual ID (IDi) value is sent by the initiator.

I will update the wiki page when we come closer to the actual 6.44 release. Basically "auto" will check (verify) the IDi with clients certificate, so they have to match! "ignore" will not care about the initiators ID.

Would it be possible (during the rework of the IPsec code) to also add a phase1 "on up" and "on down" script?
(that receives parameters like the remote-id, remote-IP etc)
This script could then add/delete phase2 settings e.g. a GRE tunnel.

Would it be possible (during the rework of the IPsec code) to also add a phase1 "on up" and "on down" script?
(that receives parameters like the remote-id, remote-IP etc)
This script could then add/delete phase2 settings e.g. a GRE tunnel.

Yes, please! Hooking a script would be much appreciated. Currently I have a script running every 30 seconds to update gre interfaces...

Thank you for the feedback. Definitely not in this release, but I will see if we can add it in the near future.

Much time spent on ipsec when one could spend time on wireguard and have better VPN.

Much time spent on ipsec when one could spend time on wireguard and have better VPN.

Wireguard is not a better VPN. It is an immature product with a vocal community around it.
IPsec is widely supported amongst industry standard routers and does not require lame "+1 for Wireguard" 1-time posters.

CRS328-24P-4S+RM: I'm unable to log into the console on 6.44beta61, anyone experiencing a similar issue? Tried with multiple cables. Couple of CRS112s I have on 6.43.8 work fine.

Version 6.44beta75 has been released.

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 6.44beta75 (2019-Feb-08 08:02):

Important note!!! Backup before upgrade!
Due to major IPsec configuration changes in RouterOS v6.44beta39+ (see changelog below), it is advised to make a backup before upgrading. Regular downgrade will still be possible as long as no changes in IPsec peer menu are done.

MAJOR CHANGES IN v6.44:
----------------------
!) cloud - added command "/system backup cloud" for backup storing on cloud (CLI only);
!) ipsec - added new "identity" menu with common peer distinguishers;
!) ipsec - removed "main-l2tp" exchange-mode, it is the same as "main" exchange-mode;
!) ipsec - removed "users" menu, XAuth user configuration is now handled by "identity" menu;
!) radius - initial implementation of RadSec (Radius communication over TLS);
!) speedtest - added "/tool speed-test" for ping latency, jitter, loss and TCP and UDP download, upload speed measurements (CLI only);
!) telnet - do not allow to set "tracefile" parameter;
!) upgrade - release channels renamed - "bugfix" to "long-term", "current" to "stable" and "release candidate" to "testing";
!) upgrade - "testing" release channel now can contain "beta" together with "release-candidate" versions;
----------------------

Changes in this release:

!) ipsec - added new "identity" menu with common peer distinguishers;
!) winbox - improvements in connection handling to router with open winbox service (CVE-2019–3924);
*) bridge - fixed log message when hardware offloading is being enabled;
*) bridge - fixed packet forwarding with enabled DHCP Snooping and Option 82;
*) bridge - fixed system's identity change when DHCP Snooping is enabled (introduced in v6.44beta61);
*) bridge - improved packet handling when hardware offloading is being disabled;
*) certificate - show digest algorithm used in signature;
*) chr - distribute NIC queue IRQ's evenly across all CPUs;
*) chr - fixed IRQ balancing when using more than 32 CPUs;
*) crs3xx - fixed packet forwarding through SFP+ ports when using 100Mbps link speed;
*) crs3xx - fixed SFP+ linking using 1.25G SFP modules (introduced in v6.44beta39);
*) dhcpv6-server - fixed missing gateway for binding's network if RADIUS authentication was used;
*) dhcpv6-server - show "client-address" parameter for bindings;
*) ethernet - added "tx-rx-1024-max" counter to Ethernet stats;
*) ethernet - fixed packet forwarding when SFP interface is disabled on hEX S;
*) fetch - added option to specify multiple headers under "http-header-field", including content type;
*) fetch - improved stability when using HTTP mode;
*) fetch - removed "http-content-type" parameter;
*) gps - increase precision for dd format;
*) hotspot - added "https-redirect" under server profiles;
*) ike2 - retry RSA signature validation with deduced digest from certificate;
*) ipsec - require write policy for key generation;
*) kidcontrol - use "/128" prefix-length for IPv6 addresses;
*) lldp - fixed missing capabilities fields on some devices;
*) lte - added multiple APN support for R11e-4G;
*) lte - fixed passthrough DHCP address forward when other address is acquired from operator;
*) lte - improved SIM7600 initialization after reset;
*) lte - query "cfun" on initialization;
*) lte - require write policy for at-chat;
*) lte - update firmware version information after R11e-LTE/R11e-4G firmware upgrade;
*) ntp-client - fixed "dst-active" and "gmt-offset" being updated after synchronization with server;
*) ppp - fixed dynamic route creation towards VPN server when "add-default-route" is used;
*) quickset - fixed "country" parameter not properly setting regulatory domain configuration;
*) rb4011 - fixed SFP+ interface full duplex and speed parameter behavior;
*) rb4011 - improved SFP+ interface linking to 1Gbps;
*) sfp - fixed possible reboot loop when inserting SFP modules in CRS328-4C-20S-4S+ (introduced in v6.44beta61);
*) smb - fixed macOS clients not showing share contents;
*) smb - fixed possible buffer overflow;
*) smb - fixed Windows 10 clients not able to establish connection to share;
*) snmp - fixed "rsrq" reported precision;
*) snmp - report ifSpeed 0 for sub-layer interfaces;
*) switch - added comment field to switch ACL rules;
*) tr069-client - added "connection-request-port" parameter (CLI only);
*) usb - improved USB device powering on startup for hAP ac^2 devices;
*) usb - increased default power-reset timeout to 5 seconds;
*) userman - added first and last name fields for signup form;
*) w60g - fixed disconnection issues in PtMP setups;
*) winbox - renamed "Default AP Tx Rate" to "Default AP Tx Limit";
*) winbox - renamed "Default Client Tx Rate" to "Default Client Tx Limit";
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) wireless - improved antenna gain setting for devices with built in antennas;
*) wireless - improved connection stability for new model Apple devices;
*) wireless - improved system stability when scanning for other networks;
*) wireless - show "installation" parameter when printing configuration;

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as expected or after crash.

Normis,

6.44Beta75 has an issue with GPS lat/longs. The new algorithm is inserting "00" after the decimal point. So originally lat/long would be 33.9686/-117.7432. NOW... from the GPS itself.... it is 33.009686/-117.007432. Ive attached a screen shot..

The next version will have some more changes for IPsec Identities to make it more clearer what you are actually matching. First of all, in beta61 it is pointless to specify remote-certificate on responder - certificate matching is not yet implemented. To match certain remote IDs, you have to check the IPsec debug logs and find out what actual ID (IDi) value is sent by the initiator.

[...]

Separate but related...

I'm using a GRE interface with IPSec using certificate auth.

GRE interface properties has a setting for IPSec Secret.

When using PSK it seems redundant - there already is a PSK setting in peer / identity.

When using key or cert auth it's also redundant and unnecessary - there is no "secret" for key or cert auth. But when the "secret" is removed, the GRE tunnel doesn't get secured by IPSec (even if IPSec setting are left exactly the same), I mean IPSec is not brought up.

I think the idea is for the router to "know" that the GRE interface is supposed to be secured by IPSec - but perhaps there is a better way to set this up in the UI?

[SOLVED]

The next version will have some more changes for IPsec Identities to make it more clearer what you are actually matching. First of all, in beta61 it is pointless to specify remote-certificate on responder - certificate matching is not yet implemented. To match certain remote IDs, you have to check the IPsec debug logs and find out what actual ID (IDi) value is sent by the initiator.

[...]

Separate but related...

I'm using a GRE interface with IPSec using certificate auth.

GRE interface properties has a setting for IPSec Secret.

When using PSK it seems redundant - there already is a PSK setting in peer / identity.

When using key or cert auth it's also redundant and unnecessary - there is no "secret" for key or cert auth. But when the "secret" is removed, the GRE tunnel doesn't get secured by IPSec (even if IPSec setting are left exactly the same), I mean IPSec is not brought up.

I think the idea is for the router to "know" that the GRE interface is supposed to be secured by IPSec - but perhaps there is a better way to set this up in the UI?

And another thing about GRE + IPSec with cert auth. This one really looks like a bug.

When the GRE interface is brought up, it brings up the configured IPSec peer but *also* creates a redundant peer (with names like "peer6", "peer7") and a related item under Identities. Both are not necessary.

Not sure if it's new in 6.44 or was there before.

My "real" Peer is already set up, obviously, and uses IKEv2 and cert auth. The "bogus" peers have "main" as exchange mode and PSK auth but the local IP and remote IP are the same as in the "real" peer.

I really don't think it's in response to server (other side) initiated connections - first the server is set to IKEv2 only, second it uses cert auth (matching my "real" peer in Mikrotik) and not PSK.

Can be reproduced without reboot by disabling and then re-enabling the GRE interface in WebFig.

[SOLVED]

You can setup an ipsec transport policy with protocol=47 and ensure gre traffic is secured using the firewall ipsec policy matcher:

https://wiki.mikrotik.com/wiki/Manual:I ... ed_traffic

Dynamic peer will disappear as soon as you unset ipsec secret in gre tunnel.

Not sure if it's new in 6.44 or was there before.

kmansoft, It's not a bug, it's a feature, and definitely not version-related.

Either set the ipsec-psk field in gre (ipip, l2tp) tunnel interface settings and the peer and policy will be generated automatically ("dynamically" is the RouterOS name for it), using the default peer profile and proposal. Or define the IPsec peer & policy necesssary to secure the transport packets of your tunnel manually (and use security options as per your choice, not just the IKE(v1) main mode with PSK), and in that case do NOT fill the ipsec-psk field to prevent the dynamic peer&policy from being generated.

@nescafe2002, @sindy

Went to check IPSec / Policy and there was one for my GRE - but it had a "D" = "dynamic". Aha!

Did this:

- Removed "IPSec Secret" from GRE tunnel interface properties
- Manually added a policy for it
And now disabling and re-enabling the GRE interface:

- Keeps the IPSec connection running, with SAs and stuff
- Does not create those "peer8" policies

Both "bugs" solved. Wonderful!

Thank you both for your help!