What’s the version of the source?
dash, it will be fixed in the next beta, however you will need to have the same version on server and client (either both pre-6.45 or both post-6.45).
filzek, you can connect to NordVPN servers using IKEv2.
Source is 6.45.1, client that tries to update is 6.44.3.
Acording to Emils comment this seems to be a known issue and will be resolved in one of the next beta versions.
thx
Version 6.46beta9 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.46beta9 (2019-Jul-11 09:04):
Changes in this release:
*) bonding - fixed bonding running status after reboot when using other bonds as slave interfaces (introduced in v6.45);
*) bonding - properly handle MAC addresses when bonding WLAN interfaces;
*) dhcpv6-server - include “User-Name” parameter in accounting requests;
*) ipsec - added “connection-mark” parameter for mode-config initiator;
*) ipsec - allow peer argument only for “encrypt” policies (introduced in v6.45);
*) ipsec - fixed peer configuration migration from versions older than v6.43 (introduced in v6.45);
*) ipsec - show warning for policies with “unknown” peer;
*) ospf - fixed possible busy loop condition when accessing OSPF LSAs;
*) ppp - disable DTR send when using at-chat;
*) ssh - do not enable “none-crypto” if “strong-crypto” is enabled on upgrade (introduced in v6.45);
*) ssh - fixed executed command output printing (introduced in v6.45);
*) supout - fixed supout file generation outside of internal storage with insufficient space;
*) upgrade - fixed “auto-upgrade” to use new style authentication (introduced in v6.45);
*) usb - general USB modem stability improvements;
*) userman - updated Authorize.Net to use SHA512 hashing;
*) vlan - fixed “slave” flag for non-running interfaces (introduced in v6.45);
*) winbox - properly show timestamp in file “Creation Time” field;
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.
- !) upgrade - fixed “auto-upgrade” to use new style authentication (introduced in v6.45);
To get a new authentication working, you have to do the following steps:
- Downgrade server to one of the previous versions below v6.45;
- Configure user password once more to get the old authentication method working;
- Update server to the v6.46beta9;
- Then update all the hosts to the v6.46beta9;
“auto-upgrade” feature now is working with new style authentication.
Great, thanks a lot for this! Much appreciated.
Is any of the other ipsec changes suppose to fix my issue from Ticket#2019070222004609?
*) ipsec - added “connection-mark” parameter for mode-config initiator (CLI only);
Thanks and I am going to test is later. I was looking where is was hidden in Winbox and could just not find it. It is for now CLI only. 
ip - ipsec - mode-config
Don’t you mean v6.4**6**beta9?
Yes, I did the necessary corrections.
Update: problem tackled with help of mkx. In the previous Beta EAP for ikev2 was made available and I needed to split all over two routers. It needed changes in Hairpin, which broke the catching traffic better be served locally.
I have an problem I can’t explain with dstnat to an local address on UDP. I catch DNS requests going out to external DNS servers and I am redirecting those to a local DNS server. I have the suspicion that since late in 6.45beta something changed that does not replace local answering with the caught external address IP on the way back from the router to the client.
When I use torch then the traffic is returned from the internal DNS server to the router.
!DNSservers contains the local DNS server IP.
chain=dstnat action=dst-nat to-addresses=192.168.0.4 protocol=udp src-address-list=!DNSservers dst-port=53,123 log=no log-prefix="DNS out catch"
When I run a dig
#>dig mikrotik.com @8.8.8.8
;; reply from unexpected source: 192.168.0.4#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.0.4#53, expected 8.8.8.8#53
;; reply from unexpected source: 192.168.0.4#53, expected 8.8.8.8#53
; <<>> DiG 9.10.8 <<>> mikrotik.com @ 8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached
Update: Torching the Bridge I see the traffic directly being returned from the internal DNS to the client and so skipping the router.
MANY THANKS! To mkx for helping me solving this.
Do you have proper hair-pin NAT implemented? The single dstnat rule you’ve shown only does things half-way:
- UDP packet with dst-address=8.8.8.8 arrives at router (src-address=192.168.0.x)
- router uses dstnat rule to replace dst-address to dst-address=192.168.0.4 … src-address remains set to 192.168.0.x
- router delivers DNS query to the internal DNS server.
- DNS server prepares reply for sender, which is 192.168.0.x
- DNS server sends reply directly as the client is on the same IP subnet (dst-address=192.168.0.x src-address=192.168.0.4)
- as the reply bypasses router with it’s NAT engine, client receives answer with src-address=192.168.0.4 (while expecting answer from 8.8.8.8 because that’s where it sent the query)
For things to properly unroll for the reply, router would have to perform additional step between steps 2 and 3 … changing src-address to its own.
All of my explanation above is void if you have matching src-nat rule in power
/ip firewall nat
add action=src-nat chain=srcnat src-address-list=!DNSservers dst-address=192.168.0.4 to-address=192.168.0.1
# assuming that router's address in 192.168.0.0/24 subnet is this
You can currently at least use the upgrade function to trigger a reboot of the CAPs, even when there is no new RouterOS:
/caps-man remote-cap
upgrade [find]
Seems to have fixed the display of OSPF LSAs as well as printing them via terminal.
I am tethering internet from Android 9 phone to ac^2 via USB.
After upgrade USB kept disconnecting within 5-20 mins. I had to re-connect the cable to be able to turn on USB tethering on the phone.
Rollback to 6.45.1 resolved the issue.
Hex upgraded to 6.46beta9. When USB modem plugged in, device continuously reboots itself. Removing USB modem resolves this issue.
This works perfectly fine! Would like to see it in a stable release as soon as possible… But I guess I have to wait for 6.46 final?
Thanks for the feedback. We will try to add it in the 6.45.2 as well. It will also be possible to specify both the src-address-list and connection-mark parameters to form a single NAT rule. If anyone is wondering, currently an example is published here.
confirming the fix in 6.46beta9. Thx for taking care
Hi Guys
I have now seen an issued with DHCP server, when using a relay and adding arp
/ip dhcp-server
add add-arp=yes address-pool=vlan_10 dhcp-option-set=phones disabled=no interface=10_br name=vlan10_voice relay=255.255.255.255 src-address=172.168.17.1
The wrong arp mac-address is added for the lease, it adds the mac of the relay that sends the dhcp request.