Hello Neil,

Can you check if your sonicwall are using IkeV1 or V2 ?

Hello Neil,

Thanks for the update. We will take it up with priority and get back to you with our input.

It is using IKE v1

Ok, could you try to change it to Ike v2

I have changed it to IKE v2 and still no connection.

I do not know sonicwall, but on Juniper you need to clear the "IKE SA" keys..

Anyway, when i had the problem, i har to change in the;

On the router

/opt/cloud/bin/ipsectunnel.sh

from

sudo echo " keyexchange=ike" >> $vpnconffile &&

to

sudo echo " keyexchange=ikev1" >> $vpnconffile &&

ofcorse you need to change your sonicwall back to IkeV1.. ;O)

When you have done this and if there is a connection error can you check it the vpn is up anyways.. ?

The changes should be on the CloudPlatform VR..

I will give that a try and let you know...    Thank you.

I am having issues connecting to the virtual router.  Isn't there a way to do it from the XenServer host that it is on?

yes, you can use root and password if you have not changed it..

Ok...   Figured that out.   I was using the wrong syntax.
I found the keyexchange and changed it to ikev1 and then rebooted the router for measure.
I then deleted the VPN connection from within the CP UI and created a new connection.

Still, no luck.

could you try on the VR

ipsec status

and post the result

and do you get a message disconnected or error..

Just to make sure you have set sonicwall back to what it was as of before 4.7.1 ?

You have changed VR to use ikeV1

?

Please post ipsec status

root@r-478-VM:~# ipsec status
000 "L2TP-PSK": 172.26.0.151[172.26.0.151]:17/1701---10.102.0.1...%any[%any]:17/%any==={0.0.0.0/0}; unrouted; eroute owner: #0
000 "L2TP-PSK": newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vpn-xxx.xxx.xxx.xxx": 10.12.12.0/24===10.102.1.56:4500[10.102.1.56]---10.102.0.1...98.164.129.68:4500[98.164.129.68]===192.168.1.0/24; erouted; eroute owner: #28
000 "vpn-xxx.xxx.xxx.xxx": newest ISAKMP SA: #24; newest IPsec SA: #28;
000
000 #28: "vpn-xxx.xxx.xxx.xxx" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 3252s; newest IPSEC; eroute owner
000 #28: "vpn-xxx.xxx.xxx.xxx" esp.b6635d58@98.164.129.68 (0 bytes) esp.c7069e5d@10.102.1.56 (0 bytes); tunnel
000 #24: "vpn-xxx.xxx.xxx.xxx" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 85521s; newest ISAKMP
000
Security Associations:
none
root@r-478-VM:~#

Yes, I changed the VR to ikev1
The SonicWALL I am testing on with this has had no changes.

can you check from a vm on the xenserver if the connection is up ?

forinstance ping from a vm in xenserver to the endpoint i.e the gateway on the customer side.

and do you get an error or disconnected in CP, connection status.?

VMs on XenServer cannot see client side.
VPN Connection Status in CP is "disconnected"

Also, looking at the logs on the SonicWALL..   It seems as though Phase 1 connects but Phase 2 either times out or has some sort of mismatch.  (I've double checked the settings on each and and they match)

And....   Now, I am even more confused...
I've been trying different connection types...   Now, on the client's SonicWALL, it is showing the VPN as connected.  But, the CP VPN Connection status is disconnected.   But, I am now able to ping the client's SonicWALL from within one of their Instances in CP.

That is great,

In my case i had to change the file:

opt/cloud/bin/checks2svpn.sh

from cat /tmp/vpn-$1.status | grep "ESTABLISHED" > /dev/null

to

cat /tmp/vpn-$1.status | grep -i "ESTABLISHED" > /dev/null

så the text ESTABLISHED is case insensetive.

when it is done, clik on reconnect on the connection...

I've done that and it shows as connected now!   Thank you VERY MUCH for all of your help Gert!
Was that essentially just showing a false negative?  If so, I assume that both the ike v1 and the status is going to happen every time we make a new VPN?

Hello,

You are welcome, glad to help..

I had the problem last friday.. :O)

I figure that when they changed the VPN engine from openswan to strong swan (i think), it also changed the default from ikeV1 to IkeV2, i too could have used this information.. :O)

Regarding the false positive, i think the new version reports back in lowercase, if they only check uppercase it does not work, and we get the status disconnected or error.

When you create a new VR og use the cleanup option (It creates a new VR), you have to manuelly change the settings (until it is fixed or you), i do not think that the IKE version will be fixed but i belive the script will..

Have a nice day..

Kind regards Gert

Yes, it would have been nice to know about the default IKE version, or at the very least have a switch to enable/disable.   And the false positive...   That just threw me.   We should put in for bug reports.
Again, thank you very much!  

Dear all,

We are the same kind of issue.
We just upgrade from 4.7.0 to 4.7.1 but all of our VPN connection are now down (client VPN and s2s VPN)

We are using ASA cisco, i juste recreated the connection s2s vpn but still not working.

Here ipsec status :

Do you know if we need to perform any modification on VR or before/after upgrade on cloudplatform ?

Thanks upfront,

Best regards,

N.B

Hey Everyone,

I am one of the developer who worked on this (not from Accelerite).  I don't have visibility into what Accelerite actually deployed, but I suspect it is the content of this PR.  I have continued the development of this PR here to fix a few issues that we ran into when testing this.  Keep in mind that my experience with this code is from Apache CloudStack (what CloudPlatform is built on) and not CloudPlatform.

First of all.  IKEv2 will not work, only IKEv1 is supported unless Accelerite completely changed the API for creating the the VPN Gateway since fields have changed, and I doubt that is the case.

With ACS anyway, just doing a reset of the VPC is not enough.  This does fix somethings, but it is not everything.  In ACS we have a checkbox for 'Clean Up' which MUST be checked when you reset the VR in order for the new implementation to be completely deployed.  Without this checkbox checked, a reset of the VPC will only reboot the VR.  If you check the 'Clean Up' checkbox when you reset the VPC, the VR will be destroyed and a new VR will be provisioned according to the configuration defined by ACS/ACP.  In testing, we have found this is required in order for this functionality to be correctly upgraded in ACS.

We also found a strange issue when working on this that the 'ipsec' command binary does not seem to be updated until a reset (of any kind) of the VPC.  Even though 'which' and 'version' would show that the ipsec command was pointing at the StrongSwan binary, it was still executing as OpenSwan when the VR used it.  We could not isolate exactly why this was happening, but a reset of the VR did fix it.

It looks like Neil ran into this problem as well given the following:
'000 #24: "vpn-xxx.xxx.xxx.xxx" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 85521s; newest ISAKMP'
The 'ISAKMP SA established' string is the OpenSwan version of the 'ipsec status' output.  Note this change in the code to represent this change between OpenSwan and StrongSwan.

The change that Gert did to 'opt/cloud/bin/checks2svpn.sh' for the case insensitive grep should not be required if the StrongSwan ipsec status is is correctly being used.  I tested this yesterday to verify and I can not make StrongSwan output a status that is not all caps.

As for the 'disconnected' thing.  From my testing, if the VPN Connection in the VPC is set to 'passive', it will always have a state of 'disconnected' even if the VPN connection is established.  If you uncheck the 'passive' box when creating the VPN Connection, then it will show as 'connected' when the VPN is connected.  I have not dug into this problem, but I have verified that setting the 'passive' checkbox will make the VPN show 'disconnected' even if the VPN is established.

I think thats it.  Let me know if you have any questions.

Will,

  Thank you for the information.   One thing of note; I was having the "disconnected" issue and did NOT have the VPC set to passive.   The only thing that resolved that was Gert's advice with changing the syntax in checks2svpn.sh

Hello..

I have also tried to clean/destroy  and reboot reboot of the VR, that did not help.

I have no passive VPCs

I had to change the check get the correct status..

And I have to change in the config to use IkeV1, but if i changed it back to Ike i could change the endpoints to use Ikev2 and make it work (with the connection),

I do not have acces to all endpoints so for me the change in router config was the only way..