site to site vpn tunnel is up but no traffic flowing

[fortinoy]

setup site to site vpn using the ipsec wizard. tunnel is already up but keeps on getting the error "progress ipsec phase 1 negotiate failure" in vpn events log. need your help where and what to check.

note: i initially setup ssl vpn on the same fortigate and it works well. trying to setup the site to site vpn now. the setup on the ipsec wizard is easy and fast. but it is not working.

please advise. thanks.

[zaphod]

@rwpatterson

in sd-wan environment it is normal that the defaultroute has a distance with 1, all static routes get 10

i have checked one of ny sdwan branches and it is the same.

but in sdwan you need to handle ipsec vpns other than without sdwan.. think that is the problem here... 

i have posted a kb article which describes a how to...

greets

zaphod

[rwpatterson]

zaphod wrote:

@rwpatterson

in sd-wan environment it is normal that the defaultroute has a distance with 1, all static routes get 10

i have checked one of ny sdwan branches and it is the same.

but in sdwan you need to handle ipsec vpns other than without sdwan.. think that is the problem here... 

i have posted a kb article which describes a how to...

greets

zaphod

OK. I'm still learning after all these years...

[zaphod]

me too :)

[smari]

You should not have to make any changes to the administrative distance if the route to the tunnel is more specific than the default route.

[rwpatterson]

fortinoy wrote:

The administrative distance of the static route for the tunnel is 10. We have a static route with a lower administrative distance than the tunnel at both ends.

That makes no sense. The static route for the tunnel needs to have a lower administrative distance than the DEFAULT route, which was not mentioned.

[brycemd]

rwpatterson wrote:

fortinoy wrote:

The administrative distance of the static route for the tunnel is 10. We have a static route with a lower administrative distance than the tunnel at both ends.

That makes no sense. The static route for the tunnel needs to have a lower administrative distance than the DEFAULT route, which was not mentioned.

It always routes based on the most specific route, then distance if there are equally specific routes. Every route takes priority over 0.0.0.0

[fortinoy]

Here is the debug from the remote Fortigate:

FG100ETK18010728 $ ike 0: comes REMOTE WAN IP:500->LOCAL WAN IP:500,ifindex=7....

ike 0: IKEv2 exchange=INFORMATIONAL_RESPONSE id=40699c6066b7a5dc/d7f17ef590733f17:00000001 len=76

ike 0:REMOTE VPN NAME:13: received informational response

ike 0:REMOTE VPN NAME:13:24: processing informational acknowledgement

ike 0:REMOTE VPN NAME:13: processing delete ack (proto 3)

ike 0:REMOTE VPN NAME:REMOTE VPN NAME:23: send SA_DONE SPI 0xc219d81

ike 0:REMOTE VPN NAME: SA_DONE failed. SPI 0xc219d81, error 2: No such file or directory

ike 0:REMOTE VPN NAME: deleting IPsec SA with SPI 0c219d81

ike 0: comes REMOTE WAN IP:500->LOCAL WAN IP:500,ifindex=7....

ike 0: IKEv2 exchange=CREATE_CHILD id=40699c6066b7a5dc/d7f17ef590733f17:00000003 len=460

ike 0:REMOTE VPN NAME:13: received create-child request

ike 0:REMOTE VPN NAME:13: responder received CREATE_CHILD exchange

ike 0:REMOTE VPN NAME:13: responder creating new child

ike 0:REMOTE VPN NAME:13:25: peer proposal:

ike 0:REMOTE VPN NAME:13:25: TSi_0 0:REMOTE LAN IP-REMOTE LAN IP:0

ike 0:REMOTE VPN NAME:13:25: TSr_0 0:LOCAL LAN IP-LOCAL LAN IP:0

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: comparing selectors

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: matched by rfc-rule-2

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: phase2 matched by subset

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: accepted proposal:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: TSi_0 0:REMOTE LAN IP-REMOTE LAN IP:0

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: TSr_0 0:LOCAL LAN IP-LOCAL LAN IP:0

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: autokey

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: incoming child SA proposal:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: proposal id = 1:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:   protocol = ESP:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:      encapsulation = TUNNEL

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=ENCR, val=AES_CBC (key_len = 128)

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=INTEGR, val=SHA

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=DH_GROUP, val=MODP2048

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=ESN, val=NO

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: matched proposal id 1

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: proposal id = 1:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:   protocol = ESP:

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:      encapsulation = TUNNEL

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=ENCR, val=AES_CBC (key_len = 128)

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=INTEGR, val=SHA

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=DH_GROUP, val=MODP2048

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25:         type=ESN, val=NO

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: lifetime=43200

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: PFS enabled, group=14

ike 0:REMOTE VPN NAME: schedule auto-negotiate

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: set sa life soft seconds=42927.

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: set sa life hard seconds=43200.

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: IPsec SA selectors #src=1 #dst=1

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: src 0 7 0:LOCAL LAN IP-LOCAL LAN IP:0

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: dst 0 7 0:REMOTE LAN IP-REMOTE LAN IP:0

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: add IPsec SA: SPIs=82229bb1/0c219d82

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: added IPsec SA: SPIs=82229bb1/0c219d82

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: sending SNMP tunnel UP trap

ike 0:REMOTE VPN NAME:13:REMOTE VPN NAME:25: responder preparing CREATE_CHILD message

ike 0:REMOTE VPN NAME:13: sent IKE msg (CREATE_CHILD_RESPONSE): LOCAL WAN IP:500->REMOTE WAN IP:500, len=460, id=40699c6066b7a5dc/d7f17ef590733f17:00000003

ike shrank heap by 126976 bytes

[OneOfUs]

From the logs it looks like the Phase 1 / Phase 2 come up and negotiate successfully, but I saw this:

recv IPsec SA delete, spi count 1

It appears the disconnect is being initiated from the peer.  Can you run the same debugs on the remote side?

[Toshi_Esumi]

For the log you saw was "IPsec". Nothing to do with SSL VPN or other types of VPNs. If somebody from other country  is trying to set up a VPN to exploit your network at the public IP on the interface, you would see those logs. It actually happens quite often than not. That's why I asked if the remote IP in the log is the IP for your VPN's remote IP.

[OneOfUs]

Based on this: ike 0:”LOCAL VPN NAME”: sending SNMP tunnel DOWN trap for “LOCAL VPN NAME” ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21:[<font] my proposal: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: [<font]proposal id = 1: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: protocol id = IPSEC_ESP: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: PFS DH group = 14 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: trans_id = ESP_AES_CBC (key_len = 128) ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: type = AUTH_ALG, val=SHA1 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: [<font]proposal id = 2: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: protocol id = IPSEC_ESP: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: PFS DH group = 5 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: trans_id = ESP_AES_CBC (key_len = 128) ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: type = AUTH_ALG, val=SHA1 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: incoming proposal: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: proposal id = 1: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: protocol id = IPSEC_ESP: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: PFS DH group = 14 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: trans_id = ESP_AES_CBC (key_len = 128) ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: type = AUTH_ALG, val=SHA1 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: [<font]negotiation result ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: proposal id = 1: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: protocol id = IPSEC_ESP: ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: PFS [<font]DH group = [<font]14 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: trans_id = ESP_[<font]AES_CBC (key_len = [<font]128) ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: encapsulation = ENCAPSULATION_MODE_TUNNEL ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: type = AUTH_ALG, val=[<font]SHA1 ike 0:”LOCAL VPN NAME”:330:”LOCAL VPN NAME”:21: [<font]sending SNMP tunnel UP trap   It appears the phase 1 (IKE) is coming up and the issue is with the phase 2 (IPSEC) negotiation.  The only thing I saw odd in the debug is that you appear to have two phase 2 selectors however the remote only has one.  It may help to eliminate the 2nd phase 2 selector and additional (unneeded) encryption / authentication protocols.  Make sure the phase 2 local / remote addresses match.   The phase 2 negotiation appears to complete using: AES-128 SHA1 DH 14 Keylife 43200.     If you look at the IPSEC VPN monitor does the tunnel appear to bounce?