Hello,
Upgraded CCR1036 v6.48.6 to v7.2.3 , ipsec tunnel was established, but incoming packets were not matching against DST_NAT rule. So the traffic was not able to pass the tunnel.
Rolled back to v6 and all is good.
Is it going to be fixed in next v7 release ?
So something with IPSec and dstnat works for you in v6 and not in v7. You didn’t share any details beyond that, so nobody can really know what’s happening. And you’d like to know if it’s going it change. I don’t think we can tell you without knowing what exactly it is.
I have shared enough details to see, that problem is in v7. DST-NAT stops working as soon as upgraded to v7, when back to v6, it works fine with ipsec.
If you need something else, please ask
No, you didn’t share any details. You just wrote that some dstnat rule supposedly broke in v7 and it’s probably somehow related to IPSec tunnel, because you mentioned it. That’s all. You didn’t share the dstnat rule, didn’t explain how it’s related to IPSec tunnel, nothing.
As far as I can tell, dstnat in v7 works just fine, exactly the same way it worked in v6. So if you were unlucky to discover some corner case where it doesn’t, and you want some help with that, you should provide some actual details. For example, posting exported config and explaining important parts often leads to great success.
Dst-nat rule contains ipsec tunnel far-end server address as src and ipsec tunnel peer ip address as dat address, then it makes dst-nat to my interneal host.
As soon as I upgrade to v7, matching to that rule dissapears, no matter I set incoming interface or not.
I can tell you that
/ip firewall nat
add src-address=X dst-address=Y action=dst-nat to-addresses=Z
is simple rule that definitely works in v7. If yours doesn’t, then it’s probably caused by something else in your config, but since nobody else has any idea what you might have there…
simple ipsec with 3des, which is established and this dst-nat rule. that’s all.
I saw another post where the same v7 problem is described [ somehow related to nat ]
just imagine, something works good on v6 for years and after upgrade rule stops matching, back and that’s good. exactly the same thing other users are reporting
/ip ipsec policy group
add name=group2
/ip ipsec profile
add enc-algorithm=3des name=profile_1
/ip ipsec peer
add address=remote_peer_public_ip/32 local-address=local_peer_public_ip name=to_company_x profile=profile_1
/ip ipsec proposal
set [ find default=yes ] disabled=yes enc-algorithms=aes-128-cbc
add enc-algorithms=3des name=to_company_x pfs-group=none
/ip ipsec identity
add peer=to_company_x secret=“somesecret”
/ip ipsec policy
set 0 disabled=yes
add dst-address=remote_server_ip/32 level=unique peer=to_company_x proposal=to_company_x src-address=local_public_ip/32 tunnel=yes
/ip firewall nat
add action=dst-nat chain=dstnat comment=“” dst-address=local_public_ip src-address=remote_server_ip to-addresses=local_server_ip
Requests are coming from remote server, to local server
That sure is a strange setup, probably not many users have that.
But probably it should work…
Anyway, it would be better to study and understand the concept of a tunnel. Then you do not need the NAT.
I know the purpose of the tunnels.
This tunnel is peering a bank, which needs public Ip on my side as a service dest., that’s why dst nat is needed as intrernal server of the company sits in private pool.
It worked fine for 8 years till v7 and it’s very usual practice in such scenarios. Hope it’s clear now
I have never seen it before.
Seems clear enough, but I don’t see why it shouldn’t work. I’ll try to test it and I’m pretty sure it will be ok.
Test it on ccr, as some of the reports say ccr has this problem. Mine also is ccr1036
Sorry, I don’t have any. I tried CHR and it works as expected, no problem. But if it should happen only with one architecture, and if you have spare device, then try to reproduce it with minimal config, just tunnel and one dstnat rule. If you succeed (and it won’t work), you can report it to MikroTik and they should be able to reproduce it too and fix it. If it will work, then you’ll have to find what difference between real and this minimal testing config is responsible for it.
I Have the same problem with IPsec after upgrade from V6.49.6 to V7.5 on CCR1016
I’m sure that it works fine if configured properly.
How does the v7 configuration looks like? Post an export.
Form release topic:
This is too general, it may depend on how you have configured the device.
There have been many changes from 6.x to 7.x, especially in BGP and Routing,
which probably make the configuration incompatible with what you expect.
Indeed, now I also add:
It is perfectly useless to write like this.
If you do not provide an export before the update, an export after, and you do not create a supout
and do not send everything to support@mikrotik.com accompanied by an adequate description,
it is perfectly useless, it could also be fake, and it could also be a very trivial configuration error.
I have problems with IPSEC too.
I have simple setup:
server<—lan—>routerboard1(ROS7)<—wireguard–>routerboard2(ROS7)<----l2tp/ipsec---->routerboard3(ROS6)
After upgrading routerboard2 from ROS 6.48.6 lts to ROS 7.5 stable - clients behind routerboard3 lost access to server. If i switch from l2tp/ipsec to simple pptp it works fine. Or i have to downgrade routerboard2 back to ROS6 to make it work again.
Is it a bug or feature?