Sent from my XT1580 using TapatalkI think I'm running into a config bug in 6.44 Beta 20
I've upgraded my testing router and saw the L2TP/IPSec unsafe config notice. So I was playing around with configs to fix that.
Once the L2TP peer is initially added, any attempt to edit the peer config errors out with "Couldn't change IPSec Peer <::/0> - certificate chain is supported only in IKEv2 (6)"
This seems to affect both manually and dynamically added peers.
Any truly valid peer config commits successfully when initially configured, but any attempt to change them results in the same error.
Also, since Mikrotik is warning against L2TP/IPSec PSK, is there any plans to expand the L2TP setup in PPP to be more secure?
Is 008 still the current firmware?the recent betas [ eg 6.44beta20 ] allow for upgrade of the lte card's firmware in RBwAPR-2nD&R11e-LTE,
after an upgrade on RBwAPR-2nD&R11e-LTE /interface lte info lte1 shows "MikroTik_CP_2.160.000_v008", while RBwAPR-2nD&R11e-LTE-US - MPSS: R11eL_v12.09.171931 APSS: R11eL_v02.14.173531 CUSTAPPIs 008 still the current firmware?the recent betas [ eg 6.44beta20 ] allow for upgrade of the lte card's firmware in RBwAPR-2nD&R11e-LTE,
actually i can - that's why i stated my question: do you plan for allowing lte firmware upgrade on the US version?Change log for this beta clearly states that R11e firmware upgrade is available only for international version of devices .... can't you read?
Sorry, didn't see the question in your previous post.actually i can - that's why i stated my question: do you plan for allowing lte firmware upgrade on the US version?Change log for this beta clearly states that R11e firmware upgrade is available only for international version of devices .... can't you read?
Test on the current/stable channel
I was also trying to do that without success.
Sent from my XT1580 using Tapatalk
On the 43rc was also get the sames errorsI previously had 6.44 b(~6 or 8, can't recall) and it didn't warn about either l2tp/ipsec psk nor ipsec certificates.
I'm fairly certain it's a recent addition to the testing channel only.
Test on the current/stable channel
I was also trying to do that without success.
Sent from my XT1580 using Tapatalk
Thanks for heads up. I think I will eventually end up with this new board, as it seems I've became addicted to Mikrotik tech
I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.
viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
Hmm... I respectfully disagree that reading the topic leads to your assumption; however, I am also willing to believe this is an Apple problem.I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.
viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.
From iOS 12.0.1 release notes:Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.
viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
12.0.1 does not resolve what we are seeing. I can confirm it did fix the issue you mentioned above when both 2.4GHz and 5GHz radios are broadcasting the same SSID, and was impacting all environments. The issue I am discussing makes these new iPhones almost totally dysfunctional within the Mikrotik framework using any 5GHz AC 80MHz XXXX channel width. If you configure your radio to 5GHz A/N 40MHz XX, the problem goes away. It's an "AC" issue...different problem than what was fixed in 12.0.1From iOS 12.0.1 release notes:Reading through the topic you've linked to makes me think it is an iPhone's problem, not Mikrotik's one.I really hope that the new iPhone Xs/XsMax 5GHz AC problem is resolved before the 6.44 production release.
viewtopic.php?f=7&t=139608&sid=c8121250 ... cae5c96b71
Resolves an issue that could cause iPhone XS devices to rejoin a Wi-Fi network at 2.4GHz instead of 5GHz
Please do not use the release topic for other things than reporting issues with the release.But what I cannot ping Miktrotik ipv6 addres from LAN, same subnet, same VLAN. Maybe someone have similar issue ?
sorry... I fixed this by using Router/48: from HE instead /64:Please do not use the release topic for other things than reporting issues with the release.But what I cannot ping Miktrotik ipv6 addres from LAN, same subnet, same VLAN. Maybe someone have similar issue ?
Make a new topic in the General or Beginners section describing your issue and include a /export of your configuration (no screenshots!).
Any Examples?ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
/certificate
add common-name=TESTCA name=TESTCA days-valid=3650
sign TESTCA ca-crl-host=192.168.3.124
add common-name=192.168.3.124 subject-alt-name=DNS:192.168.3.124 key-usage=tls-server name=TestVPN days-valid=3600
sign TestVPN ca=TESTCA
add common-name=hunter key-usage=tls-client name=hunter days-valid=3600
sign hunter ca=TESTCA
/ip pool
add name=VPN-Pool ranges=192.168.222.100-192.168.222.150
/ip ipsec mode-config
add address-pool=VPN-Pool address-prefix-length=32 name=RW-cfg split-include=192.168.88.0/24
/ip ipsec peer profile
set [ find default=yes ] enc-algorithm=aes-128
/ip ipsec policy group
add name=RoadWarrior
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-256-cbc,aes-128-cbc
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=proposal1 pfs-group=none
/ip ipsec peer
add auth-method=rsa-signature certificate=TestVPN exchange-mode=ike2 generate-policy=port-strict mode-config=RW-cfg passive=yes policy-template-group=RoadWarrior
/ip ipsec policy
add comment=IKEv2 dst-address=192.168.222.0/24 group=RoadWarrior proposal=proposal1 src-address=0.0.0.0/0 template=yes
0 14.46 ether1 192.168.222.146:68 (bootpc) 255.255.255.255:67 (bootps) udp 342 0 no
1 19.212 ether1 192.168.222.146:68 (bootpc) 255.255.255.255:67 (bootps) udp 342 0 no
2 24.21 ether1 192.168.222.146:68 (bootpc) 255.255.255.255:67 (bootps) udp 342 0 no
I'm a bit sleepy so I've mixed them up, that's all. Good you've found out yourself.I dont really understand what DNS (udp/53) has to do with DHCP (udp/67-68)
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.3.1 192.168.3.122 55
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.3.0 255.255.255.0 On-link 192.168.3.122 311
192.168.3.122 255.255.255.255 On-link 192.168.3.122 311
192.168.3.124 255.255.255.255 On-link 192.168.3.122 56
192.168.3.255 255.255.255.255 On-link 192.168.3.122 311
192.168.222.0 255.255.255.0 On-link 192.168.222.148 46
192.168.222.148 255.255.255.255 On-link 192.168.222.148 301
192.168.222.255 255.255.255.255 On-link 192.168.222.148 301
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.3.122 311
224.0.0.0 240.0.0.0 On-link 192.168.222.148 301
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.3.122 311
255.255.255.255 255.255.255.255 On-link 192.168.222.148 301
===========================================================================
Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.Because it is whole system backup.
Let's imagine the internals of this restoration process. There's a database table with the list of interfaces, their parameters, their MAC addresses, etc. Now you restore it from backup leaving MAC address fields empty (?). So there's no connection between entries in the table and real interfaces. Configuration is in inconsistent state.Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.
It will be greate to add this feature for PPP tunels too (SSTP, L2TP). Now I'm using forwarding DHCP Info packets to external DHCP server for DHCP option 249 (and another DHCP options for Windows clients).*) ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
Then maybe a RSC script that does manual work after a restore. I can Reset MAC on a interface so I get the MAC of the restored to device and not the MAC from the backup.Let's imagine the internals of this restoration process. There's a database table with the list of interfaces, their parameters, their MAC addresses, etc. Now you restore it from backup leaving MAC address fields empty (?). So there's no connection between entries in the table and real interfaces. Configuration is in inconsistent state.Proposal: choice, to omit not on backup but on restore. So you will have allways a full backup and can select on restore if certain values should not be restored.
Don't think about backup like about an /export file. It's a bit different and more low-level thing.
just got word back from support. They have found the problem with split-include and it will be fixes in next beta..ike2 - send split networks over DHCP (option 249) to Windows initiators if DHCP Inform is received;
After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.I want to see HW Off-load enabled in all bridge interfaces, not just one. Specially knowing that you need 1 Bridge per VLAN having this limitation is a killer as I will limit the traffic throughput without unable to get wired speed only in just 1 VLAN. Really?? Seriously??
But with VLAN-aware bridges you have no hw-offload at all!After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.
The config mentioned above - with multiple bridges - was always purely software, and it was the only way for devices without switch chip.But with VLAN-aware bridges you have no hw-offload at all!After implementing vlan-aware bridges with hw-offload you no longer need 1 bridge per vlan.
*) ethernet - fixed linking issues on wAP ac, RB750Gr2 and Metal 52 ac (introduced in v6.43rc52);
That depends. It can be a bug in your client device too. E.g. Ubiquiti access points sometimes lose the default route (or it becomes ineffective) and then you need tricksTurning on "Proxy-arp" for that ethernet interface appears to fix it or at least make it work for hours instead of minutes, although there is no reason to have proxy-arp.
Yeah I was hoping that proxy arp would have a slightly different processing path, and it appears to work. It's a WinCE end device (that is, no routing, just a single IP address) that appeared to work ok with 6.39 across 15 or so units, so I'll probably revert to that and see if it makes a difference. But I've been trawling the changelogs looking for recent ROS ethernet changes, and this is the first one I've come across.It can be a bug in your client device too.
Hence why I suspect it's a bug in ROS.I would not know a legitimate reason why proxy-arp would work and normal arp would not, when the client is correctly configured.
Will devices be able to handle that on its own? Or more important... Will CAPsMAN handle this for connected devices?Nice catch. It is because of the new IKEv2 feature which works with DHCP. I will update the changelog.
Will devices be able to handle that on its own? Or more important... Will CAPsMAN handle this for connected devices?
Nope. Link to the device from the switch is reported as being up by both the device and the switch, but it's completely unpingable. Device can't connect to a server on the same subnet, server or any other IP on the subnet can't ping the device. ARP pings fail as well. Packet sniffing shows ping packets making it to the port that the device is connected to (according to ROS when I packet sniff on the port, anyway), but nothing from the device, not even normal idle packets (arps, windows networking packets,etc). Zero bytes / packets come from the port when the fault is present.While the device cannot communicate (I presume to an outside network, not internal to the LAN subnet), is it still possible to ping the device from the router (i.e. from within the same subnet)?
And is it possible to ping the device from outside and wake-up the stalled connection?
The bug affected all devices. Traffic stopped forwarding when you started to change MSTI VLAN mappings, but you could easily fix it by disabling it and re-enabling it.Hi
regarding the issue:
bridge - fixed packet forwarding when changing MSTI VLAN mappings
could someone from MT please elaborate?
we have been quite unsuccessfull integrating crs317 devices in our network using MSTP
the RSTP from other devices arriving on vlans is simply not being replicated to other memberports of the same VLAN (untagged/tagged).
please advise
hk
AgreedI see some complaining about MS-CHAPv2 support in Winbox. We like the MS-CHAPv2 support for Winbox because it allows us to no longer have to store the passwords unencrypted on the authentication server, so I hope it is retained in some way. We do not wish to go back to regular CHAP in our case.
ABSOLUTELY, security first.AgreedI see some complaining about MS-CHAPv2 support in Winbox. We like the MS-CHAPv2 support for Winbox because it allows us to no longer have to store the passwords unencrypted on the authentication server, so I hope it is retained in some way. We do not wish to go back to regular CHAP in our case.
Security first!
MS-CHAPv2 need clear-text / decryptable password or MD4 hash of password on radius server sideI see some complaining about MS-CHAPv2 support in Winbox. We like the MS-CHAPv2 support for Winbox because it allows us to no longer have to store the passwords unencrypted on the authentication server, so I hope it is retained in some way. We do not wish to go back to regular CHAP in our case.
I cannot find that setting...Version 6.44beta9 has been released.
*) winbox - added 4th chain selection for "HT TX chains" and "HT RX chains" under "CAPsMAN/CAP Interface/Wireless" tab;
I cannot find that setting...
Bettar beta? =)No new beta?
That was evil... well played!
I cannot find that setting...
No, that is a feature!4 chains without mu-mimo it's a joke?
I cannot find that setting...
mimo 4x4 using 2 TX and 2 RX chains works much better than mimo 2x2 using same hardware.No, that is a feature!4 chains without mu-mimo it's a joke?
I cannot find that setting...
I hate You so much...
You Are not really benefiting without mumimo, and Status today ROS doesn’t support MU-Mimo or Wave2 or something else new..mimo 4x4 using 2 TX and 2 RX chains works much better than mimo 2x2 using same hardware.No, that is a feature!4 chains without mu-mimo it's a joke?
I cannot find that setting...
hahahaha
l2tp server ISAKMP-SA deleted problem if dhcp enable solve in 6.44beta28
I can confirm this on LHG60using a w60G and beta28 im not getting any information on the interface page eg
Frequency 64800
Remote MAC
Signal
MCS
PHY Rate
RSSI
TX Sector
TX Sector Info
RX Sector
Distance
All blank, and the quickset page is showing 0 for signal and MCS
Kingsley
I think maybe but just maybe they are ready for the 7v betaHave MikroTik stopped working at new version of RouterOS ?
Please no new 6.44beta...New beta build will be released later today. Had to polish some new features before releasing the version.
No iperf??"/tool speed-test"
[admin@1072_bonding_test_1] > /tool speed-test 192.168.1.2 test-duration=60
;;; results can be limited by cpu, note that traffic generation/termination performance might not be
representative of forwarding performance
status: done
time-remaining: 0s
ping-min-avg-max: 111us / 123us / 2.14ms
jitter-min-avg-max: 0s / 10us / 2.01ms
loss: 0% (0/1200)
tcp-download: 11.6Gbps local-cpu-load:83%
tcp-upload: 12.1Gbps local-cpu-load:89% remote-cpu-load:84%
udp-download: 24.3Gbps local-cpu-load:5% remote-cpu-load:79%
udp-upload: 23.1Gbps local-cpu-load:87% remote-cpu-load:20%
Current implementation allow only include this data into test connection, but waiting for it impacts results, we need to implement data collection as separate connection to get this working, it is in our to-do list.Why there are no tcp-download "remote-cpu-load"?
I ask myself what issues my cAP ac devices have? Can you please give some more information about it?*) wireless - improved system stability for all ARM devices with wireless;
The router could have rebooted due to kernel failure in some rare occasions.I ask myself what issues my cAP ac devices have? Can you please give some more information about it?
*) chr - correctly initialize grant table version 1;
Can you post some screenshots of your peer menu?I have L2PT/IPSEC connections that are "dail on demand" and those are displayed in IPSEC-Peers as entries that are unreachable. This is true, however after the connection is up they are still seen as unreachable (colour red).
Pre-shared key with XAuth was never really supported in IKEv2. Also IKEv2 rfc does not acknowledge XAuth as an authentication method.Hi,
What is the idea of that I can't use IKE2 with "pre shared key xauth" ?
When I try to set it up I get the message in attached picture.
Have you checked BTest?Finally test uses all cores of the routerboard...
This new menu keeps complaining about my IKEv2-PSK configuration. After upgrade, I have 5 entries autogenerated in "/ip ipsec identity", but all of them (except one) show an error:What's new in 6.44beta39 (2018-Nov-27 12:14):
!) ipsec - added new "identity" menu with common peer distinguishers;
Very strange... Below are logs before and after on remote device(77.70.x.x with ROS 6.43).Pre-shared key with XAuth was never really supported in IKEv2. Also IKEv2 rfc does not acknowledge XAuth as an authentication method.Hi,
What is the idea of that I can't use IKE2 with "pre shared key xauth" ?
When I try to set it up I get the message in attached picture.
Very strange... Below are logs before and after on remote device(77.70.x.x with ROS 6.43).Pre-shared key with XAuth was never really supported in IKEv2. Also IKEv2 rfc does not acknowledge XAuth as an authentication method.Hi,
What is the idea of that I can't use IKE2 with "pre shared key xauth" ?
When I try to set it up I get the message in attached picture.
Before - device (46.23.x.x with ROS 6.44beta28)
After - device (46.23.x.x with ROS 6.44beta39)
Thanks very much for the response.g22113, that is not a limitation, simply the warning messages are misleading. The limitation should be - one identity per one initiator peer. We will resolve the issue in the next beta.
The same goes for "this peer is unreachable" warnings - they are not working as expected. Also resolved in the next beta.
i use this config in 6.4.34 in all clients, in the new beta no work the peer, the port-override and main-l2tp no workIsn't the answer two posts above?..
I gave up on btest long time ago, and iperf is not always possibleHave you checked BTest?Finally test uses all cores of the routerboard...
MT Staff: why create speed-test? You already have BTest - develop it!
What if you try:i use this config in 6.4.34 in all clients, in the new beta no work the peer, the port-override and main-l2tp no workIsn't the answer two posts above?..
if upgrade to next version all vpn l2tp/ipsec with this config will they stop working?
.
.
/ip ipsec peer
add exchange-mode=main-l2tp generate-policy=port-override passive=yes secret=SECRETL2TPPASSWORD
add exchange-mode=main generate-policy=port-override passive=yes secret=SECRETL2TPPASSWORD
As stated above, we are aware of the issue and will be fixed in the next beta versions.L2TP/IPSEC no work, the message are "failed to pre-process ph2 packet"
config
# nov/27/2018 17:36:36 by RouterOS 6.44beta39
#
# model = 951G-2HnD
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des
/interface l2tp-server server
set allow-fast-path=yes authentication=mschap2 default-profile=default enabled=yes ipsec-secret=********** use-ipsec=yes
config by default, i have deleted all old config ipsec an created by default
The configuration will automatically convert to the new format on upgrade. If you wish to configure the same configuration on new versions, you have to change the IPsec peer configuration to something like this:i use this config in 6.4.34 in all clients, in the new beta no work the peer, the port-override and main-l2tp no work
if upgrade to next version all vpn l2tp/ipsec with this config will they stop working?
/interface l2tp-server server
set authentication=mschap2 enabled=yes
/ip ipsec peer
add exchange-mode=main-l2tp generate-policy=port-override passive=yes secret=SECRETL2TPPASSWORD
/ip ipsec peer
add exchange-mode=main passive=yes name=l2tpserver
/ip ipsec identity
add generate-policy=port-override auth-method=pre-shared-key secret=SECRETL2TPPASSWORD peer=l2tpserver
Unfurtunately this serial console output is the result of the problem. Not the output from the moment when packages were lost.Netinstall fixed the router. Same package files.
Please read carefully through change log:I gave up on btest long time ago, and iperf is not always possibleHave you checked BTest?Finally test uses all cores of the routerboard...
MT Staff: why create speed-test? You already have BTest - develop it!
As stated above, we are aware of the issue and will be fixed in the next beta versions.
The configuration will automatically convert to the new format on upgrade. If you wish to configure the same configuration on new versions, you have to change the IPsec peer configuration to something like this:i use this config in 6.4.34 in all clients, in the new beta no work the peer, the port-override and main-l2tp no work
if upgrade to next version all vpn l2tp/ipsec with this config will they stop working?
/interface l2tp-server server
set authentication=mschap2 enabled=yes
/ip ipsec peer
add exchange-mode=main-l2tp generate-policy=port-override passive=yes secret=SECRETL2TPPASSWORD
Code: Select all/ip ipsec peer add exchange-mode=main passive=yes name=l2tpserver /ip ipsec identity add generate-policy=port-override auth-method=pre-shared-key secret=SECRETL2TPPASSWORD peer=l2tpserver
Great job. Now a single Btest can saturate a w60 linkPlease read carefully through change log:
*) btest - added multithreading support for both UDP and TCP tests;
Hi!
*) winbox - show "W60G" wireless tab on wAP 60G AP;
Can you please give some more information about this one?Version 6.44beta40 has been released.
*) capsman - fixed "group-key-update" parameter not using correct units;
tested beta version on CCR1072 ?Average Joe will not know how to use iperf. I think target audience for this feature is defferent from iperf users
But it is fun anyway:Why there are no tcp-download "remote-cpu-load"?Code: Select all[admin@1072_bonding_test_1] > /tool speed-test 192.168.1.2 test-duration=60 ;;; results can be limited by cpu, note that traffic generation/termination performance might not be representative of forwarding performance status: done time-remaining: 0s ping-min-avg-max: 111us / 123us / 2.14ms jitter-min-avg-max: 0s / 10us / 2.01ms loss: 0% (0/1200) tcp-download: 11.6Gbps local-cpu-load:83% tcp-upload: 12.1Gbps local-cpu-load:89% remote-cpu-load:84% udp-download: 24.3Gbps local-cpu-load:5% remote-cpu-load:79% udp-upload: 23.1Gbps local-cpu-load:87% remote-cpu-load:20%
Only on test CCR, which you can Netinetall any time!if it is worked without problem, I will install too
exatly, both 1072 are at very critic area, so I will waitOnly on test CCR, which you can Netinetall any time!if it is worked without problem, I will install too
and bgp multithreading support when?Dude multithreading support when?
First the hell has to freeze over....and bgp multithreading support when?
I have the feeling that maybe this will be last beta if not the last is going to a close ending..First the hell has to freeze over....and bgp multithreading support when?
viewtopic.php?f=1&t=141920#p699481
Maybe we have some v7 beta to play with on this Christmas [emoji848][emoji4]
I gave up betting on RouterOS v7 release dates many years ago after incurring significant lossesMe too. I bet Europe MUM
All deployments that are scheduled for deployment are stress-tested here on the table, it just happens to be bonding setup with pair of CCR1072, at that particular moment.tested beta version on CCR1072 ?
The same situation. In DHCP Server/Lease many ip addresses with router MAC address and other.You could check the ARP table of the client to see if it has any strange entries (other IP addresses than the router, with the router's MAC address).
If so you need to debug the client.
I would not know a legitimate reason why proxy-arp would work and normal arp would not, when the client is correctly configured.
(correct subnet on the LAN interface and a default route via the router's IP address)
and bgp multithreading support when?
kind of but not exactlywill still be single-threaded
Enigmatic affirmationkind of but not exactlywill still be single-threaded
Normis beeing Normis.Enigmatic affirmationkind of but not exactlywill still be single-threaded
I had some SFP+ link flapping up to a few times a day before the upgrade to 6.43.7. Since the upgrade I have seen one link flap only. The CRS328 is connected using DAC (FS.com) to my CRS317. I upgraded both switches last Friday.Do any of the CRS328 fixes have anything to do with the SFP+ link up down issue?
[admin@MikroTik] > :global firmware [ / interface lte firmware-upgrade lte once as-value ];
[admin@Mikrotik] > :put ($firmware->"installed")
MikroTik_CP_2.160.000_v010
[admin@MikroTik] > :put ($firmware->"latest")
MikroTik_CP_2.160.000_v010
[admin@MikroTik] > :if (($firmware->"installed") != ($firmware->"latest")) do={ :put "Versions differ!"; }
Versions differ!
[admin@MikroTik] >
After restoring my settings I can not set the country for my interface:Updated wAP LTE to version 6.44beta50 and lost the wireless package. :-/
The LTE connection was really weak, though - no idea if that caused the issue.
[admin@MikroTik] /interface wireless> set country=germany wlan1
failure: only regulatory-domain mode allowed for this country
What is this about?.. Why is this marked as important?!) telnet - do not allow to set "tracefile" parameter;
That works, thanks! Can this be the cause for my trouble with wireless package?set frequency-mode to regulatory-domain
That works, thanks! Can this be the cause for my trouble with wireless package?set frequency-mode to regulatory-domain
*) package - use bundled package by default if standalone packages are installed as well;
Ah, right, that could cause the culprit. But I have standalone packages, no bundle.That works, thanks! Can this be the cause for my trouble with wireless package?set frequency-mode to regulatory-domainwhat set of packages did you have? and what did you use to upgrade?Code: Select all*) package - use bundled package by default if standalone packages are installed as well;
/ system package upgrade install
The wireless package did no longer show under System/Package, had to copy the npk file manually to recover. Tried to reproduce with a mAP lite that has very similar configuration, but its update succeeds (and regulatory-domain was updated correctly).What do you mean with lost package? Did you actually lose wireless package under System/Packages menu or wireless interface did not work properly?
I wouldn´t call the RB4011 unstable, but I simply cannot connect to it with Intel AC-8260 on 5.0Ghz. There´s no problem wuth cAP AC, though. Both are running the same config pushed by CAPSMAN controller. May I ask what kind of wireless instability is fixed with ARM based devices?Version 6.44beta50 has been released.
*) wireless - improved system stability for all ARM devices with wireless;
It is not good. Have you been thinking about the fact that not everyone reads changelogs before upgrade?If you have set EU country under wireless configuration, but you did not use regulatory-domain, then configuration will be changed to fit these requirements. Otherwise you violate the law. So if you are legal, then everything will work just fine after an upgrade
emils - Unfortunately, not possible. When it is happening, I ask my router to generate supout and it sits there not responding. I tried stopping and restarting and I get "Couldn't start - busy (12)". I'll keep trying though.mducharme, please generate a supout.rif file when the issue is present and send it to support@mikrotik.com
We use official sources for frequencies allowed in each country. Are you sure you are correct on this one? We use information from Qualcomm chip and European Union.This frequency is not legal in our country. And this problem is due to simple upgrade RouterOS :(
There was some obscure proof of concept that allowed to do strange things, but it only affected you if you gave a user account to the attacker.What is this about?.. Why is this marked as important?!) telnet - do not allow to set "tracefile" parameter;
Then we need Option to set Indoor or Outdoor use!Honzam
We use official sources for frequencies allowed in each country. Are you sure you are correct on this one? We use information from Qualcomm chip and European Union.This frequency is not legal in our country. And this problem is due to simple upgrade RouterOS :(
+1Which ETSI you are comply with? Because as I know there is a band between 5470MHz to 5725Mhz, this leting me select this variety of frequencies, but if YOU apply on your restrictions, I cannot use 5480MHz, why?
cannot use 5480MHz, why?
.Then we need Option to set Indoor or Outdoor use!
5180-5320 in Germany is only allowed for Indoor use!
You must manually used allowed frequency, but you are right, next beta will have "auto" frequency follow the country "indoor/outdoor" rules, you will have a new setting for that.I set the frequency 5640 - in log say - radar detected on 5640. The AP is automatically tuned to the 5240 frequency.
This frequency is not legal in our country (Czech)
No, there are no files at all in the files menu. I had rebooted and tried again. It is still trying to generate the supout 5 hours later.Most likely a supout.rif file is already generating in the backgound. Is there an autosupout.rif file in the Files menu?
Does not respect outdoor / indoor settings for EU countries.Honzam
We use official sources for frequencies allowed in each country. Are you sure you are correct on this one? We use information from Qualcomm chip and European Union.This frequency is not legal in our country. And this problem is due to simple upgrade RouterOS :(
Did you try Scanlist 5470-5720 ???Does not respect outdoor / indoor settings for EU countries.Honzam
We use official sources for frequencies allowed in each country. Are you sure you are correct on this one? We use information from Qualcomm chip and European Union.This frequency is not legal in our country. And this problem is due to simple upgrade RouterOS :(
In Czech Republic is outdoor 5500-5700. Indoor is 5180-5320.
After upgrade (6.44beta50) is AP running (with auto enabled DFS) on channel 5280 which is indoor !!! But selected channel is 5620. Thanks
I know the scan list will solve it. But would you think that this line:Did you try Scanlist 5470-5720 ???
I experienced the same on my ccr, only chance was to downgrade to latest stable firmware.No, there are no files at all in the files menu. I had rebooted and tried again. It is still trying to generate the supout 5 hours later.Most likely a supout.rif file is already generating in the backgound. Is there an autosupout.rif file in the Files menu?
If I go to the command line and type "/ip ipsec export" it also hangs forever.
First of all, this is a BETA release which should not be used anywhere near production.means you need to create a scan list before upgrading RouterOS to 6.44? I find it unclear and it cause a number of problems....
The fact that the EU forces Mikrotik to comply with the law is clear to me
The main point is that there is going to be a move from the outdoors to the indoors. Outdoor frequencies 5500-5700 are tuned anywhere from 5180 to 5700. So quietly indoors which is not legally correct. Is it written clearly?What do you mean by that? With scan list you will only reduce number of frequencies. After an upgrade your list will use all frequencies that are available in your country. From previous version point of view, nothing has been changed related to scan list or indoor/outdoor solutions. Indoor/outdoor selection should be introduced in upcoming beta versions.
Yes, I known. I tested it on non production part of network.
First of all, this is a BETA release which should not be used anywhere near production.
Yes, that's exactly what I was suggesting. Divide it into indoor / outdoorWe have made a new setting for one of the next BETA releases, that will honour the "indoor/outdoor" parameter in the country-info list, and will not move you to an indoor-only frequency, so you will not have to make any custom scan lists.
THIS IS NOT CORRECT! try to read this link and you will have a CLEAR knowledge which is allowed in Czech Republic and which is not ... https://www.ctu.cz/cs/download/oop/rok_ ... 010-12.pdfDoes not respect outdoor / indoor settings for EU countries.Honzam
We use official sources for frequencies allowed in each country. Are you sure you are correct on this one? We use information from Qualcomm chip and European Union.This frequency is not legal in our country. And this problem is due to simple upgrade RouterOS :(
In Czech Republic is outdoor 5500-5700. Indoor is 5180-5320.
After upgrade (6.44beta50) is AP running (with auto enabled DFS) on channel 5280 which is indoor !!! But selected channel is 5620. Thanks
I know this document. What exactly is wrong?THIS IS NOT CORRECT! try to read this link and you will have a CLEAR knowledge which is allowed in Czech Republic and which is not .
outdoor is exactly 5470MHz-5725MHz not 5500MHz-5700MHz mentioned by you in older posts .. indoor exactly 5150MHz-5350MHz not 5180MHz-5320MHz mentioned by you.I know this document. What exactly is wrong?
Yes it is 5470-5725Mhz , but it is commonly referred to as I wrote. (fully channels)outdoor is exactly 5470MHz-5725MHz not 5500MHz-5700MHz mentioned by you in older posts .. indoor exactly 5150MHz-5350MHz not 5180MHz-5320MHz mentioned by you.I know this document. What exactly is wrong?
If Mikrotik wants to restrict use of superchannels, they have to follow ETSI/CZ rules at least. They don't. They push us to not using "czech_republic" settings, if we wants to be comply with our laws rules.Yes it is 5470-5725Mhz , but it is commonly referred to as I wrote. (fully channels)
They push us to not using "czech_republic" settings, if we wants to be comply with our laws rules.
Which channel width do you use when trying to set centre frequency to 5480MHz?... and second, according to CZ rules I can set 5480MHz ...
The "Outdoor" setting is already in released versions, it's called "installation=outdoor/indoor/any".They push us to not using "czech_republic" settings, if we wants to be comply with our laws rules.
That's not true. Please read this thread carefully. The next Beta release will have indoor/outdoor option, so I guess the next stable release for your production environment will have it too.
Unfortunately the change to regulatory conformance was badly communicated by Mikrotik in the release notes.
What will be more of a concern is the future of Omnitik 5 devices in Europe. The regulators are about to shut them down soon. Let's hope Mikrotik really can prevent this from happening.
5480Ce in Poland too. 5470-5725.Which channel width do you use when trying to set centre frequency to 5480MHz?... and second, according to CZ rules I can set 5480MHz ...
What exactly have you configured currently? Are you creating multiple IPsec identities and specifying different remote-certificates for each of them? Are these certificates from the same CA chain? That is not quite how we planned it to work. There is a 'remote-id' parameter, which is not in Winbox and is not implemented fully yet. You will be able to match the IPsec identity to a specific peer by this parameter.mutiple mode-config doesn't be as intended with certificate matching.
I've tried to add 2 mode-configs and i want to assign a different ip pool each.
apart the fact that is better to implement an object of type "list" populated with multiple certificate, currently it's impossible to add multiple client certificate matching...
policy matching chould be intended as this, imho:
a group of client certificates that, when matched with a specific mode-config policy, assign an ip pool and a split tunnel.
currently it's impossible to add a group of client certificate, just one cert.
Moreover, and this is what isn't working, the client check just the first mode-config policy and if it's not matched skips the others. It should be a sequential checking trough the all mode-config matching policy...
Strods;doush - Unfortunately we can not tell from description "lockups" to what kind of problem you are referring to. Please contact support@mikrotik,com directly, provide proper problem description (when did problem start to appear, how often do you see this issue, do you have any information what processes might trigger lockup) and supout file from your router/s. At the moment there are no known bugs that would lock up router. Either this is an unknown problem, hardware related issue or it is a configuration related problem. Without debugging we can not tell why is this happening with your router. At the moment of "lockup" can you access router over serial console?
And where is the version specific part of this? As I see it it's nothing new to this beta.... So please stay in the other thread.
When watchdog is on, it reboots.
Please work with us in this issue.
This problem is still valid with the latest stable build !And where is the version specific part of this? As I see it it's nothing new to this beta.... So please stay in the other thread.
When watchdog is on, it reboots.
Please work with us in this issue.
*) dhcpv6-server - allow to add DHCPv6 server with pool that does not exist;
Did you even read my post ?doush Nobody except you complains, which means it's either faulty hardware or a configuration specific issue. A couple of posts ago you said you are not willing to supply support@ with the info they asked you for. Being software developer myself, I can assure you this is a road to nowhere...
Normis, are you work for ubnt?"My router reboots" is a very generic problem, all kinds of issues are gathered in that topic.
!) cloud - added command "/system backup cloud" for backup storing on cloud (CLI only);
[admin@MikroTik] /system backup cloud> print
-- connecting
Server error: Backend error. Try again later.
The copyright notice still has a link with http-schema. You should really change that to https.*) console - updated copyright notice;
Thanks, have to play with this...*) ipsec - added new "remote-id" peer matcher;
Thanks for fixing!*) lte - fixed DHCP IP acquire in 3G mode for r11e-lte (introduced in v6.44beta54);
That change is very welcome. Thanks a lot!*) ssh - close active SSH connections before IPsec connections on shutdown;
/system telnet 10.2.0.16
Trying 10.2.0.16...
Connected to 10.2.0.16.
Escape character is '^]'.
MikroTik v6.43.8 (stable)
Login:
Version 6.44beta61 has been released.
rb4011 - improved SFP+ interface linking to 1Gbps;
The RB4011 is not an actively-cooled device so it will never be compatible with the S-RJ01.Does this mean the S-RJ01 is now compatible with the RB4011?
The compatibility table disagrees with You:The RB4011 is not an actively-cooled device so it will never be compatible with the S-RJ01.Does this mean the S-RJ01 is now compatible with the RB4011?
Look at the S-RJ01 page. It is only for actively-cooled devices!
Hopefully some time, after yet more advances in technology, it will be possible to produce and SFP+ ethernet adapter that does not dissipate so much power.
Then it could work.
What's new in 6.44beta61 (2019-Jan-17 13:24):
*) rb4011 - improved SFP+ interface linking to 1Gbps;
/interface ethernet
set sfp-sfpplus1 auto-negotiation=yes full-duplex=yes&no speed=1Gbps # link
set sfp-sfpplus1 auto-negotiation=yes full-duplex=no speed=10Mbps # link (detected/actual rate 1Gpbs FD)
set sfp-sfpplus1 auto-negotiation=yes full-duplex=yes&no speed=100Mpbs # flapping
set sfp-sfpplus1 auto-negotiation=yes full-duplex=yes&no speed=10Gbps # flapping
set sfp-sfpplus1 auto-negotiation=no full-duplex=yes speed=1Gbps # link
set sfp-sfpplus1 auto-negotiation=no full-duplex=no speed=1Gbps # router crash
set sfp-sfpplus1 auto-negotiation=no full-duplex=yes&no speed=10Mbps # link (detected rate 10Mbps, actual rate 1Gpbs)
set sfp-sfpplus1 auto-negotiation=no full-duplex=yes&no speed=100Mbps # flapping
set sfp-sfpplus1 auto-negotiation=no full-duplex=yes speed=10Gbps # no link
The RB4011 is not an actively-cooled device so it will never be compatible with the S-RJ01.
The compatibility table disagrees with You:
https://wiki.mikrotik.com/wiki/MikroTik ... lity_table
The S-RJ01 is supported on the CSS/CRS326-24G-2S+ models - and they are passive cooled switches. Also, they run on RB3011, RB2011, RB260 and many others passively cooled devices.
Yes, it is weird. I have no idea where this limitation comes from.The RB4011 is not an actively-cooled device so it will never be compatible with the S-RJ01.
The compatibility table disagrees with You:
https://wiki.mikrotik.com/wiki/MikroTik ... lity_table
The S-RJ01 is supported on the CSS/CRS326-24G-2S+ models - and they are passive cooled switches. Also, they run on RB3011, RB2011, RB260 and many others passively cooled devices.
Yeah, I guess its not clear what works unless one consults the compatibility table. So, the S+RJ10 does work, but the S-RJ01 does not? I have not been able to get my S-RJ01 to work with the RB4011 and was hoping it was only a software issue.
Anyway management interfaces, be it Winbox, APIs, ssh, web and whatnot should never be exposed without proper filtering. So the version display is harmless in my opinion.security by obscurity
This one looks promising and, indeed, there is a clear improvement.Version 6.44beta61 has been released.
*) rb4011 - improved SFP+ interface linking to 1Gbps;
+1Please remove OS version from telnet. It is not needed.
I agree. If the untrusted person can see your TELNET interface, you are in much bigger trouble than an exposed version numberAnyway management interfaces, be it Winbox, APIs, ssh, web and whatnot should never be exposed without proper filtering. So the version display is harmless in my opinion.security by obscurity
Yes, with the latest beta S-RJ01 also should work.Version 6.44beta61 has been released.
rb4011 - improved SFP+ interface linking to 1Gbps;
Does this mean the S-RJ01 is now compatible with the RB4011?
But it saves the untrusted person the trouble to test which tool to use. Or just see on forehand that none of the available tools is going to work and moves on.I agree. If the untrusted person can see your TELNET interface, you are in much bigger trouble than an exposed version numberAnyway management interfaces, be it Winbox, APIs, ssh, web and whatnot should never be exposed without proper filtering. So the version display is harmless in my opinion.security by obscurity
The Interface/Ethernet section of the documentation should be updated as well.Yes, with the latest beta S-RJ01 also should work.Version 6.44beta61 has been released.
rb4011 - improved SFP+ interface linking to 1Gbps;
Does this mean the S-RJ01 is now compatible with the RB4011?
We will update compatibility table when this fix will be included in the stable version.
Anyway management interfaces, be it Winbox, APIs, ssh, web and whatnot should never be exposed without proper filtering.
This isn't true for SSH:I agree. If the untrusted person can see your TELNET interface, you are in much bigger trouble than an exposed version numberAnyway management interfaces, be it Winbox, APIs, ssh, web and whatnot should never be exposed without proper filtering. So the version display is harmless in my opinion.security by obscurity
telnet 192.168.88.1 22
Trying 192.168.88.1...
Connected to 192.168.88.1.
Escape character is '^]'.
SSH-2.0-ROSSSH
It works for me. Please check the IPsec debug logs and find out what ID_I and ID_R fields are actually received from the client.Installed 6.44beta61, but it seems there are issues with "/ip ipsec identity my-id" matching for fqdn:, user-fqdn: and even address:ipv4 types. It doesn't seem to work with Remote ID on iOS devices with IKEv2 in pre-shared-key mode.
10:35:04 ipsec processing payload: ID_I
10:35:04 ipsec ID_I (RFC822): usera@domain.com
10:35:04 ipsec processing payload: ID_R
10:35:04 ipsec ID_R (ADDR4): 10.155.130.204
/system logging add topics=ipsec,!debug
/certificate
add name=my.ca common-name=my.ca key-usage=key-cert-sign,crl-sign
sign my.ca
add name=vpn.server common-name=vpn.server subject-alt-name=DNS:vpn.company.com key-usage=tls-server
sign vpn.server ca=my.ca
add name=vpn.client.ios common-name=vpn.client.ios key-usage=tls-client
sign vpn.client.ios ca=my.ca
add name=vpn.client.macos common-name=vpn.client.macos key-usage=tls-client
sign vpn.client.macos ca=my.ca
add name=vpn.client.windows common-name=vpn.client.windows key-usage=tls-client
sign vpn.client.windows ca=my.ca
/certificate
export-certificate my.ca
export-certificate vpn.client.ios export-passphrase=1234 type=pkcs12
export-certificate vpn.client.macos export-passphrase=1234 type=pkcs12
export-certificate vpn.client.windows export-passphrase=1234 type=pkcs12
/ip ipsec policy group
add name=ike2
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=ike2
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1d name=ike2 pfs-group=none
/ip ipsec policy
add comment=ike2 group=ike2 proposal=ike2 template=yes
/ip pool
add name=ike2 ranges=192.168.88.100-192.168.88.150
/ip ipsec mode-config
add address-pool=ike2 name=ike2
/ip ipsec peer
add comment=ike2 exchange-mode=ike2 name=ike2 passive=yes profile=ike2
/ip ipsec identity
add auth-method=rsa-signature certificate=vpn.server generate-policy=port-strict mode-config=ike2 my-id=fqdn:vpn.company.com \
peer=ike2 policy-template-group=ike2 remote-certificate=vpn.client.ios remote-id=fqdn:vpn.client.ios
add auth-method=rsa-signature certificate=vpn.server generate-policy=port-strict mode-config=ike2 my-id=fqdn:vpn.company.com \
peer=ike2 policy-template-group=ike2 remote-certificate=vpn.client.macos remote-id=fqdn:vpn.client.macos
add auth-method=rsa-signature certificate=vpn.server generate-policy=port-strict mode-config=ike2 \
peer=ike2 policy-template-group=ike2 remote-certificate=vpn.client.windows
Type: IKEv2
Server: vpn.company.com
External ID: vpn.company.com
Local ID: vpn.client.ios
User authentication: None
Use certificate: Yes
Certificate: vpn.client.ios
Type: IKEv2
Server: vpn.company.com
External ID: vpn.company.com
Local ID: vpn.client.macos
User authentication: None
Use certificate: Yes
Certificate: vpn.client.macos
$securePassword = ConvertTo-SecureString -String "1234" -AsPlainText -Force
Import-PfxCertificate -FilePath cert_export_vpn.client.windows.p12 -CertStoreLocation Cert:\LocalMachine\My -Password $securePassword
Import-Certificate -FilePath cert_export_my.ca.crt -CertStoreLocation Cert:\LocalMachine\Root
Add-VpnConnection -Name "Company" -ServerAddress vpn.company.com -TunnelType Ikev2 -AuthenticationMethod MachineCertificate
Set-VpnConnectionIPsecConfiguration -ConnectionName "Company" -AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 `
-DHGroup Group14 -PfsGroup None -Force
Yes, please! Hooking a script would be much appreciated. Currently I have a script running every 30 seconds to update gre interfaces...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.
Wireguard is not a better VPN. It is an immature product with a vocal community around it.Much time spent on ipsec when one could spend time on wireguard and have better VPN.
Separate but related...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.
[...]
And another thing about GRE + IPSec with cert auth. This one really looks like a bug.Separate but related...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'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?
kmansoft, It's not a bug, it's a feature, and definitely not version-related.Not sure if it's new in 6.44 or was there before.
/ip ipsec policy
add comment=myservertunnel dst-address=139.0.0.1/32 protocol=gre src-address=89.0.0.1/32