After Upgrade from 6.49.1 to 7.1 ipsec Site-Site not working

RouterOS General
1

I have recently bought CCR2004 with 7.1 soft. I have Configured ipsec Site-Site tunnel according to instruction on many sites. Tunnel was established between CCR2004 soft 7.1 and RB3011 soft 6.49.1)
eg. https://www.informaticar.net/how-to-establish-site-to-site-vpn-with-mikrotik-routers/
Tunnel is established but there is not transfer between sites. Of course there is a rule in NAT (in the first place) that accepts packets form sites not to go through NAT.

I put the same configuration to router RB4011 with soft 6.49.1. Tunnel is established between RB4011 (6.49.1) and RB3011 (6.49.1). Everything is working OK communication between sites is working OK.

After upgrade RB4011 from 6.49.1 to 7.1 communication stopped working. No packed are transferred through IPSEC Tunnel. Tunnel itself is established, but no packet between sites are going…
Is there anything special that should I setup on 7.1 soft or this is just a bug of 7.1 soft (I have tried 7.1 rc7, but the problem persists). I don’t have access to older soft from 7 version…

My configuration of IPSEC tunnel is simple:
IPSEC Configuration RB4011/CCR2004 v7.1 OS
LAN IP SRC RB4011/CCR2004 v7.1 OS: 192.168.10.1/24
LAN IP RB3011 (Poznan) v6.49.1 OS: 192.168.29.1/24

/ip ipsec profile add dh-group=modp1024 enc-algorithm=3des name=Phase2
/ip ipsec peer add address=111.111.111.22/32 name=Poznan profile=Phase2
/ip ipsec proposal add enc-algorithms=3des lifetime=1h name=Phase1
/ip ipsec identity add peer=Poznan remote-id=ignore secret=PoznanPassword
/ip ipsec add dst-address=192.168.29.0/24 peer=Poznan proposal=Phase1 src-address=192.168.10.0/24 tunnel=yes

IP NAT (in the beginning of roules)
/ip firewall nat add action=accept chain=srcnat dst-address=192.168.10.0/24 src-address=192.168.29.0/24
/ip firewall nat add action=accept chain=srcnat dst-address=192.168.29.0/24 src-address=192.168.10.0/24
2

I am also confirming the problem.

3

Same here + L2TP IPSEC Clients can’t connect.
CCR1016-12G

L2TP Clients connects and fails with error “server did not respond”

14:12:59 ipsec,info respond new phase 1 (Identity Protection): 212.114.xx.xx[500]<=>80.187.82.203[500]
14:12:59 ipsec received Vendor ID: RFC 3947
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-08
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-07
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-06
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-05
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-04
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
14:12:59 ipsec received Vendor ID: draft-ietf-ipsec-nat-t-ike-02\n
14:12:59 ipsec received Vendor ID: FRAGMENTATION
14:12:59 ipsec Fragmentation enabled
14:12:59 ipsec received Vendor ID: DPD
14:12:59 ipsec 80.187.xx.xxSelected NAT-T version: RFC 3947
14:12:59 ipsec sent phase1 packet 212.114.xx.xx[500]<=>80.187.82.203[500] 6808335ad5fa9786:355bce9f67760205
14:12:59 ipsec NAT detected: ME PEER
14:12:59 ipsec Adding remote and local NAT-D payloads.
14:12:59 ipsec sent phase1 packet 212.114.xx.xx[500]<=>80.187.82.203[500] 6808335ad5fa9786:355bce9f67760205
14:12:59 ipsec NAT-T: ports changed to: 80.187.82.203[14545]<=>212.114.xx.xx[4500]
14:12:59 ipsec KA list add: 212.114.xx.xx[4500]->80.187.82.203[14545]
14:12:59 ipsec 80.187.xx.xxignore INITIAL-CONTACT notification, because it is only accepted after phase1.
14:12:59 ipsec,info ISAKMP-SA established 212.114.xx.xx[4500]-80.187.82.203[14545] spi:6808335ad5fa9786:355bce9f67760205
14:13:00 ipsec respond new phase 2 negotiation: 212.114.xx.xx[4500]<=>80.187.82.203[14545]
14:13:00 ipsec searching for policy for selector: 212.114.xx.xx:1701 ip-proto:17 <=> 80.187.82.203:59792 ip-proto:17
14:13:00 ipsec generating policy
14:13:00 ipsec Adjusting my encmode UDP-Transport->Transport
14:13:00 ipsec Adjusting peer's encmode UDP-Transport(4)->Transport(2)
14:13:00 ipsec sent phase2 packet 212.114.xx.xx[4500]<=>80.187.82.203[14545] 6808335ad5fa9786:355bce9f67760205:00001611
14:13:00 ipsec IPsec-SA established: ESP/Transport 80.187.82.203[14545]->212.114.xx.xx[4500] spi=0xb40aa34
14:13:00 ipsec IPsec-SA established: ESP/Transport 212.114.xx.xx[4500]->80.187.82.203[14545] spi=0xbd73b8
14:13:00 ipsec -> ike2 request, exchange: INFORMATIONAL:634 13.95.9.128[4500] 6cbd8f62cb636534:95bd53d95feb7fe0
14:13:00 ipsec payload seen: ENC
14:13:00 ipsec processing payload: ENC
14:13:00 ipsec respond: info
14:13:00 ipsec <- ike2 reply, exchange: INFORMATIONAL:634 13.95.9.128[4500] 6cbd8f62cb636534:95bd53d95feb7fe0
4

Turns out it is working, same for l2tp ppp dial-in - but only right after a fresh boot.
After a few minutes all tunnel die.

5

In my situation after reboot nothing changed tunnels where established but no transfer between them.
Maybe my test was on 28 tunnels…But with 6.49 everything was OK. Only soft upgrade to 7.1 and everything fall down.

I have wrote to support@mikrotik.com but no response…

6

Hey guys from developers, can you answer in this topic please.

7

No. They already celebrate Christmas and annual bonuses.

8

Some “official” response would indeed be appreciated…

9

support@mikrotik also have already Christmas.
Sorry but waiting 2 weeks for the answer that they products doesn’t work (CCR with obligatory OS 7) is something that is not right.

10

For me the tunnel was working but I experience massive packet drops. WIreshark showed a lot of TCP DUPs and Retransmissions. After changing the underlay from IPSec to WireGuard it is smooth now. On top I have a GRE tunnel with OSPF. No DUPs and Retransmissions now.

11

I’ve tested 7.x version few days ago , there was a lot of problem with it, such as routing tunnels and so on.
Seriously I suggest all of you not to test 7.x version in production environments just use stable versions.

12

trolrolo,

Try to change 3des algorithm to aes-128 cbc

13

+1 Confirming this problem.
IPSEC tunnel and connections to remote computers via RDP works while on 6.49.1.
After upgrading to 7.1 IPSEC tunnel is established without errors, but I am unable to access remote resources. In IPSEC “Active peers” tab there are zero Rx Bytes/packets.

14

Tunnel works ok with 3des, Tunnel encryption should not have influence to routing. I have some old routers on the other side and I need to use 3des instead aes-128

15

( I have to stop playing with new “stable” releases on holidays! :slight_smile:)

Same story there. Tunnels work for 5-10 seconds after 7.1.1 router reboots and stop then. I’ve “fixed” that by setting Check Gateway = none in routes

16

Was there any resolution to that ? Still pretty much seeing the same problem :confused:

17

We had the same issue on RB1100AHx4 after upgrade from v6.49.2->v7.1.1.. IPSec VPN tunnel is estableshed fine but packets weren’t routed to the tunnel. RDC to a client host stopped working after the upgrade.

Had to downgrade to v6. Found several bugs while the downgrade. All of the found bugs were related with IP\Firewall\Mangle fields mapping.

18

More details. We use 2 WANs and so have several IP\Firewall\mangle settings. While the downgrade I faced with field mapping bugs. [New] Connection mark and [New] Routing mark fields were filled incorrectly. I even lost connection to the office network and had to ask collegues to help. I’m not ready to check on production router but I propose there is the same bug with field mapping while upgrading V6->V7. And that may be the reason why the routing fails.

19

Same problems here. http/https sessions are not working. icmp does go through the tunnel

I haven’t been able to get my hex-s working again. Rollback to 6.49 didn’t fix the issue, even after a clean wipe with netinstall.
It’s driving me crazy

20

IPsec on RB2011 with fw 7.1 works fine, this problem i have on CCR.