Good Morning all.Please i really need help to fix this issue.
Router OS Ver 6.35.4,
I have A site-to-site VPN with a third party that uses Cisco ASR1000 Router.
Goal is to allow my "TEST Server & Live Server Which are behind NAT To Access Their "TEST & Live Servers. However Both Of Their servers are on a different subnet 22.22.x.x & 33.33.x.x
I have Configured the Ipsec Policies on my own side and my "Live Sever" Can successfully access Their "Live Server" Which is on 22.22.x.x but connection between my "Test Server & their "Test Server" continues to fail....
I have been following the forum and many suggestions, eg is Mrz. On the Ipsec Policy Page,I have changed the Level from "require" to "unique" but my server cant still access my partner's server that is on a different subnet.
Please your kind help will be appreciated.

The 22.22.x.x and 33.33.x.x are public addresses or private, and are they addresses of a NAT device behind which their ASRs are connected or are these addresses up directly on the ASRs?

these are public ip addresse. the servers are translated via by the cisco asr 1000 using those public addresses 22.22.x.x & 33.33.x.x

there is a static nat (one-to-one Nat) configured for both Servers at either end.

Okay. So the overall topology for both the "live" and "test" setups is the same:

Mikrotik at private address - some NATwith 1:1 mapping - internet - another NAT with 1:1 mapping - remote server at private address.

Can you set if not done yet, let the connection attempt start and fail, and then post the output of , , , and after systematically replacing each occurrence of a public address with a distinctive pattern like , ?

/ip ipsec export

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=aes-192-cbc,aes-128-cbc
add enc-algorithms=aes-256-cbc name=LNBS pfs-group=none
add enc-algorithms=aes-256-cbc name=proposal1 pfs-group=none
/ip ipsec peer
add address=19.x.x.25/32 comment="IKE PHASE 1 FOR ME and Partner" dh-group=modp1536 enc-algorithm=aes-256 \
lifetime=8h secret=password
/ip ipsec policy
add comment="IKE PHASE 2" dst-address=19.x.x.233/32 level=unique proposal=IBS \
sa-dst-address=19.x.x.25 sa-src-address=97.x.x.2 src-address=97.x.x.14/32 tunnel=yes
add comment="IKE PHASE 2" dst-address=41.x.x.134/32 level=unique proposal=IBS \
sa-dst-address=19.x.x.25 sa-src-address=97.x.x.2 src-address=97.x.x.14/32 tunnel=yes

/ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder
0 R ;;; Remote Access-VPN
address=0.0.0.0/0 passive=yes auth-method=pre-shared-key
secret="P@55W0rd" generate-policy=port-override
policy-template-group=default exchange-mode=main-l2tp
send-initial-contact=yes nat-traversal=yes proposal-check=obey
hash-algorithm=sha1 enc-algorithm=aes-128,3des dh-group=modp1024
lifetime=1d dpd-interval=2m dpd-maximum-failures=5

1 ;;; IKE PHASE 1 FOR LNBS
address=19.x.x.25/32 auth-method=pre-shared-key
secret=password generate-policy=no
policy-template-group=default exchange-mode=main
send-initial-contact=yes nat-traversal=yes proposal-check=obey
hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1536
lifetime=8h dpd-interval=2m dpd-maximum-failures=5

/ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active,
* - default
0 A ;;; esan Ipsec Policy
src-address=172.16.x.x/24 src-port=any dst-address=172.17.x.x/24
dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp tunnel=yes sa-src-address=172.27.x.x
sa-dst-address=172.26.x.x proposal=proposal1 ph2-count=1

1 ;;; IKE PHASE 2
src-address=97.x.x.14/32 src-port=any dst-address=19.x.x.233/32
dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp tunnel=yes sa-src-address=97.x.x.2
sa-dst-address=19.x.x.25 proposal=proposal2 ph2-count=0

2 A ;;; IKE PHASE 2
src-address=97.x.x.14/32 src-port=any dst-address=41.x.x.134/32
dst-port=any protocol=all action=encrypt level=unique
ipsec-protocols=esp tunnel=yes sa-src-address=97.x.x.2
sa-dst-address=19.x.x.25 proposal=proposal2 ph2-count=1

3 T * group=default src-address=::/0 dst-address=::/0 protocol=all
proposal=default template=yes

There are two sites.
Site1 which is my side:
LAN details 10.x.x.x/24
WAN details 97.x.x.x/28
My Live Server Local Ip 10.x.x.10 >97.x.x.14

Site2 is Partner
LAN details x.x.x.x/x
WAN details 41.x.x.x/28 and 19.x.x.x/27
2 Live Severs
Fisrt server nat to 41.x.x.134
2nd server nat to 19.x.x.233
The servers at either side talk to each other using their publicly translated addresses but through a VPN tunnel.
My Tunnel Interface IP is (97.x.x.2) which is in the same public ip block as the Live Server ip after translation(nat)
Partner Tunnel interface IP is (19.x.x.25) which is in the same subnet with one of their Live Servers IP after translation(nat)

The Live Server at my end(97.x.x.14) can reach their first Live Server (41.x.x.134) through IPSEC Tunnel
But 97.x.x.14 cannot reach 19.x.x.233

I will upload the Log Soon.
Thanks.

Here is the Log:
time=15:48:35 topics=ipsec,debug message="===== received 92 bytes from 19.x.x.25[500] to 97.x.x.2[500]"

time=15:48:35 topics=ipsec,debug,packet message="54c833e9 77f6c95f bb336122 1058c966 08100501 9a5ff152 0000005c 1c633283"

time=15:48:35 topics=ipsec,debug,packet message="1dc0905e 12087c59 661dd3ef be2d7468 c1f7014d 675b847a 92de41a7 53ef314a"

time=15:48:35 topics=ipsec,debug,packet message="eeb574de 52bb357d 3e9529f4 f8836c4b f6f8a64f 388f90b4 8dd32edd"

time=15:48:35 topics=ipsec,debug message="receive Information."

time=15:48:35 topics=ipsec,debug message="compute IV for phase2"

time=15:48:35 topics=ipsec,debug message="phase1 last IV:"

time=15:48:35 topics=ipsec,debug message="f1ed034c 9cce2aeb b7096ad5 87b3fe1f 9a5ff152"

time=15:48:35 topics=ipsec,debug message="hash(sha1)"

time=15:48:35 topics=ipsec,debug message="encryption(aes)"

time=15:48:35 topics=ipsec,debug message="phase2 IV computed:"

time=15:48:35 topics=ipsec,debug message="ce4189dd 8df31491 7cb25db2 f5cd9039"

time=15:48:35 topics=ipsec,debug message="encryption(aes)"
time=15:48:35 topics=ipsec,debug message="IV was saved for next processing:"

time=15:48:35 topics=ipsec,debug message="f8836c4b f6f8a64f 388f90b4 8dd32edd"

time=15:48:35 topics=ipsec,debug message="encryption(aes)"

time=15:48:35 topics=ipsec,debug message="with key:"

time=15:48:35 topics=ipsec,debug message="b61e213b 20bd95a2 6d55173e e821bd67 2262198b 92d1ede8 7e7124e4 561d4e41"

time=15:48:35 topics=ipsec,debug message="decrypted payload by IV:"

time=15:48:35 topics=ipsec,debug message="ce4189dd 8df31491 7cb25db2 f5cd9039"

time=15:48:35 topics=ipsec,debug message="decrypted payload, but not trimed."

time=15:48:35 topics=ipsec,debug message="0b000018 f26a0c23 5c5eb9ed bf6a2c97 9ea0e6a4 6d9bdb58 00000020 00000001"

time=15:48:35 topics=ipsec,debug message="01108d28 54c833e9 77f6c95f bb336122 1058c966 339c8900 00000000 00000000"

time=15:48:35 topics=ipsec,debug message="padding len=1"

time=15:48:35 topics=ipsec,debug message="skip to trim padding."

time=15:48:35 topics=ipsec,debug message="decrypted."

time=15:48:35 topics=ipsec,debug message="54c833e9 77f6c95f bb336122 1058c966 08100501 9a5ff152 0000005c 0b000018"

time=15:48:35 topics=ipsec,debug message="f26a0c23 5c5eb9ed bf6a2c97 9ea0e6a4 6d9bdb58 00000020 00000001 01108d28"

time=15:48:35 topics=ipsec,debug message="54c833e9 77f6c95f bb336122 1058c966 339c8900 00000000 00000000"

time=15:48:35 topics=ipsec,debug message="HASH with:"

time=15:48:35 topics=ipsec,debug message="9a5ff152 00000020 00000001 01108d28 54c833e9 77f6c95f bb336122 1058c966"

time=15:48:35 topics=ipsec,debug message="339c8900"

time=15:48:35 topics=ipsec,debug message="hmac(hmac_sha1)"

time=15:48:35 topics=ipsec,debug message="HASH computed:"

time=15:48:35 topics=ipsec,debug message="f26a0c23 5c5eb9ed bf6a2c97 9ea0e6a4 6d9bdb58"

time=15:48:35 topics=ipsec,debug message="hash validated."

time=15:48:35 topics=ipsec,debug message="begin."

time=15:48:35 topics=ipsec,debug message="seen nptype=8(hash) len=24"

time=15:48:35 topics=ipsec,debug message="seen nptype=11(notify) len=32"

time=15:48:35 topics=ipsec,debug message="succeed."

time=15:48:35 topics=ipsec,debug message="19.x.x.25 notify: R_U_THERE"

time=15:48:35 topics=ipsec,debug message="19.x.x.25 DPD R-U-There received"

time=15:48:35 topics=ipsec,debug message="compute IV for phase2"

time=15:48:35 topics=ipsec,debug message="phase1 last IV:"

time=15:48:35 topics=ipsec,debug message="f1ed034c 9cce2aeb b7096ad5 87b3fe1f 8427ca2c"

time=15:48:35 topics=ipsec,debug message="hash(sha1)"

time=15:48:35 topics=ipsec,debug message="encryption(aes)"

time=15:48:35 topics=ipsec,debug message="phase2 IV computed:"

time=15:48:35 topics=ipsec,debug message="9755e7c3 b85f32ab 980ec4a2 1d9e4e4e"

time=15:48:35 topics=ipsec,debug message="HASH with:"

time=15:48:35 topics=ipsec,debug message="8427ca2c 00000020 00000001 01108d29 54c833e9 77f6c95f bb336122 1058c966"

time=15:48:35 topics=ipsec,debug message="339c8900"

time=15:48:35 topics=ipsec,debug message="hmac(hmac_sha1)"

time=15:48:35 topics=ipsec,debug message="HASH computed:"

time=15:48:35 topics=ipsec,debug message="d1c941a9 85a6533c 9236e6dc ec0d0a04 8b53e9b7"

time=15:48:35 topics=ipsec,debug message="begin encryption."

time=15:48:35 topics=ipsec,debug message="encryption(aes)"

time=15:48:35 topics=ipsec,debug message="pad length = 8"

time=15:48:35 topics=ipsec,debug message="0b000018 d1c941a9 85a6533c 9236e6dc ec0d0a04 8b53e9b7 00000020 00000001"

time=15:48:35 topics=ipsec,debug message="01108d29 54c833e9 77f6c95f bb336122 1058c966 339c8900 cf9bc9df f0c0ac07"
time=15:48:35 topics=ipsec,debug message="encryption(aes)"

time=15:48:35 topics=ipsec,debug message="with key:"

time=15:48:35 topics=ipsec,debug message="b61e213b 20bd95a2 6d55173e e821bd67 2262198b 92d1ede8 7e7124e4 561d4e41"

time=15:48:35 topics=ipsec,debug message="encrypted payload by IV:"

time=15:48:35 topics=ipsec,debug message="9755e7c3 b85f32ab 980ec4a2 1d9e4e4e"

time=15:48:35 topics=ipsec,debug message="save IV for next:"

time=15:48:35 topics=ipsec,debug message="ff946ead 1e9f9578 b0687b7a 1a3bdcc3"

time=15:48:35 topics=ipsec,debug message="encrypted."

time=15:48:35 topics=ipsec,debug message="92 bytes from 97.x.x.2[500] to 19.x.x.25[500]"

time=15:48:35 topics=ipsec,debug message="1 times of 92 bytes message will be sent to 19.x.x.25[500]"

time=15:48:35 topics=ipsec,debug,packet message="54c833e9 77f6c95f bb336122 1058c966 08100501 8427ca2c 0000005c 0ea6867e"

time=15:48:35 topics=ipsec,debug,packet message="94249c73 075a23b3 5286fdff 0d63219d 9051d4db 91348f9d 9b7daef2 4f7fe9ba"

time=15:48:35 topics=ipsec,debug,packet message="7b630f94 eed877da ce31ffb7 ff946ead 1e9f9578 b0687b7a 1a3bdcc3"

time=15:48:35 topics=ipsec,debug message="sendto Information notify."

time=15:48:35 topics=ipsec,debug message="received a valid R-U-THERE, ACK sent"

time=15:48:40 topics=ipsec,debug message="19.x.x.25 DPD monitoring...."

time=15:48:40 topics=ipsec,debug message="compute IV for phase2"

time=15:48:40 topics=ipsec,debug message="phase1 last IV:"

time=15:48:40 topics=ipsec,debug message="f1ed034c 9cce2aeb b7096ad5 87b3fe1f 80c222de"

time=15:48:40 topics=ipsec,debug message="hash(sha1)"

time=15:48:40 topics=ipsec,debug message="encryption(aes)"

time=15:48:40 topics=ipsec,debug message="phase2 IV computed:"

time=15:48:40 topics=ipsec,debug message="8e2ab24f 2baceac1 4214dd41 8597e1b6"

time=15:48:40 topics=ipsec,debug message="HASH with:"

The passwords in the ipsec output are not my real passwords.

The passwords in the ipsec output are not my real passwords.

Good, I was a bit scared when seeing one shared secret corrected to plain (which seems like obfuscation) but the other one to which looks as if it could eventually be a real one.

Other than that:

• the log seems too short to me to reveal anything useful, I would need at least 60 seconds of the log to see what really happens there
• I am totally lost in your NATs and tunnel interface addresses. As you say there are 1:1 NATs at both ends, I would expect something like this:
  
  
  Code: Select all

  mikrotik  ---        NAT        ---        NAT        --- server
  a.a.a.a       a.a.a.a<->b.b.b.b     c.c.c.c<->d.d.d.d     d.d.d.d
  

  
  
  So at your Mikrotik side, the policy would be:
  
  Code: Select all

  src-address=a.a.a.a

  ,
  Code: Select all

  dst-address=d.d.d.d

  (this is to match, for sending via the tunnel, the packets from the real address of the Mikrotik to the real address of the remote server)
  
  
  Code: Select all

  sa-src-address=a.a.a.a

  ,
  Code: Select all

  sa-dst-address=c.c.c.c

  (this is to establish the SA from the real address of the Mikrotik towards the public address
  Code: Select all

  c.c.c.c

  which is then dst-nated to the real
  Code: Select all

  d.d.d.d

  of the server)
  
  Are you telling me that
  Code: Select all

  a.a.a.a=97.x.x.2

  and
  Code: Select all

  b.b.b.b=97.x.x.14

  on your end, so both are in the same subnet (and thus both of them are from the public IP range)? And are you telling me that
  Code: Select all

  b.b.b.b

  is up not only on the NAT device but also on the Mikrotik itself, in parallel to
  Code: Select all

  a.a.a.a

  , making it possible for the IPSec to run without NAT traversal support as the log suggests? What about mapping of the remote addresses, is
  Code: Select all

  c.c.c.c=19.x.x.25

  and
  Code: Select all

  d.d.d.d=41.x.x.134

  as the policy says?

The ipsec tunnel is built after nat translation.
Site A private of a.a.a.a is translated to b.b.b.b

Site B private of c.c.c.c is translated to
d.d.d d
Then b.b.b.b can reach d.d.d d through vpn

So I hope you get the ideas.
Site A has one Live sever
Private ip a.a a a nat to public b.b.b.b

Site B has two Live Servers
Private ip c.c.c.c nat to public d.d.d.d
Private ip e.e.e.e nat to public f.f.f f
The b.b.b.b can reach d.d.d d through vpn.

The problem is that b.b.b.b can not reach the second Live server in Site e.e.e e through vpn.
So I have two ipsec policies for my server to reach both servers at the other end but once the first policy is processed and established the second policy fails.
I can only reach one of the servers at the other end instead of the two through vpn.

So I have two ipsec policies for my server to reach both servers at the other end but once the first policy is processed and established the second policy fails.
I can only reach one of the servers at the other end instead of the two through vpn.

OK. So if I get you right, you can only reach one of the remote servers at a time - if you disable the peer and remove the existing security associations, disable the policy which worked and re-enable the peer, the other policy will work instead?
There used to be a problem like this until the has been introduced but you did configure your policies that way so that's not the issue.

Or is it so that the policy for 19.x.x.233 never works, regardless whether the one for 41.x.x.134 is enabled or not?

In either case, only the log of the whole startup can answer what's going on.

Thanks. I'll check it out.