ipsec multisubnet or multi policy issue

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

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?

The logging is also showing “ipsec ike - couldn’t find configuration”

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

Kind regards

Andrew

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.
Sa Dst.

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:
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 [0] → [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

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

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] >

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.

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

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

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/t/v4-0-feature-request-s/18662/1 and pitch your support. For us it is the single biggest factor stopping us from using more Mikrotik kit.


Regards,



Andrew

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?

I am guessing this STILL isn’t fixed?

I just bought two NEW RB1000’s and this doesn’t work… :frowning:

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

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 :frowning:

Any known workarounds??

I was told they are “Looking” into the problem…

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.

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)

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 ? :slight_smile:

I use level=unique level for all my ipsec vpn’s form beginning, but this don’t fix problem! :frowning: 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??

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.

Good tip this, thanks.