Tunnel VPN with Windows Phone 8.1

[mazu74]

Hi, i have lumia 930 with Windows Phone 8.1 and i try to connect to my Fortigate 90D v5.2 with l2tp over ipsec but ... I create, on my FG, an IOS tunnel (Dialup - iOS (Native)) for Iphone and it's ok. I also create Windows tunnel (Custom - Dialup User) for my laptop and it's ok. Do i create specific tunnel for my Windows Phone ? Thanks

[AndreaSoliva]

Hi

you can if you want but it is a question of following (from my point of view)

- I would absolutly prevent L2tp because this kind of connection is a "software based vpn" which means no acceleration on the FGT hardware which means also this stuff is slow!

- I can not talk about lumia and windows phone because I do not know this kind of device but I can talk about following:

- For IPhone use embedded IPSec based VPN client (cisco standard on each IPhone)

- For IPad the same as for IPhone

- For Android use the Fortinet IPSec VPN client based on FGT version 5.2 (in opposite to Android IPhone does not have this function because of the restrictions of apple which means the same client used for Android is also available for IPhoen/IPad but this client does not include the VPN IPSec function instaed the embedded cisco standard client can be used which works nice)

At least following: If you build up VPN IPSec for each device because they are using different encryption Phase1/2 and/or you would like to use different groups of users with different devices etc. and mostly the VPN IPSec used on such devices are in aggressive mode you HAVE to use the "local-id" configuration in Phase1 to differ between the IPSec and user meaning groups. Because IKE listens on port 500 UDP/TCP all client are sending there authentication to this IKE 500 deamon. If the deamon receives the request the deamon itself can not differ which IPSec Phase1 is used. This means if a user is in group A for phase1 A but not in group B for phase1 B the authentication would be accepted for A but not for B this means also the user receives a disconnect within seconds. To differ between the IPSec the local-id must be used which is nothing else as a identifier between different phase1 using all the same IKE 500 deamon. This what is written here is only for aggressive mode which means the stuff is not true for main mode. The disadvantage of using the aggresive mode from security point of view is that the local-id is delivered in the beginning of phase1 in clear-text. This must be known.

I hope this helps you

have fun

Andrea

[mazu74]

Thanks. whith debug : diag debug app ike -1 I have [size="1"]

ike 0:dc0dbd1bca3396f4/0000000000000000:410: responder: main mode get 1st message...[/size] ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID unknown (20): 01528BBBC00696121849AB9A1C5B2A5100000001 ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000009 ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID RFC 3947 4A131C81070358455C5728F20E95452F ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3 ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120 ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819 ike 0:dc0dbd1bca3396f4/0000000000000000:410: VID unknown (16): E3A5966A76379FE707228231E5CE8652 ike 0:dc0dbd1bca3396f4/0000000000000000:410: my proposal, gw IOS_VPN: ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 1: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=MD5. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY_XAUTH_I. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP1024. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=86400 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 1: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=MD5. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP1024. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=86400 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 1: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY_XAUTH_I. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP1024. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=86400 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 1: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP1024. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=86400 ike 0:dc0dbd1bca3396f4/0000000000000000:410: incoming proposal: ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 0: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=ECP384. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=28800 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 0: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=ECP256. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=28800 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 0: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=AES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP2048. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=28800 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 0: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP2048. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=28800 ike 0:dc0dbd1bca3396f4/0000000000000000:410: proposal id = 0: ike 0:dc0dbd1bca3396f4/0000000000000000:410: protocol id = ISAKMP: ike 0:dc0dbd1bca3396f4/0000000000000000:410: trans_id = KEY_IKE. ike 0:dc0dbd1bca3396f4/0000000000000000:410: encapsulation = IKE/none ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_HASH_ALG, val=SHA. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=AUTH_METHOD, val=PRESHARED_KEY. ike 0:dc0dbd1bca3396f4/0000000000000000:410: type=OAKLEY_GROUP, val=MODP1024. ike 0:dc0dbd1bca3396f4/0000000000000000:410: ISAKMP SA lifetime=28800 ike 0:dc0dbd1bca3396f4/0000000000000000:410: negotiation failure [size="1"]ike Negotiate ISAKMP SA Error: ike 0:dc0dbd1bca3396f4/0000000000000000:410: no SA proposal chosen

[/size]

I don't know why it chooses "my proposal, gw IOS_VPN".

[size="2"]"IOS_VPN" is created on FG by Tunnel template "Dialup - iOS (Native)" (description=On-demand tunnel for iPhone/iPad users using the native iOS IPsec client.) [/size]

My phone is a Lumia930 Windows Phone 8.1 !

Help.

[Christopher_McMullan]

The FortiGate received a Main Mode message instead of an Aggressive Mode message, which would have contained the local ID that was mentioned earlier. This local ID is required to differentiate between the dial-up tunnels, so that the right VPN Phase 1 profile is associated with the client connection.

Change the Windows host settings to use aggressive mode and specify the local ID, then it should work, all other things being equal.

[AndreaSoliva]

Hi

sorry was on Bank Holiday....and yep absolutly right! If you have problems with VPN and you debug with your command go through each line and diff to your configured phase1 and 2 (if 2 comes up :) ) it must be absolutly equal to that what you configured. In your case this line does not match your phase 1:

ike 0:dc0dbd1bca3396f4/0000000000000000:410: responder: main mode get 1st message...

hope this helps....have fun

Andrea

[mazu74]

In the FG, i have 2 tunnels : - First for IPhone. Create with template "Dialup - iOS (Native)". Agresive Mode - Second for my Windows computers. Create with "Custom VPN Tunnel (No Template)". On clients, i use Forticlient. Agresive Mode I can't put agresssive mode and local ID on my Windows Phone device. There is no option like in Forticlient. Forticlient exist for Android and Iphone but not for Windows Phone. I must create another tunnel with "Main Mode" ?