IPsec VPN with SSL VPN

[jjensen]

We currently have a SSL VPN setup on our Fortigate 60D devices.  I've been tasked with getting some Chromebooks to VPN into our network.  I've been doing some reading and from what I can tell I need to implement IPsec VPN for the chromebooks.  I have a few questions

1) Can I use the same interface that our SSLVPN is using?

2) Can I use the same Object - Addresses.  (The IP Range that our SSLVPN is using?)

[ede_pfau]

Hi,

yes, SSL VPN and IPsec VPN are independent and use different protocols: HTTPS and ESP/UDP resp. As such, IPsec doesn't use a well known port as SSL VPN does.

Regarding client IP addresses:

if you expect that your clients will have distinct addresses (distinct from the internal FGT subnet and other clients' addresses) then you can even work with their private addresses. The moment they dial in the FGT will create a route back to their address space.

If you expect many clients to use the dial-in IPsec VPN though, then you better set up IPsec-DHCP with some private address range.Or you could even hand out statically pre-assigned addresses which you configure into the FortiClient IPsec config.

I would not recommend to use the same addresses as existing, just to be able to differentiate between user groups. In the policies just use address groups and put both ranges into an address group. But strictly speaking, I don't see any problem if you use the same address range for both kinds of VPN.

[jjensen]

OK.  I've hit a snag on a few things and was hoping somebody could enlighten me.  I'm testing the l2tp/ipsec connection internally first to verify that the settings are correct.  I'm getting some negotiation but then the connection stops and ends.

The picture shows the start of the negotiation.  I then get some more stuff... such as

sent IKE msg (agg_r1send) with info

sent IKE msg (P1_RETRANSMIT) with more stuff

sent IKE msg (P1_RETRANSMIT) with more stuff

negotiation timeout, deleting

connection expiring due to phase1 down

Is phase1 not negotiating thus it ends up timing out?

[ede_pfau]

You haven't told the whole truth...you're trying to implement "Windows" L2TP with IPsec, right?

Good news, that can be done.

Bad news, the FGT has to offer exactly the parameters Windows needs - no negotiations about phase1 params. IIRC the key life depends both on time and kilobytes.

This is documented somewhere on the 'net, and (maybe) in the KB.

forum:

http://support.fortinet.com/forum/fb.asp?m=83222

http://support.fortinet.com/forum/fb.asp?m=77124

KB:

"Technical Note : FortiOS v4.0 MR3 L2TP/IPSEC and Windows7 with PSK"

I will try to attach it (remove .txt extension).

[jjensen]

As i said earlier we're trying to get chromebook's to VPN in.  After I had setup the l2tp/ipsec VPN and it didn't work i contacted support.  They made some changes... The chromebook still wouldn't work.  So then support asked to try it on a windows OS.  That worked.   I had to leave for an appointment so we ended there.  This morning I noticed that the chromebook was failing on the authentication type which is when I changed it to aggressive.  So the output you see is in fact from a chromebook trying to VPN in.

[ede_pfau]

Sorry, I overlooked the Chrome part...no idea about Chrome OS (Chromium?).

[jjensen]

I have the VPN working for the most part.  So far I can only get a local account to work.  If I try to use a LDAP account It fails.  From what I can tell it makes it through to phase2.  I noticed i'm getting two different proposal id's... yet at the end it shows negotiation result proposal id = 0

So to me that would mean it was going OK.

[TedDMoncrief]

What settings did you use in setting up the VPN on the fortigate to get the local account working?  I'm running 5.4 and I'm having the same issue you described.  I can't seem to be able to get to the phase 2 piece of the tunnel.