ipsec multisubnet or multi policy issue

sfaizan · Sat Jul 12, 2008 2:33 pm

Ipsec is working fine b/w mkt and openswan by following the example given on mkt website. but i have one issue with multiple lan subnets at openswan side didnt work. only one whose packet goes first esablish tunnel work and other didnt work. heres wat i have done..

mkt side
-------
one WAN side on internet.
one peer connecting to openswan WAN side with 3des and md5
lan side pool 172.20.100.0/24 (src address)
2 same policies just a difference of destination address of openswan LAN
e.g one policy with dst address = 192.168.0.0/24 and other policy with dst address = 192.168.1.0/24 keeping the rest of the things same.

openswan side..
-------------
2 connection in ipsec conf keeping everything same except leftsubnet. one connection with 192.168.0.0/24 another connection with leftsubnet 192.168.1.0/24 keeping evrything same and ipsec securyt thr one shared key beczuse its connecting to the same global IP of mkt.

now here how its working...

when i ping from mkt lan that is 172.20.100.0/24 to any of the ip of Openswan LAN that is 192.168.1.0/24 or 192.168.0.0/24 it connects automatically and start pinging the other side sucessfully.

The Problem is, if in start I ping any ip of 192.168.0.0/24 from mkt lan 172.20.100.0/24 it connects using tunnel and encrption and start pinging 192.168.0.0/24 pool ips but not the 192.168.1.0/24 pool ips...

on the other hand if in start I ping any ip of 192.168.1.0/24 from mkt lan 172.20.100.0/24 it connects and start pinging but not the other subnet of openswan i.e 192.168.0.0/24 ..

it measn which packet goes first be4 connecting the tunnel is routed but it ignores the other policy ... one at a time. and if i try to ping other subnet it gives error of ISAK key error on console of mkt. but if WAN IPs are same and secret is same both subnet shud be routed using the same key thr no keys in policy and conn config of either opnswan or mkt,

wat must be the prb and if anyone can tell me how to setup multiple subnet using ipsec tunnel and one peer. do i need to stablish another peer which i am doubtfull and how to ..

Regards

Fiz

nathany · Thu Jul 17, 2008 2:12 pm

I'm experiencing exactly the same issue with 3.0.11 to a Cisco device. We need to tunnel multiple subnets to a single peer, which we have configured correctly. However, we can only ever communicate with one subnet at a time. I have received logs from the Cisco device and they confirm the RouterOS is not handling the multiple subnets.

Has anyone got a solution to have multiple subnets via IPSec to a single peer?

nathany · Fri Jul 18, 2008 3:18 pm

The logging is also showing "ipsec ike - couldn't find configuration"

andrewluck · Sat Jul 19, 2008 10:57 pm

You need to post some configs. Also the log that shows the errors.

Kind regards

Andrew

nathany · Sun Jul 20, 2008 1:47 pm

Hi Andrew,

The config is:

Policies:

Src: 10.25.0.0/16
Dst: 10.1.0.0/16

Action: enceypt
Level: require
IPSec Protocols: esp

Tunnel: Yes

Sa Src. <Our Public IP>
Sa Dst. <There Public IP>

Proposal: to_cisco
Manual SA: none

Pri: 0

We also have a second policy but for 10.25.0.0/15 to 192.1.1.0/24 - other parameters are as listed above.

Peers

Address: <There Public IP>
Port: 500
Auth: Pre-Share Key
Secret: <********>

Exchange Mode: main
Send initial Contact: Yes

Proposal Check: obey
Hash Alg: MD5
Enc Alg: 3des
DH Group: modp1024

Lifetime: 1d

Proposals

Name: to_cisco
Auth Alg: sha1
Enc Alg: 3des
Lifetime 01:00:00

With this configuration we do establish an IPSec tunnel and I can ping from 10.25.0.0/16 to hosts in 10.1.0.0/16. However, whilst I can ping hosts in 10.1.0.0/16 I cannot ping in 192.1.1.0/24 at the same time. This is not a firewall rule issue at this or the other end as if I disable the 10.25.0.0/16 to 10.1.0.0/16 policy I can then shortly after ping hosts in 192.1.1.0/24.

The logging shows the following:

ipsec-ike - IPSec-SA established: ESP/Tunnel <There IP>[0] -> <Our IP>[0] spi=XXXXXXX
ipsec-ike - couldn't find configuration
ipsec-ike - couldn't find configuration
ipsec-ike - couldn't find configuration

The couldn't find configuration error is listed circa every 20 seconds.

Thanks Again,
Nathan

andrewluck · Mon Jul 21, 2008 8:06 pm

Can't see anything out of order there. Turn on ipsec logging as well as ike, see if that reports anything.

If you're not seeing anything useful at the MT end then turn on debugging on the Cisco end and see if that offers any clues. You might post the Cisco crypto setup here as well.

Kind regards

Andrew

olydoc · Wed Jul 30, 2008 4:39 am

I have the same problem trying to run IPSEC tunnel between 2 MT Routers (RB450) using v3.11, but I don't have this problem with older routers (Soekris) using v2.9.43:

Router-1 (Delhur-PA)
------------------------------

[admin@Delhur-PA] /ip ipsec proposal> prin
0 name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m
pfs-group=modp1024

[admin@Delhur-PA] /ip ipsec peer> print
Flags: X - disabled
0 address=65.243.191.50/32:500 auth-method=pre-shared-key secret="anykey"
generate-policy=no exchange-mode=main send-initial-contact=yes
nat-traversal=yes proposal-check=obey hash-algorithm=md5
enc-algorithm=3des dh-group=modp1024 lifetime=1d lifebytes=0
dpd-interval=20s dpd-maximum-failures=1

[admin@Delhur-PA] /ip ipsec policy> print
Flags: X - disabled, D - dynamic, I - inactive
0 src-address=192.168.0.0/24:any dst-address=192.168.1.0/24:any protocol=all
action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=208.200.250.220 sa-dst-address=65.243.191.50
proposal=default manual-sa=none priority=0

Router-2 (Ang-Conc)
------------------------------

[admin@Ang-Conc] /ip ipsec proposal> print
Flags: X - disabled
0 name="default" auth-algorithms=sha1 enc-algorithms=3des lifetime=30m
pfs-group=modp1024

[admin@Ang-Conc] /ip ipsec peer> print
Flags: X - disabled
0 address=208.200.250.220/32:500 auth-method=pre-shared-key secret="anykey"
generate-policy=no exchange-mode=main send-initial-contact=yes
nat-traversal=yes proposal-check=obey hash-algorithm=md5
enc-algorithm=3des dh-group=modp1024 lifetime=1d lifebytes=0
dpd-interval=20s dpd-maximum-failures=1

[admin@Ang-Conc] /ip ipsec policy> print
Flags: X - disabled, D - dynamic, I - inactive
0 src-address=192.168.1.0/24:any dst-address=192.168.0.0/24:any protocol=all
action=encrypt level=require ipsec-protocols=esp tunnel=yes
sa-src-address=65.243.191.50 sa-dst-address=208.200.250.220
proposal=default manual-sa=none priority=0

First session......Ping from Router2 to Router1 OK, but not in reverse.....
------------------------------------------------------------------------------------------------------

[admin@Ang-Conc] > ping 192.168.0.254 src-address=192.168.1.254
packet rejected
packet rejected
packet rejected
packet rejected
192.168.0.254 64 byte ping: ttl=64 time=6 ms
192.168.0.254 64 byte ping: ttl=64 time=4 ms
6 packets transmitted, 2 packets received, 66% packet loss
round-trip min/avg/max = 4/5.0/6 ms

[admin@Delhur-PA] > ping 192.168.1.254 src-address=192.168.0.254
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
192.168.1.254 ping timeout
12 packets transmitted, 0 packets received, 100% packet losss

Flush the Installed-SA and stop service, then

First session......Ping from Router1 to Router2 OK, but not in reverse.....
------------------------------------------------------------------------------------------------------

[admin@Delhur-PA] > ping 192.168.1.254 src-address=192.168.0.254
packet rejected
packet rejected
packet rejected
packet rejected
192.168.1.254 64 byte ping: ttl=64 time=5 ms
192.168.1.254 64 byte ping: ttl=64 time=4 ms
6 packets transmitted, 2 packets received, 66% packet loss
round-trip min/avg/max = 4/4.5/5 ms
[admin@Delhur-PA] >

[admin@Ang-Conc] > ping 192.168.0.254 src-address-192.168.1.254
bad argument name src-address-192.168.1.254 (line 1 column 20)
[admin@Ang-Conc] > ping 192.168.0.254 src-address=192.168.1.254
192.168.0.254 ping timeout
192.168.0.254 ping timeout
3 packets transmitted, 0 packets received, 100% packet loss
[admin@Ang-Conc] >

nathany · Wed Jul 30, 2008 10:44 pm

Olydoc,

I logged a support ticket for this particular issue and it was confirmed as a bug and should hopefully be resolved in the next update - so hopefully 3.12 will be out soon!

Regards,
Nathan.

olydoc · Thu Jul 31, 2008 11:00 pm

Thanks Nathan...I rcvd an acknowledgement from Sergejs that he had been able to duplicate the problem so we will look for the fix hopefully w/ next update.

Regards,

Doc

zodiac · Tue Aug 12, 2008 1:17 am

Hello,

I have the same problem. Previously I used version 2.9 and it worked OK. After upgrade, only first SA is established and no other policy for following subnet is taken. I tried to debug it on Cisco ISR 3825, but it looks at 100% that error is on mikrotik side. Can you do something with this please ? Old routerboards have small cpu power for ipsec and new RB's are not working with old 2.9 versions. I have feeling, that every version bring some new stuff, but lots of old working stuff gets ruined...... And I havent this feeling alone...

Best Regards,

Pavel

Tue Aug 12, 2008 11:50 am

Hi Guys,

I have been lightly pushing Mikrotik for a while to improve the ipsec implementation in RouterOS to include more standard naming, as well as the ability to have IPSEC tunnel interfaces. This is pretty much standard functionality now days and routers/firewalls from Juniper, Cisco, Fortinet even some Linksys routers support it!

If you also want to see IPSEC in RouterOS improved, read the posts at http://forum.mikrotik.com/viewtopic.php?f=1&t=21357 and pitch your support. For us it is the single biggest factor stopping us from using more Mikrotik kit.

Regards,

Andrew

mrstroob · Sun Mar 22, 2009 5:38 am

I'm gettting:

23:31:09 ipsec couldn't find configuration.

on ROS 3.22 (RB500) when trying to set up L2TP w/ IPSec

Has there been a fix/workaround discovered? Known issue?

wkstill · Wed Mar 25, 2009 8:53 pm

I am guessing this STILL isn't fixed?

I just bought two NEW RB1000's and this doesn't work...

I need to setup multiply polices using the same peer, and only one of the polices works..

msundman · Tue Apr 21, 2009 2:08 pm

Damn, I just ran into the exact same issue,

trying to establish two policies to the same peer (a Cisco), but only the first one that is established works.

My config is like:

/ip ipsec peer
add address=xx.xx.xx.196/32:500 auth-method=pre-shared-key dh-group=modp1024 \
    disabled=no dpd-interval=disable-dpd dpd-maximum-failures=1 enc-algorithm=\
    3des exchange-mode=main generate-policy=no hash-algorithm=sha1 lifebytes=0 \
    lifetime=1d nat-traversal=no proposal-check=obey secret=am5dbLKF43392vmD \
    send-initial-contact=yes
/ip ipsec policy
add action=encrypt disabled=no dst-address=10.4.y.y/32:any ipsec-protocols=esp \
    level=require priority=0 proposal=default protocol=all sa-dst-address=\
    xx.xx.xx.196 sa-src-address=xx.xx.xx.33 src-address=10.105.0.0/16:any \
    tunnel=yes
add action=encrypt disabled=no dst-address=10.1.z.z/32:any ipsec-protocols=esp \
    level=require priority=0 proposal=default protocol=all sa-dst-address=\
    xx.xx.xx.196 sa-src-address=xx.xx.xx.33 src-address=10.105.0.0/16:any \
    tunnel=yes

Running on RB1000 and just tried to upgrade to 3.23, but still no luck

Any known workarounds??

wkstill · Wed Apr 22, 2009 6:11 pm

I was told they are "Looking" into the problem...

msundman · Mon Apr 27, 2009 4:32 pm

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.

wkstill · Thu Apr 30, 2009 6:15 pm

i also worked around the problem as well (used a L2TP tunnel over IPSEC, and then I also setup RIP between the two RB's, working pretty good for now)

arnisg · Tue Nov 03, 2009 12:25 pm

Hi,

I run into same problem running 3.27, but till 3.30 I can't see any fixes regarding this problem in changelog. Is there still Sergejs working on this problem ?

I use level=unique level for all my ipsec vpn's form beginning, but this don't fix problem!

As I heard - it's not good idea to try 4.2 jet (heard that it's still quite unstable for handling configuration changes). but maybe there it's fixed??

deimos · Thu Feb 04, 2010 1:23 am

Hi,

Running version 4.5, this problem appears to be resolved. Make sure you set level of the IPsec Policy to 'unique' for each subnet.

This was tested against a Cisco ASA.

hilton · Thu Feb 04, 2010 9:00 am

Make sure you set level of the IPsec Policy to 'unique' for each subnet.

Good tip this, thanks.

kuz8 · Sun Mar 02, 2014 10:18 am

Had the same issue on 6.10, IPSec between new MikroTik CCR1036 and Zyxel ZyWALL USG200 (to be replaced with CCR) when connection was initiating from MikroTik.. Thanks for the tip, setting IPSec Policy level to "unique" solved the issue.

When connection was initiated from ZyWALL though it worked well without "unique" but I wanted mkt to be able to handle it by itself as I'm retiring Zyxel.

I only wonder why Unique is not the default. It took me two+ days to model it to the right set of symptoms to be able to formulate the search criteria to find this post..

cmurrayis · Fri May 23, 2014 3:29 am

Guys,

I am also having this problem however When the session is established the logs show the polices don't match and it is creating new policies on the fly with the setting of required. I've made a policy for each tunnel which patch perfectly with what is being created by the tunnel when initiated from the cisco end however the are still giving the same result.

When we ping one tunnel it works and then ping the second tunnel it works but when we come back to the first tunnel it will no longer work.

montdidier · Thu Feb 26, 2015 7:41 am

I also seem to be having this issue. Cannot get more than one tunnel to work. Have set all three policies to level=unique.

UPDATE: Actually it turns out my problem is more like the problem described below:

http://forum.mikrotik.com/viewtopic.php?f=13&t=92568

I can establish a tunnel for the other subnets, but only if initiated from the Cisco ASA.

radekmacek · Fri Oct 02, 2015 10:22 am

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.

Our setting is Mikrotik to cisco ASA and it works like a charm

Thank you very much

eon · Thu May 12, 2016 11:25 am

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.

Thank you, IPsec policy <> action <> level - unique - worked !

Teive · Tue Aug 08, 2017 5:00 pm

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.
Thank you, IPsec policy <> action <> level - unique - worked !

Solved my problem. Thank you!

catalin · Tue Jul 10, 2018 3:53 pm

have the same issue, switch level to unique fix the problem on MT to Cisco ASA 55xx

JorisFRST · Thu Oct 11, 2018 11:42 am

Thanks,

unique worked for me too. Was troubleshooting a connection between us and a 3rd party using Cisco.

Great forum.

resolve · Wed Nov 28, 2018 2:15 am

Hi everyone,

Sorry for digging this out, but I am experiencing a similar issue between CRS-125-24G-1S RouterOS 6.43.4 while trying to establish an IKEv2 connection to Checkpoint Security R5. Everything is working fine when only one policy is in use. I have to, however, be able to reach two different /32 addresses and it is no possible to group them into a bigger subnet (the remote peer does not accept that). So I had to create two policies, which are identical with the exception of destination address of course.

Reading through the forums I found information that the Policy level should be set to "unique", so I have set policy level to unique for both, but this does not help. Here's a piece of the log file:

nov/27 23:51:44 ipsec,info peer authorized: E.F.G.H[4500]-A.B.C.D[4500] spi:1bc312ed89fda99a:d562bda431f21819 
nov/27 23:51:44 ipsec peer selected tunnel mode 
nov/27 23:51:44 ipsec processing payload: TS_I 
nov/27 23:51:44 ipsec 172.30.0.0/24 
nov/27 23:51:44 ipsec processing payload: TS_R 
nov/27 23:51:44 ipsec 10.170.10.132 
nov/27 23:51:44 ipsec my vs peer's selectors: 
nov/27 23:51:44 ipsec 172.30.0.0/24 vs 172.30.0.0/24 
nov/27 23:51:44 ipsec 10.170.10.132 vs 10.170.10.132 
nov/27 23:51:44 ipsec processing payload: SA 
nov/27 23:51:44 ipsec IKE Protocol: ESP 
nov/27 23:51:44 ipsec  proposal #1 
nov/27 23:51:44 ipsec   enc: aes256-cbc 
nov/27 23:51:44 ipsec   auth: sha256 
nov/27 23:51:44 ipsec matched proposal: 
nov/27 23:51:44 ipsec  proposal #1 
nov/27 23:51:44 ipsec   enc: aes256-cbc 
nov/27 23:51:44 ipsec   auth: sha256 
nov/27 23:51:44 ipsec,debug => child keymat (size 0x80) 
nov/27 23:51:44 ipsec,debug f2ccbd97 0e2d870e 5ef15722 49f3fd57 ca01d7d7 0fcabb8a 59a17b84 545c57a9 
nov/27 23:51:44 ipsec,debug aa2d81c8 579b8bc2 3c16445b 070c2732 24d5fb5e 4c7b4aba c1100972 bc5f7501 
nov/27 23:51:44 ipsec,debug 7561740b 787054e8 a5212cdf 31cf6064 3143e3b2 7a9d37bc 60327d91 d0a94816 
nov/27 23:51:44 ipsec,debug c4d3cec8 1cc623ed 7a97866d 7ab1ba40 41b9131d baa1786b 96d668ad 4a5bca34 
nov/27 23:51:44 ipsec IPsec-SA established: A.B.C.D[4500]->E.F.G.H[4500] spi=0xba06cbe 
nov/27 23:51:44 ipsec IPsec-SA established: E.F.G.H[4500]->A.B.C.D[4500] spi=0x63e3db6b 
nov/27 23:51:44 ipsec ph2 possible after ph1 creation 
nov/27 23:51:44 ipsec init child for policy: 172.30.0.0/24 <=> 10.200.10.0/24 
nov/27 23:51:44 ipsec init child continue 
nov/27 23:51:44 ipsec offering proto: 3 
nov/27 23:51:44 ipsec  proposal #1 
nov/27 23:51:44 ipsec   enc: aes256-cbc 
nov/27 23:51:44 ipsec   auth: sha256 
nov/27 23:51:44 ipsec   dh: modp1024 
nov/27 23:51:45 ipsec adding payload: NONCE 
nov/27 23:51:45 ipsec,debug => (size 0x1c) 
nov/27 23:51:45 ipsec,debug 0000001c 408217c2 b204719a 33259bb9 0b036a29 b489d8bb ae091336 
nov/27 23:51:45 ipsec adding payload: KE 
nov/27 23:51:45 ipsec,debug => (size 0x88) 
nov/27 23:51:45 ipsec,debug 00000088 00020000 d0feef98 dbbba3f1 27a16b65 385103e9 4beb7e74 df2e5e79 
nov/27 23:51:45 ipsec,debug ede76133 83e81fb2 0a380b11 4aa4dcd8 624728ca c6e9d139 d7b7a2d5 2d403c4a 
nov/27 23:51:45 ipsec,debug 64c53895 3b67a395 c389d422 1147cc8c 22fe0624 052ad541 465aece3 51099e7d 
nov/27 23:51:45 ipsec,debug 214df2bf 69e58cfd deebc7f3 cf0f3d5a 08c94928 da7c2351 3182e00d 2b7a2f3f 
nov/27 23:51:45 ipsec,debug 5ee7cd58 04701070 
nov/27 23:51:45 ipsec adding payload: SA 
nov/27 23:51:45 ipsec,debug => (size 0x34) 
nov/27 23:51:45 ipsec,debug 00000034 00000030 01030404 054cff37 0300000c 0100000c 800e0100 03000008 
nov/27 23:51:45 ipsec,debug 0300000c 03000008 04000002 00000008 05000000 
nov/27 23:51:45 ipsec initiator selector: 172.30.0.0/24 
nov/27 23:51:45 ipsec adding payload: TS_I 
nov/27 23:51:45 ipsec,debug => (size 0x18) 
nov/27 23:51:45 ipsec,debug 00000018 01000000 07000010 0000ffff ac1e0000 ac1e00ff 
nov/27 23:51:45 ipsec responder selector: 10.200.10.0/24 
nov/27 23:51:45 ipsec adding payload: TS_R 
nov/27 23:51:45 ipsec,debug => (size 0x18) 
nov/27 23:51:45 ipsec,debug 00000018 01000000 07000010 0000ffff 0ac80a00 0ac80aff 
nov/27 23:51:45 ipsec <- ike2 request, exchange: CREATE_CHILD_SA:2 A.B.C.D[4500] 
nov/27 23:51:45 ipsec,debug,packet => outgoing plain packet (size 0x124) 
nov/27 23:51:45 ipsec,debug,packet 1bc312ed 89fda99a d562bda4 31f21819 28202408 00000002 00000124 2200001c 
nov/27 23:51:45 ipsec,debug,packet 408217c2 b204719a 33259bb9 0b036a29 b489d8bb ae091336 21000088 00020000 
nov/27 23:51:45 ipsec,debug,packet d0feef98 dbbba3f1 27a16b65 385103e9 4beb7e74 df2e5e79 ede76133 83e81fb2 
nov/27 23:51:45 ipsec,debug,packet 0a380b11 4aa4dcd8 624728ca c6e9d139 d7b7a2d5 2d403c4a 64c53895 3b67a395 
nov/27 23:51:45 ipsec,debug,packet c389d422 1147cc8c 22fe0624 052ad541 465aece3 51099e7d 214df2bf 69e58cfd 
nov/27 23:51:45 ipsec,debug,packet deebc7f3 cf0f3d5a 08c94928 da7c2351 3182e00d 2b7a2f3f 5ee7cd58 04701070 
nov/27 23:51:45 ipsec,debug,packet 2c000034 00000030 01030404 054cff37 0300000c 0100000c 800e0100 03000008 
nov/27 23:51:45 ipsec,debug,packet 0300000c 03000008 04000002 00000008 05000000 2d000018 01000000 07000010 
nov/27 23:51:45 ipsec,debug,packet 
nov/27 23:51:45 ipsec,debug,packet 0000ffff ac1e0000 ac1e00ff 00000018 01000000 07000010 0000ffff 0ac80a00 
nov/27 23:51:45 ipsec,debug,packet 0ac80aff 
nov/27 23:51:45 ipsec adding payload: ENC 
nov/27 23:51:45 ipsec,debug => (first 0x100 of 0x1c4) 
nov/27 23:51:45 ipsec,debug 280001c4 e7cbe847 d6e8d0a2 f6b17beb 17970d03 d30dd8f0 31b058ea 3ad19ec5 
nov/27 23:51:45 ipsec,debug bd356961 fb10cfe2 a1725a2b 018eb0e4 adedcfa7 046fd9e9 799c442e 2401dde3 
nov/27 23:51:45 ipsec,debug e7ef3f00 c69dc6db 721aaf96 28228a92 2ebed541 756e7a8a c546128b 380e9e48 
nov/27 23:51:45 ipsec,debug e937f7ef dca19c6a 652ff8fc a0d76f2a 8b62cf06 b7b45513 77afa2d1 023171f5 
nov/27 23:51:45 ipsec,debug b6bd795a fc9c7692 468bb1ed 05941e09 ddca66f4 2943c60d 1b9a4fcc a659147f 
nov/27 23:51:45 ipsec,debug fc7f8ef4 94d7a9a3 3fbbb2c0 7b46f5b8 fa9b2b1b 514e6321 93cdaa3a 76165a34 
nov/27 23:51:45 ipsec,debug 659023d5 85515a36 2d903268 23eb6987 e32c8640 4d7e13f2 07807fba 7f4d7932 
nov/27 23:51:45 ipsec,debug f81e3c41 13f8df34 662fd429 7d1ee4c8 31936d3e ac4fdf42 57329609 f5433f19 
nov/27 23:51:45 ipsec,debug ===== sending 480 bytes from E.F.G.H[4500] to A.B.C.D[4500] 
nov/27 23:51:45 ipsec,debug 1 times of 484 bytes message will be sent to A.B.C.D[4500] 
nov/27 23:51:45 ipsec,debug,packet 1bc312ed 89fda99a d562bda4 31f21819 2e202408 00000002 000001e0 280001c4 
nov/27 23:51:45 ipsec,debug,packet e7cbe847 d6e8d0a2 f6b17beb 17970d03 d30dd8f0 31b058ea 3ad19ec5 bd356961 
nov/27 23:51:45 ipsec,debug,packet fb10cfe2 a1725a2b 018eb0e4 adedcfa7 046fd9e9 799c442e 2401dde3 e7ef3f00 
nov/27 23:51:45 ipsec,debug,packet c69dc6db 721aaf96 28228a92 2ebed541 756e7a8a c546128b 380e9e48 e937f7ef 
nov/27 23:51:45 ipsec,debug,packet dca19c6a 652ff8fc a0d76f2a 8b62cf06 b7b45513 77afa2d1 023171f5 b6bd795a 
nov/27 23:51:45 ipsec,debug,packet fc9c7692 468bb1ed 05941e09 ddca66f4 2943c60d 1b9a4fcc a659147f fc7f8ef4 
nov/27 23:51:45 ipsec,debug,packet 94d7a9a3 3fbbb2c0 7b46f5b8 fa9b2b1b 514e6321 93cdaa3a 76165a34 659023d5 
nov/27 23:51:45 ipsec,debug,packet 85515a36 2d903268 23eb6987 e32c8640 4d7e13f2 07807fba 7f4d7932 f81e3c41 
nov/27 23:51:45 ipsec,debug,packet 13f8df34 662fd429 7d1ee4c8 31936d3e ac4fdf42 57329609 f5433f19 4a978db3 
nov/27 23:51:45 ipsec,debug,packet fc6710fe a0fc95a4 a7405cc4 75736d7d 95b3b6c5 e84e04a3 3881f18d fa5ed97e 
nov/27 23:51:45 ipsec,debug,packet 6d28b4fc 98a7afed 5c5b7566 ebfcfc3f 24455881 18d40390 b49fa38a 25a797e1 
nov/27 23:51:45 ipsec,debug,packet c73abf59 47bcdd44 49c466ef 421129af c30fc824 3375b18c 907147c8 0494f2dd 
nov/27 23:51:45 ipsec,debug,packet 2caae82b cc466d45 c92dbc79 a5564ee3 c5e173db d890ee76 9578222e 6160d5fd 
nov/27 23:51:45 ipsec,debug,packet 4eaeedc9 2d68af92 c2c12ac0 b0d80e9c 0ba8b271 c5e4e26f f6c68b37 f1acae3d 
nov/27 23:51:45 ipsec,debug,packet 1f24395f abdfe72b d65b938e 6d97cf28 43e5499b 146633d3 1cfab3fb e183a684 
nov/27 23:51:47 ipsec,debug ===== received 80 bytes from A.B.C.D[4500] to E.F.G.H[4500] 
nov/27 23:51:47 ipsec,debug,packet 0dcf65c8 145a7f37 8e743716 1789a208 2e202500 00000000 00000050 2a000034 
nov/27 23:51:47 ipsec,debug,packet 40305720 6651f6d8 4aff3945 b0448982 d1711db1 6d1e6d89 3d028f1c 2d321ef7 
nov/27 23:51:47 ipsec,debug,packet 8c553460 69b38358 84c426a4 42ca6878 
nov/27 23:51:47 ipsec -> ike2 request, exchange: INFORMATIONAL:0 A.B.C.D[4500] 
nov/27 23:51:47 ipsec SPI dcf65c8145a7f37 not registred for A.B.C.D[4500] 
nov/27 23:51:48 ipsec,info killing ike2 SA: E.F.G.H[4500]-A.B.C.D[4500] spi:1bc312ed89fda99a:d562bda431f21819 
nov/27 23:51:48 ipsec IPsec-SA killing: A.B.C.D[4500]->E.F.G.H[4500] spi=0xba06cbe 
nov/27 23:51:48 ipsec IPsec-SA killing: E.F.G.H[4500]->A.B.C.D[4500] spi=0x63e3db6b 
nov/27 23:51:48 ipsec adding payload: DELETE 
nov/27 23:51:48 ipsec,debug => (size 0x8) 
nov/27 23:51:48 ipsec,debug 00000008 01000000 
nov/27 23:51:48 ipsec <- ike2 request, exchange: INFORMATIONAL:3 A.B.C.D[4500] 
nov/27 23:51:48 ipsec,debug,packet => outgoing plain packet (size 0x24) 
nov/27 23:51:48 ipsec,debug,packet 1bc312ed 89fda99a d562bda4 31f21819 2a202508 00000003 00000024 00000008 
nov/27 23:51:48 ipsec,debug,packet 01000000 
nov/27 23:51:48 ipsec adding payload: ENC 
nov/27 23:51:48 ipsec,debug => (size 0xf4) 
nov/27 23:51:48 ipsec,debug 2a0000f4 e7cbe847 d6e8d0a2 f6b17beb 17970d03 331e0f58 b25a2665 e11cc892 
nov/27 23:51:48 ipsec,debug e8c0f2a6 bf9d7e56 0bdc4185 7794cf2f 916ab4c2 ee883c9a fd479ef3 5c9db7b7 
nov/27 23:51:48 ipsec,debug 633858f7 16d8d902 87959b3a 884a74e8 4927af48 630f7cd7 592b4845 b5df20c6 
nov/27 23:51:48 ipsec,debug 5d9c2f89 048afea9 0b8e8e52 2c9134f1 ca86f6f9 2e819149 5d70f931 ea3b9378 
nov/27 23:51:48 ipsec,debug 02f0bfbd 5bf10c68 32ca380e fe397fb7 c8a84484 d9e60606 e87a526c 2b58289b 
nov/27 23:51:48 ipsec,debug f7e7b80a dd377293 6a468a7f f4a70471 4750e547 b7071749 9ea97c24 05b73447 
nov/27 23:51:48 ipsec,debug 11b61fed b08633d7 71be089f 243f9db9 7d091ec5 9aeb9bbc 0e6dd103 37116715 
nov/27 23:51:48 ipsec,debug 3cafcce3 00000000 00000000 0000ffff 0aaa0a84 
nov/27 23:51:48 ipsec,debug ===== sending 272 bytes from E.F.G.H[4500] to A.B.C.D[4500] 
nov/27 23:51:48 ipsec,debug 1 times of 276 bytes message will be sent to A.B.C.D[4500] 
nov/27 23:51:48 ipsec,debug,packet 1bc312ed 89fda99a d562bda4 31f21819 2e202508 00000003 00000110 2a0000f4 
nov/27 23:51:48 ipsec,debug,packet e7cbe847 d6e8d0a2 f6b17beb 17970d03 331e0f58 b25a2665 e11cc892 e8c0f2a6 
nov/27 23:51:48 ipsec,debug,packet bf9d7e56 0bdc4185 7794cf2f 916ab4c2 ee883c9a fd479ef3 5c9db7b7 633858f7 
nov/27 23:51:48 ipsec,debug,packet 16d8d902 87959b3a 884a74e8 4927af48 630f7cd7 592b4845 b5df20c6 5d9c2f89 
nov/27 23:51:48 ipsec,debug,packet 048afea9 0b8e8e52 2c9134f1 ca86f6f9 2e819149 5d70f931 ea3b9378 02f0bfbd 
nov/27 23:51:48 ipsec,debug,packet 5bf10c68 32ca380e fe397fb7 c8a84484 d9e60606 e87a526c 2b58289b f7e7b80a 
nov/27 23:51:48 ipsec,debug,packet dd377293 6a468a7f f4a70471 4750e547 b7071749 9ea97c24 05b73447 11b61fed 
nov/27 23:51:48 ipsec,debug,packet b08633d7 71be089f 243f9db9 7d091ec5 9aeb9bbc 0e6dd103 37116715 3cafcce3 
nov/27 23:51:48 ipsec,debug,packet c7946304 f3f0d670 6085722e 58ca3944 
nov/27 23:51:48 ipsec KA remove: E.F.G.H[4500]->A.B.C.D[4500] 
nov/27 23:51:48 ipsec,debug KA tree dump: E.F.G.H[4500]->A.B.C.D[4500] (in_use=1) 
nov/27 23:51:48 ipsec,debug KA removing this one... 
nov/27 23:51:58 ipsec,debug ===== received 80 bytes from A.B.C.D[4500] to E.F.G.H[4500] 
nov/27 23:51:58 ipsec,debug,packet 0dcf65c8 145a7f37 8e743716 1789a208 2e202500 00000000 00000050 2a000034 
nov/27 23:51:58 ipsec,debug,packet 40305720 6651f6d8 4aff3945 b0448982 d1711db1 6d1e6d89 3d028f1c 2d321ef7 
nov/27 23:51:58 ipsec,debug,packet 8c553460 69b38358 84c426a4 42ca6878 
nov/27 23:51:58 ipsec -> ike2 request, exchange: INFORMATIONAL:0 A.B.C.D[4500] 
nov/27 23:51:58 ipsec SPI dcf65c8145a7f37 not registred for A.B.C.D[4500] 
nov/27 23:52:14 ipsec,debug ===== received 80 bytes from A.B.C.D[4500] to E.F.G.H[4500] 
nov/27 23:52:14 ipsec,debug,packet 0dcf65c8 145a7f37 8e743716 1789a208 2e202500 00000000 00000050 2a000034 
nov/27 23:52:14 ipsec,debug,packet 40305720 6651f6d8 4aff3945 b0448982 d1711db1 6d1e6d89 3d028f1c 2d321ef7 
nov/27 23:52:14 ipsec,debug,packet 8c553460 69b38358 84c426a4 42ca6878 
nov/27 23:52:14 ipsec -> ike2 request, exchange: INFORMATIONAL:0 A.B.C.D[4500] 
nov/27 23:52:14 ipsec SPI dcf65c8145a7f37 not registred for A.B.C.D[4500] 
nov/27 23:52:37 ipsec,debug ===== received 80 bytes from A.B.C.D[4500] to E.F.G.H[4500] 
nov/27 23:52:37 ipsec,debug,packet 0dcf65c8 145a7f37 8e743716 1789a208 2e202500 00000000 00000050 2a000034 
nov/27 23:52:37 ipsec,debug,packet 40305720 6651f6d8 4aff3945 b0448982 d1711db1 6d1e6d89 3d028f1c 2d321ef7 
nov/27 23:52:37 ipsec,debug,packet 8c553460 69b38358 84c426a4 42ca6878 
nov/27 23:52:37 ipsec -> ike2 request, exchange: INFORMATIONAL:0 A.B.C.D[4500] 
nov/27 23:52:37 ipsec SPI dcf65c8145a7f37 not registred for A.B.C.D[4500] 
nov/27 23:53:09 ipsec,debug ===== received 80 bytes from A.B.C.D[4500] to E.F.G.H[4500] 
nov/27 23:53:09 ipsec,debug,packet 0dcf65c8 145a7f37 8e743716 1789a208 2e202500 00000000 00000050 2a000034 
nov/27 23:53:09 ipsec,debug,packet 40305720 6651f6d8 4aff3945 b0448982 d1711db1 6d1e6d89 3d028f1c 2d321ef7 
nov/27 23:53:09 ipsec,debug,packet 8c553460 69b38358 84c426a4 42ca6878 
nov/27 23:53:09 ipsec -> ike2 request, exchange: INFORMATIONAL:0 A.B.C.D[4500] 
nov/27 23:53:09 ipsec SPI dcf65c8145a7f37 not registred for A.B.C.D[4500]

I would greatly appreciate any suggestions. It seems like ike2 request, exchange: CREATE_CHILD_SA:2 A.B.C.D[4500] does not work properly with the other end. On Checkpoint the log say:

Child SA exchange: Peer's message is unacceptable
Child SA exchange: Sending notification to peer: Invalid Syntax

jm1973 · Wed May 15, 2019 6:46 pm

Hi. I am having a similar issue where I have a IPSEC/GRE tunnel to a Cisco router which works for a while, but the connection occasionally drops and will not reform for 10 minutes, unless you fush the SAs, then it comes back up straight away.

I set the policy level to 'unique' and the drops stopped happening.

However, I have now added a further two IPSEC/GRE tunnels to other cisco routers, and the problem has come back. I have set all of them to level 'unique' but this hasn't stopped the drops.

Does anyone have another workaround?

I am using 6.37.5.

sindy · Wed May 15, 2019 9:01 pm

I'm afraid so many changes in IPsec have been made since 6.37.5 to 6.44.3 that there is no one who'd be able to remember all what may be wrong in 6.37.5. You'll have to move forward, and most likely in several steps so that the configuration could be converted more or less smoothly. But if I was to do that, I would probably export the existing configuration into a script file, netinstall the machine or at least set its configuration to default before upgrading, and manually import the exported configuration after the upgrade, modifying what needs to be modified manually. The risks of upgrading across so many releases are so high that I'd be scared to do that remotely.

Jeanne · Mon Jun 17, 2019 10:51 am

This worked well for me. Thank you! You saved me.

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.

kbehrens · Fri Sep 13, 2019 11:37 pm

The exact same thing happened to be when trying to connect multiple subnets via IPSEC between a MikroTik CCR running 6.45.3 and a Securepoint UTM 11.7. Setting the level to "unique" helped immediately.

Thanks!

hatman · Tue Jan 26, 2021 5:30 pm

The unique setting does not fix my issue...

I am only able to setup 2 policy per peer. I can't see anything about that limitation online. As soon as I enable the 3rd policy one of the other 2 stop working and goes to "no phase2"
router info: ccr2004 v6.46.8
all the policy's also have unique src and dst subnets.

if anyone could think of some tips to look at I would appreciate the help.

gwathedhel · Thu Sep 16, 2021 1:45 pm

I have the same problem =((( no phase 2 on second policy... "unique" level doesn't help. Mikrotik hEX S on one side and Cisco FTD 2120 on the other.

gwathedhel · Tue Sep 21, 2021 5:29 pm

I have the same problem =((( no phase 2 on second policy... "unique" level doesn't help. Mikrotik hEX S on one side and Cisco FTD 2120 on the other.

Oh, I have got the solution! After multiple days of experiments with Cisco FTD I got that you need to check box "Enable Perfect Forward Secrecy" to correctly work with multiple policies on Mikrotik side.

chatravin · Fri Nov 19, 2021 3:17 pm

It seems everybody's problem been solved by setting "level" parameter to "require". But what does it really mean and on what occasion each and other options should be used?
I read the description provided by mikrotik help and that was not helpful at all; like many other concepts that need to be clarified by other guys on this forum. So I would be thankful to someone here if he could add more clarity or provide with a good source on this topic, thanks in advance.

sindy · Fri Nov 19, 2021 5:35 pm

Leaving aside use, the difference between unique and required is that with unique, each policy creates its own pair of security associations with own IDs and keys; with required, multiple policies use a common security association to send the encrypted data. Both peers must use the same approach, because if a packet comes via another security association than expected, the recipient drops it.

chatravin · Fri Nov 19, 2021 6:34 pm

Hi @sindy, the explanation was both concise and clarifying but I have a major problem with this: where exactly this information come from? I am a network man working with popular network devices like cisco, Huawei, etc., but have not been able to find the basic knowledge needed to understand mikrotik solutions from within mikrotik sources. It seems mikrotik looks at network from a linux-point-of-veiw, am I right? If that is the case how can I make myself familiar with building concepts of Linux networking? Is there any comprehensive book or other sources to rely on (as it seem you're really knowledgeable ad handy to solve problems here) ?
Sorry if here is not a good place to bring up this subject (I had no access to your contact).

sindy · Fri Nov 19, 2021 7:58 pm

where exactly this information come from?

The documentation, this forum, 5 years of hands-on experience with RouterOS, and 15+ with Linux.

It seems mikrotik looks at network from a linux-point-of-veiw, am I right?

RouterOS is Linux, with quite a lot of in-house development, and a systematized configuration structure instead of a mess of individual configuration files with different syntax like regular Linux distributions. And with Winbox/WebFig of course, for those who are scared of command line.

Is there any comprehensive book or other sources to rely on (as it seem you're really knowledgeable ad handy to solve problems here)?

Probably many of them, however whenever I read this type of literature from the beginning to the end, I miss a lot of information because it cannot soak in all at once. Solving practical tasks and looking up the related information as I do it works much better for me. So I cannot recommend anything.

Sorry if here is not a good place to bring up this subject (I had no access to your contact).

PMs were working briefly here but they have been disabled again, so there is no other way but piggy-backing on resolved topics.

chatravin · Fri Nov 19, 2021 10:12 pm

Thanks for your help anyway, though I was really eager to see one or more refrence at least relating to the topic of this thread (ie. ipsec) in linux.

sindy · Fri Nov 19, 2021 10:15 pm

Well... IPsec is one of the cases where the RouterOS implementation is quite far from the popular Linux ones, both Openswan and Strongswan.

shema · Fri Jan 26, 2024 12:50 pm

I just got a reply from the support about this where they told me that Cisco probably defaults to creating seperate SAs per subnet (which I thought was mandatory according to the IPsec standard), while Mikrotik defaults to sharing the same SA for multiple policies.

So connecting two MTs works out-of-the-box with multiple subnets. It's connecting a Mikrotik to for instance a Cisco that gives problems.

There are however a configuration option on the MTs that should change this behaviour. Could someone try setting level=unique instead of level=require on the ipsec policies in the MT, and confirm if this solves the problem?

Unfortunally I've already worked around the problem by summarizing the two /32 subnets into a /13 network, so I could reach them both with only one policy, and don't wanna mess with this anymore now as it's already in production.

This is solution worked for me!!! Thank you very much