Jul 06
A Very Quick Guide for Configuring StoneGate for iOS VPN
Firewall Engine, VPN - 
(7 votes, average: 4.71 out of 5)
Loading ...
Add comments
(7 votes, average: 4.71 out of 5) Loading ...Have a shiny new iPad/iPhone/iOS device and wonder how to access all your precious corporate data? Are you a sysadmin who needs to manage the corporate LAN from everywhere? Do you need some intranet-only web pages you don’t want to publish for security reasons?
This simple tutorial will explain how to create a VPN between your StoneGate and your iDevices.
Thanks to Marco Rottigni who gave me precious hints to make all things work!
This is my very first post to the Stoneblog, if you want feel free to give me feedbacks and suggestions! Roberto
24 Responses to “A Very Quick Guide for Configuring StoneGate for iOS VPN”
Leave a Reply
You must be logged in to post a comment.
July 15th, 2011 at 6:26 pm
Hi Roberto,
1.- Question, in the file “openssl_user.cnf” client certificate conf, on line:
- commonName_default = MyCompany Client Certificate
should change to
- commonName_default = MyCompany
Am i right?
Observation: because you don´t have it as an option to change (line in blue) configuration generated certificated.
BS
July 15th, 2011 at 6:46 pm
Yes, you’re right: it should have been marked in blue. It’s simple a default tesx which is proposed: this is the text you will see in the certificate’s name.
In my case i set it to my company’s name.
Thanks for your observation!
Roberto
July 16th, 2011 at 1:57 am
Roberto,
Now we are doing some tests in a FW-5.3.0 and SMC-5.3.1, following step by step the tutorial you published.
When we tried to use a iPhone iOS v4.1 to connect it fails. We uploaded the PrimaCA.cer and the iOSUser.p12 on the iPhone and everything seems to be find.
But, when the connection starts we see in the log server that shows the following errors … :
link
https://www.yousendit.com/download/cnJqS3drdGpwaFJFQlE9PQ
… And the connection is never stablished.
Any suggestions?
Do you think we need to open a ticket for this issue?
BS
Best Regards
July 18th, 2011 at 9:06 am
Could it be a rulebase problem? The “No rule found for IKE peers” may suggest something wrong in your firewall policy. Did you write a rule for your new vpn clients and select the “enforce Vpn” option? If it is a client ip address, you might check the DHCP server log along with the fw log, so you can see if the DHCP server is correctly serving addresses onto the vpn.
Maybe it could be a good idea to open a ticket, i didn’t have that kind of problem and i’m afraid i can’t help with these few clues.
Anyway, i’m really happy that someone is using my tutorial
Best regards and good luck!
Roberto
July 27th, 2011 at 8:09 pm
Hi Roberto
I’m still experimenting with the help of support I have had Stonesoft
advances thanks to Teo, the last steps have had problems with
version of IKE v1 and IKE v2, I am testing with version
IKE v1, but the certificate is sent the following message
Starting IKEv1 main mode negotiation respond
Proposal IKEv1 SA SA (the whole key)
IKEv1 SA error: Authentication failed
IKEv1 SA réponses failed, Remote C = (all key)
IKE SA negotiation fir waiting to finish, marking invalid IKE SA
IKE SA deleted
Renteria
September 7th, 2011 at 12:05 pm
After doing almost a doctoral work to connect SG and iOS I did manage to crack everything down to every detail possible. I now have working connection from OS X, iPhone and iPad. Eveyrthing works to same VPN GW as other mobile users. So no additional GW is necessary as manual suggests.
I suggest everybody to first try and connect with OS X. This will be much easier to test and debug. The key here is to enable OS X ipsec client debug (racoon is the name of the client). This can be done via following:
• Run “sudo vi /etc/racoon/racoon.conf” on the Mac OS X command line.
• Change (remove hash in front) the following line: log debug;
• Edit your syslog configuration file: sudo vi /etc/syslog.conf
• At the end of this file, add: *.debug /var/log/debug.log
• Reload the syslog daemon:
ps aux | grep syslog
sudo kill -HUP
• Stop racoon: sudo killall racoon
Now start the VPN Client and you will have plenty of debug in /var/log/debug.log
Now the KEY PROBLEM of not being able to use Internal CA of StoneGate is the fact that the certificate of Internal CA does not have “Key usage” defined as “Key Usage – Digital Signature, Key Encipherment”. You can see that immediately since if you import Internal CA certificate in Keychain/System (all cets should go there!), enable trust on everything and then import the Stonegate GW certificate (signed by internal CA) this certificate will still be marked as “signed by unknown CA”. Same goes for the user certificate which you can also sign by internal CA. Now if you import all certificates (SG Internal CA, SG GW signed by internal CA and iosuser certificate signed by internal CA) in Keychain/System and set all of them to “Always TRUST” you will be able to connect to SG from OS X VPN Client. But it won’t work from an iOS device (iPhone). It will always complain over invalid server certificate.
looking at iPhone Configuration Utility/Debug you can actually see racoon debug that complain over “Root certificate is not trusted.” no mater the fact, that you can also import the SG Internal CA certificate to iPhone. You will always get that message.
This is why you should use external CA. Is using external CA to sign the SG GW certificate you will immediately see in keychain that now if you import external CA and SG GW certificate it will say it is trusted if you set external CA certificate to “Always TRUST”. As already mentioned my suspicion is that the Internal SG CA certificate is missing the necessary Key Usage fields.
Also VERY IMPORTANT! if you have SG GW with two certificates (one signed by internal CA and one signed by external CA) it won’t work as SG will send only certificate signed by internal CA to the IPSEC client. I found that out after using racoon debug on OS X. You have to disable “Automated RSA Certificate Management” on the SG GW definition and then DELETE the internally generated certificate (and leave only the certificate signed by external CA). Do not forget to reapply policy after that.
It is still tricky to do it and it would be MUCH EASIER if SG Internal CA could directly be used – those fundamental “Key Usage” attributes added).
September 7th, 2011 at 12:10 pm
Key Usage attributes of CA should include (and internal SG CA doesn’t):
Key Usage ( 2.5.29.15 ) – Digital Signature, Key Cert Sign, CRL Sign
November 2nd, 2011 at 6:06 pm
Hi,
I discovered a easiest way to do it.
If you configure your existing VPN with the VPN profile described for iOS and you make a user certificate with the command:
openssl req -new -days 3000 -nodes -config openssl_user.cnf -out iOSUser.req –keyout iOSUser.key
Next you sign this certificate with de VPN option “Sign VPN Client certificate”.
Now you export the StoneGate “Internal IPSec CA” to a file.
If you install the exported “Internal IPSec CA” and the signed user certificate in the iPad you can use the same configuration and Public IP than the StoneGate IPSec clients.
Sorry for my poor english.
November 2nd, 2011 at 6:32 pm
Sounds a lot easier! Especially because it doesn’t seem to require a separate ip address to manage the iOS VPN.
If you want, you can try and build a graphical guide like i did before, and share your result with everybody here… i’m pretty sure everybody will appreciate your work!
Roberto
November 4th, 2011 at 11:02 am
Hi Roberto,
I’m working on it.
Jose
January 13th, 2012 at 11:55 am
Hi all.
I have tried all the choices and followed all the advices unsuccessfully. I would like to know if someone has tested this kind of vpn with iOS5 and/or os x 10.7 lion.
Thanks in advance.
January 19th, 2012 at 10:55 pm
Doing some OS X clients again on another SG FW a couple more notes….
Be sure that at least ONE USER has IPSEC as authentication method in your policy (it doesn’t matter if this user actually has ipsec method enabled). If no user has it, IPSEC authentication method will not be enabled on engines at all and your iosuser certificate will thus fail!
Creating vpn config package with “Iphone Configuration Utility” is fine for iOS devices but when I used it on OS X device, VPN didn’t work no matter what. Reason was that StoneGate CA certificate was added to “Login” keychain and even moving it to system keychain didn’t help. BUT if I deleted the CA certificate from the keychain and manually added this same SG CA certificate to System keychain (when you import it, be sure to select destination keychain->system) everything worked OK (sometimes you have to kill racoon process -> “sudo killall -9 racoon”).
Another thing is that Jailbroken iPhones will NOT establish VPN no matter what (IOS 5.0.1). This is a known issue (not sg related), just to let you all know -> do not test with JB iPhones.
January 20th, 2012 at 10:09 am
Hi alien2108,
Did you test the way Jose Villafaña sugested? I keep geting the “Negotiation with VPN server failed”
February 7th, 2012 at 11:22 am
Hi,
i tried making certificates but im having a problem with .p12.. i cant upload it because of its size, 0kb. i also tried Jose’s way but still cant see the certificate on the iphone. the Use certificate tab is grayed out. what does that mean? sorry for my poor english..
February 7th, 2012 at 11:33 am
@rence.suarez: if it has 0kb size it means that export or generation obviously failed.
To generate good working certificates for these tests, I recommend to user the nice easy application XCA which is available for free @ http://xca.sourceforge.net.
Also, consider that on the iPhone you need to import both the user certificate and the CA public certificate that is used to validate the server certificate that SG will present.
Hope this helps.
February 7th, 2012 at 12:09 pm
@RoarinPenguin thanks for the prompt reply.. i downloaded the application.. but im really lost.. can you send me a guide or a documentation on how to use this app? thanks a lot!
February 8th, 2012 at 11:11 am
another question.. is this support on 5.0.5?
March 5th, 2012 at 12:57 pm
Does it work with 5.2.x?
March 8th, 2012 at 8:10 pm
Hello.
I’m having no luck with this. I’ve followed the guide to a T and also used alien2108′s tips. Running 5.3.3 and have tested with Lion and a iPAD. The two errors I’m seeing are.
Sending error notify: Authentication failed (No public key found)
Certificate lookup error: did not find trusted CA
Of course the rest of it fails too. All certs are trusted and within the system keys within iOS. There are no other VPN’s configured on the firewall.
Any pointers welcome.
March 12th, 2012 at 3:36 pm
Hello
I now have this working thanks to Stonesoft staff.
At least one user with the same mail address/common name of the
certificate used to identify the machine must exist in SMC (replicated
to firewall).
I was using a generic test user which we use for testing dynamic VPN’s.
March 13th, 2012 at 3:26 pm
Hi linkconnect,
I am getting the same error message. We have created a user with the correct UPN (I can see successful LDAP search requests) in our AD (as this is the default realm) but it does not work
We are using 5.2.7 though.
Any ideas?
Best regards
March 14th, 2012 at 11:37 am
Hm, now I am a step further, it seems that it does not work with 5.2.x.
Luckily I have a “test” firewall with 5.3.4 where I got past the “did not find trusted CA” error message. Now on the iPad I get the error “Server certificate cannot be verified”
However it should be trusted as I have imported the OpenSSL CA into the iPad. Strange.
March 14th, 2012 at 5:12 pm
I guess I now know why it is not working. Our SG CA certificate was issued with a MD5 signature. Since iOS 5 MD5 signed certificates are classified as untrusted (see e.g. http://arstechnica.com/apple/news/2011/10/ios-5-protects-against-diginotar-md5-signed-certs.ars). Strange enough the FW obviously presents the SGW VPN certificate signed by the internal CA even if there exists a dedicated SGW with a VPN certificate signed by an external CA
March 20th, 2012 at 6:59 pm
Finally I got it working: after re-installing all certificates (after wiping the iPad because downgrading to 4.3.5 did not work out) I got a step further (authentication worked fine). Then I had to deal with the DHCP Relay for the virtual adapter (I tested on a branch location so I needed to forward the packets into the S2S VPN). Now I will test it with our internal MS CA (CRL/OSCP will also be interesting) and maybe again with 5.2.7 (it should work according to the Stonesoft support).