thank you. ^^
Hi,
I’m testing wired dot1x with NPS. Is it possible to put the interface in a “guest” VLAN if 802.1x authentication fails?
In my example the devices/users that authenticate successfully are put in Corporate VLAN (let’s say VLAN10). And I’d like to put all other devices/user into the “guest” VLAN (let’s say VLAN20). When devices successfully authenticate they are put into VLAN10. If I connect an unauthorised device (a computer that is not in our domain, doesn’t have 802.1 ethernet enabled on their NIC) nothing happens. Port is UP but no MAC is added to the MAC table (/interface bridge hosts print). I tried configuring the port in VLAN20 access statically but nothing happens either.
Is this something that’s not yet implemented? Will this be added in a future release?
No, it is not possible at the moment. Please post your request to this thread. We are monitoring the feature requests and will implement them in future updates.
http://forum.mikrotik.com/t/feature-request-802-1x-over-ethernet/114581/1
I am still having problems with ethernet ports of a CRS326 switch. It happened again twice in the same port the past week. A 10Mbit half duplex port, only 2 meters away from the switch, stopped from responding to IPv4 pings and I had to disable and enable the port twice within a week in order to come back to life. I have send the supout of the switch a few minutes ago. At least now I don’t have to reboot the switch to start working again.
It is now quiet around the beta and using now the new IKEv2 EAP possibilities for a time, I want to made a suggestion how to direct traffic using policy routing. I am now using a second router to take care of PPPoE and IKEv2 as those two are bound together more or less.
I set in the ‘inside’ router through NAT the source address of the traffic and marking/tagging it so that in the outer router (PPPoE/IKEv2) it can be caught by the dynamic generated NAT for that specific IKEv2 traffic. This way I can have multiple IKEv2 providers/connections.
This is done by setting in IPSEC in mode config the name of the address-list containing the source address I set in through NAT on the inner router.
This is all fine but I have now a double NAT for that traffic and two routers handling that traffic.
I am using policy routing with other VPN connections and so only needing a single NAT for the traffic.
My request/suggestion is to enable a extra field in IPSEC mode config containing the name of the router mark for policy routing. Mangle is used to mark the routing that is intended to go through the router and if entered also in mode config then there is a dynamic NAT line generated on UP and removed on DOWN.
When nothing is entered in mode config then there is not dynamic NAT rule generates as is the case now.
If an address list name is entered then a dynamic NAT line is generated, matching on the list name and source address and not destination address as is the case now.
If the new field with the name of the routing mark is filled then a new dynamic NAT line is generated with only matching on that routing mark.
You can even think about interpreting source address and router mark if both are present but that will no immediate use in my eyes.
msatter we have already plans for such feature. But connection marks will be used instead of routing marks.
Great, much appreciated! Can’t wait for it…
Will we see this before version 6.45 final release?
I hope I’m not missing the point, but isn’t this IKEv2 & policy routing something that would be best solved by what’s known as route/interface-based VPN, VTI, etc? I remember it used to be popular request here few years ago. If I understand it correctly, Linux implementation provides interfaces for IPSec connections, but internally it’s still regular policy-based tunnels (often with 0.0.0.0/0 on both sides, but it can be anything). And some marks transparently assigned to outgoing traffic via that interface (it basically serves as additional filter for policy) are used to control what traffic it will actually apply to. So this should nicely cover the use case for multiple outgoing IPSec connections (like popular commercial VPN services). But not only that, distinct interfaces would make everything more clear and admin friendly. More interoperable too. And the whole thing doesn’t even sound too complicated.
That would be even more welcome. 
However I thing Mikrotik has its reasons to do it one way, not the other. I am happy either way.
Mikrotik support have acknowledged the VTI request, but said it requires a newer kernel.
They will revisit the request once v7 beta is out.
Currently looks like no, it will not make it into 6.45. We are already finalizing the 6.45 version. VTI support requires new kernel and we are still not sure whether it should or should not be implemented in version 7.
No rc versions this time?
Well, I remember the days when all Linux systems did that, but it was changed because others (BSD, Cisco) were not using separate interfaces but only those policies.
I always considered it a bad move. Dedicated interfaces for IPsec traffic were so much clearer.
Apparently later (and currently) the option to use interfaces was re-introduced, but today I am not using plain Linux systems as routers anymore so I lost track of that.
Whenever possible, I use a tunnel over IPsec transport. I use GRE because it has some other use cases, but you can use IPIP too.
In fact, IPIP over IPsec transport is almost the same as an IPsec tunnel at the protocol layer. I.e. there is no extra overhead.
But of course this can only be done when you manage both ends, as they cannot be interconnected.
One thing I would like to see in 6.45 is some hardware SNMP improvement for the CCR1072.
As stated in ticket #2019032822004818, many hardware OIDs are missing for this device, compared to what Winbox shows :
- Board temperature
- Board temparature 2
- Fan speed 3
- Fan speed 4
- PSU1 status (should be OID .15 (*))
- PSU2 status (should be OID .16 ())
() as seen on other models such as the CRS317-1G-16S+.
We are then clearly at risk with our CCR1072-1G-8S+, not being able to monitor all their hardware components, which is a rather tricky situation for core devices.
I found other topics complaining about this : http://forum.mikrotik.com/t/snmp-or-lack-of-it/126684/1 / http://forum.mikrotik.com/t/mikrotik-ccr1072-mib-file/105522/1
Many thanks for your support Mikrotik dev’ team !
Why only in tr069? Export in SNMP too, with all other info.
+1
If you can see this system info in the cli, you can easily send it out to a monitor system using script and Syslog.
I have stopped using SNMP, since for every new unit I setup, I have to tell the system that there are a nye Router/Switch, or have a program that scan a net. Scanning net does not work it the router are spread around in many net.
Using Sylog is easy. Just add a script to the router when you are setting it up. It will then call home with all info you need.
Look at my Mikrotik for Splunk in my signature.
We use SNMP for all our (network) devices from our enterprise monitoring & reporting solution, I think as many other companies.
We simply can’t rely on workarounds.
We then expect Mikrotik to complete the SNMP tree for the CCR1072 hardware components, to have something reliable.
Thank you anyway !
Version 6.45beta62 has been released.
Before an upgrade:
- Remember to make backup/export files before an upgrade and save them on another storage device;
- Make sure the device will not lose power during upgrade process;
- Device has enough free storage space for all RouterOS packages to be downloaded.
What's new in 6.45beta62 (2019-Jun-13 10:13):
MAJOR CHANGES IN v6.45:
!) 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;
!) user - removed insecure password storage;
Changes in this release:
!) 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;
*) bridge - correctly handle bridge host table;
*) capsman - fixed CAP system upgrading process for MMIPS;
*) certificate - added "key-type" field;
*) certificate - added support for ECDSA certificates (prime256v1, secp384r1, secp521r1);
*) crs3xx - fixed "tx-drop" counter;
*) defconf - fixed channel width selection for RU locked devices;
*) dhcpv4-server - added "client-mac-limit" parameter;
*) dhcpv6-client - added option to disable rapid-commit;
*) dhcpv6-server - added additional RADIUS parameters for Prefix delegation, "rate-limit" and "life-time";
*) dhcpv6-server - added "address-list" support for bindings;
*) dhcpv6-server - added "insert-queue-before" and "parent-queue" parameters;
*) dhcpv6-server - added RADIUS accounting support with queue based statistics;
*) dhcpv6-server - added "route-distance" parameter;
*) e-mail - properly release e-mail sending session if the server's domain name can not be resolved;
*) ipsec - added dynamic comment field for "active-peers" menu inherited from identity;
*) ipsec - added "ph2-total" counter to "active-peers" menu;
*) ipsec - added support for RADIUS accounting for "eap-radius" and "pre-shared-key-xauth" authentication methods;
*) ipsec - added traffic statistics to "active-peers" menu;
*) ipsec - disallow setting "src-address" and "dst-address" for transport mode policies;
*) ipsec - renamed "remote-peers" to "active-peers";
*) ltap - renamed SIM slots "up" and "down" to "2" and "3";
*) lte - added passthrough interface subnet selection;
*) lte - fixed LTE interface running state on RBSXTLTE3-7 (introduced in v6.45beta);
*) m33g - added support for additional Serial Console port on GPIO headers;
*) routerboard - renamed 'sim' menu to 'modem';
*) snmp - fixed "send-trap" not working when "trap-generators" does not contain "temp-exception";
*) snmp - improved reliability on SNMP service packet validation;
*) winbox - added "System/SwOS" menu for all dual-boot devices;
*) winbox - do not allow setting "dns-lookup-interval" to "0";
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.
Will it also work for “rsa-signature-hybrid”?