VPN not working (changed IP Public)

[PedroPablo]

Hello guys,

I have a problem that i've been the whole day trying to make it work but i can't and i have to solve it asap.

I have around 12 vpn connections peer to peer working. I have to change those vpn connections to another IP Public little by little (my peer IP).

I tried today with 3 vpn sites modifying:

- IKE Gateway: modifying Interface, local ip addres and local identification

- Static Routes: i modified the interface and the next hop

- Security Rules: I added the new IP Public to the one that already exist.

Am i missing something? The ones with the old IP Public are working perfect but i can't make it work with the new one. (The changes in the remote peers were made as well). My remote peer told me that they can ping and traceroute me but i can't, so i guess the problem is on my side.

Can someone help me? i don't know what more to look or to change. Also i got different errors in the logs:

Site 1: 

====> PHASE-1 NEGOTIATION FAILED AS INITIATOR, MAIN MODE <====
====> Failed SA: my peer[500]-remote peer[500] cookie:6731f1a9f47445d5:0000000000000000 <==== Due to timeout.
2019-02-04 19:44:36.000 +0100 [INFO]: { 2: }: ====> PHASE-1 SA DELETED <====
====> Deleted SA: my peer[500]-remote peer[500] cookie:6731f1a9f47445d5:0000000000000000 <====

Site 2:

====> PHASE-1 NEGOTIATION STARTED AS RESPONDER, MAIN MODE <====
====> Initiated SA: my peer[500]-remote peer[500] cookie:81bbd9683095c862:4079c6c2a022dd4d <====
2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: DPD
2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: RFC 3947
2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2019-02-04 19:44:51.349 +0100 [INFO]: { 1: }: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
2019-02-04 19:44:52.000 +0100 [PNTF]: { 1: }: ====> PHASE-1 NEGOTIATION FAILED AS RESPONDER, MAIN MODE <====
====> Failed SA: my peer[500]-remote peer[500] cookie:de602182338cb9d0:25a62e85bee11834 <==== Due to timeout.
2019-02-04 19:44:52.000 +0100 [INFO]: { 1: }: ====> PHASE-1 SA DELETED <====
====> Deleted SA: my peer[500]-remote peer[500] cookie:de602182338cb9d0:25a62e85bee11834 <====
2019-02-04 19:44:52.511 +0100 [PNTF]: { 17: }: notification message 36136:R-U-THERE, doi=1 proto_id=1 spi=5f9a7e21c7c369e9 97a227d4d986d5b5 (size=16).
2019-02-04 19:44:54.349 +0100 [INFO]: the packet is retransmitted from remote peer[500] to my peer[500].

Site 3: 

[PERR]: Couldn't find configuration for IKE phase-1 request for peer IP remote peer[500].
2019-02-04 19:50:55.615 +0100 [PNTF]: { 17: }: notification message 36136:R-U-THERE, doi=1 proto_id=1 spi=5f9a7e21c7c369e9 97a227d4d986d5b5 (size=16).
2019-02-04 19:50:56.156 +0100 [PNTF]: { 3: }: notification message 36136:R-U-THERE, doi=1 proto_id=1 spi=54f5845033049f7e cef513a42e864900 (size=16).
2019-02-04 19:50:57.000 +0100 [PNTF]: { 11: }: ====> PHASE-1 NEGOTIATION FAILED AS INITIATOR, MAIN MODE <====
====> Failed SA: my peer[500]-remote peer[500] cookie:e3c5714c065682f5:1a1619e7b34a9475 <==== Due to timeout.
2019-02-04 19:50:57.000 +0100 [INFO]: { 11: }: ====> PHASE-1 SA DELETED <====
====> Deleted SA: my peer[500]-remote peer[500] cookie:e3c5714c065682f5:1a1619e7b34a9475 <====

received unencrypted Notify payload (AUTHENTICATION-FAILED) from IP remote peer[500] to my peer[500], ignored.

[reaper]

for site1 you'll want to try and initiate from the othe end to see if you can get any useful error messages (the initiating side is always left in the dark about what went wrong

site2 see if you can delete all SAs on both ends to ensure nothing of the previous communication is cached

looks like it's trying to traverse NAT, has this been enabled on both ends and is this required ?

site3 seems to have a misconfiguration, causing it to not find a matching phase1 proposal

[PedroPablo]

Thank you so much for reply! I'll try what you said.

What i don't understand is that the same and exact configuration is working perfectly but with another IP on my peer so i can't see what is wrong. 

Like, if i modify my peer IP again and i set the old IP and my remote peer do the same, the tunnel would be UP almost instantly. So i don't get why could be a mismatch if nothings was changed besides the IP 😞

* I tried before to clear the session of ike and ipsec but didn't work.

[reaper]

have you tried configuring a new one just to make sure there's no underlying issues with the IP/policy?

there's usually 3 factors:

'local ip' local / 'peer ip' on other end

'local identifier' local/ 'remote identifier' on other end

SA's need to be cleared simultaneously on both end, some pesky deployments/unfortunate timing may require several 'clear's before theyre actually cleared properly (may get refreshed with bad info immediately after deletion)

[PedroPablo]

Actually a i didn't try that. I will give a try to that and i will let you know how it goes. 

Thanks for the reply!

[PedroPablo]

Hello,

For everyone with a similar situation, i fixed the problem. So going through the logs i could see that it wasn't a configuration mismatch. (Well actually in one of them it was a configuration mismatch (wrong ipsec crypt configuration) as well)

The gateway for the next hop in my static route it was wrong. My ISP gave me a wrong one...¬¬. Once i put the right one it started to work smoothly.

Thanks @reaper for your help!

[vivekkumar01]

The error "Couldn't find configuration for IKE phase-1 request for peer IP" can also be removed by checking the IKE version being used between both the peers. Both the peers should either be in IKEV1 or IKEV2.