*) fixed ssh server crashing when sessions were interrupted
*) ipsec - fix a problem which could silently remove a manual policy
from the kernel if the peer configuration has ‘generate-policy’ set to ‘yes’
and if the policy matches with the traffic selector of a SA being removed
on the responder side, also fix a problem that some generated policies
may stay in kernel after relevant SA was removed;
*) profiler - correctly show idle task on RB1200;
*) webfig - fix dual nstreme interface setting lists;
*) webfig - fix Wireless Access/Connect List editing;
*) webfig - fix bitrate presentation in simple queues (show 1.5M as 1500k);
*) fixed micro-sd access on RB400 not to stop everything else;
*) sstp - when server certificate verification is enabled for sstp client,
it will additionally compare IP addresses found in certificate’s
subjectAltName and subject CN to the real address, DNS names are ignored;
*) tftp - optional block counter roll-over support;
*) hotspot - fixed possible crash in case of multiple Radius CoA requests;
*) userman - speedup user deletion with big log size,
note that first userman startup after this update
may take few minutes if the log size is in hundreds of MB;
*) mpls - added support for enabling/disabling control word usage for
BGP based VPLS tunnels (both - Cisco and RFC 4761 based);
*) mpls - added support for auto-discovery of VPLS NLRI encoding method
for Cisco BGP based VPLS tunnels;
*) winbox - sometimes after disconnecting, winbox could not connect back;
*) bgp - allow parallel operation of RFC4761 “l2vpn” and
draft-ietf-l2vpn-signaling “l2vpn-cisco” BGP VPLS variants inside
single peering session.
*) console - “:resolve” command now returns IPv6 address for domain names
that have only IPv6 address records;
*) snmp - provide ups alarms for bad or low battery or for ups overload;
*) route - fixed SNMP getnext queries, were failing to find next
prefix in the OID order;
Normis, why are files of mipsle the only in separate directory? it was in 5.5 release, it’s in 5.6… When you changed all WinBox menus to alphabetical order - it was a bit uncomfortable for the first times, but then it appeared to be very cosy. But I bet nobody likes when all packages are in one heap!.. It’s very easy to mis-select package for another platform when uploading new version… And it wastes space when you try to make your own per-platform folders and have to leave original files in place for torrent seeding…
*) sstp - when server certificate verification is enabled for sstp client,
it will additionally compare IP addresses found in certificate’s
subjectAltName and subject CN to the real address, DNS names are ignored;
What does this mean in simple terms? Do I now have to have the server IP address as a subjectAltName in the certificate? Is now the SSTP server forcing the client to perform additional checks regarding the certificate? Does the DNS names in the CommonName are ignored in favor of IP addresses in the AltName?
Is SSTP going to be easier or more difficult to use?
Sorry for the many questions, but I really have no idea what this release note covers.
OK. So let’s assume for a moment that I’m running a VPN server and want to connect to it using SSTP. I generate my certificate signing request and for the CN I use the server IP. I then submit the cetificate signing request to Godaddy or any other signing CA (windows will not connect to servers showing an unsigned certificate by a trusted signing CA). They will throw out the CSR since the CN would not contain a valid domain name.
I’m then stuck creating my own CA and distributing root certificates to my users who may or may not know how to import them into which keystore.
If this is what 5.6 is doing, then it sounds like the killing of an otherwise useful routeros feature.
That’s why windows for example will not accept the server certificate unless it’s signed by a trusted signer. So now not only will they have to contaminate the DNS, they will have to generate a valid a signed certificate in your domain name.
So now IE/FF/Chrome/Opera/Safari should warn us every time we visit a secure site like https://amazon.com that although the certificate is in order, we should better use http://72.21.211.176 because DNS servers can be hijacked left and right? (what about DNSSEC btw.) This game had been played and the winner is the domain name. Do not re-invent this wheel.
–I feel however that we are misunderstanding something here and was hoping that MT could give a better explanation instead of this half sentence … this goes back to an earlier issue that better changelogs are needed instead of these misleading half sentences–