Bug report: L2TP does not require IPsec

[luoqi]

Recently I reconfigured my home network and I forgot to update my IPsec policy configuration, as a result my home vpn server was not negotiating any IPsec SA with the Foritgate vpn/router at work, but to my surprise they were able to successfully establish a VPN tunnel, an unencrypted/unprotected one. Granted it was a mistake on the other end, but allowing an unencrypted L2TP to establish is a security hole for a commercial (security appliance) product like Fortigate. It should be a straightforward fix by *requiring* IPsec for all traffic to/from port 1701.

[MikePruett]

That's not really a flaw I think.

As there are different types of tunnels that encrypt either just the header or the header and the payload. Sounds like it is using the former right now.

[luoqi]

We are not talking all different types of tunnels here, we're specifically talking about L2TP/IPsec as defined in rfc3193. So yes, I'm pretty sure it is a bug, and worse still a security risk.

[emnoc]

No it not a bug, you have a L2TP tunnel and L2TP over Ipsec, you enable a  L2TP tunnel that relies on tcp  1701 and sometimes 1702. This is not a bug just misunderstanding of what you did.

The difference in the fortiOS  cfg are major items are;

config vpn l2tp

and

config vpn ipsec-phase1 

    and change the mode from tunnel to transport

Can you post the cfg of whatever you did ? and show us the cli output of   get vpn l2tp  ?

Ken

[luoqi]

Well, I didn't say it's a bug in the l2tp implementation, it is a bug in the configuration that binds the l2tp and ipsec together into a l2tp/ipsec vpn service, much the same as I misconfigured my home server for not updating the ipsec policies. I cobbled up a l2tp/ipsec vpn solution at home with open source components, were I to integrate them together and offer as a product, I'd regard it as a bug, for I failed to ensure the consistency of configurations between components of my product, especially if I offer an easy-to-use webui to configure the solution as a whole. So much for the semantics of whether it should be called a bug, let's not dwell on it.

I created the l2tp/ipsec vpn configuration using the webui. Here are the relevant sections from the configuration file dump,

config vpn l2tp   set eip 10.201.22.200   set sip 10.201.22.1   set status enable   set usrgrp "Radius" end

config vpn ipsec phase1   edit "L2TP_wan1"     set type dynamic     set interface "wan1"     set proposal aes256-md5 aes256-sha256 aes256-sha1 3des-md5 3des-sha256 3des-sha1     set add-route enable     set dhgrp 2

  next

config vpn ipsec phase2   edit "L2TP_wan1"     set phase1name "L2TP_wan1"     set proposal aes256-md5 aes256-sha256 aes256-sha1 3des-md5 3des-sha256 3des-sha1     set pfs disable     set encapsulation transport-mode   next

config firewall policy

  edit 10     set srcintf "internal"     set dstintf "wan1"     set srcaddr "all"     set dstaddr "all"     set action ipsec     set schedule "always"     set service "ALL"     set inbound enable     set vpntunnel "L2TP_wan1"   next

I believe only the last "firewall policy" part is relevant, it looks like fortiOS's equivalent of an SPD, I can see a couple of potential issues (but can't be sure as I'm unfamiliar with fortisOS's ipsec implementation):

[ol]

SA negotiations are unidirectional, shouldn't there be two rules, one for outbound and one for inbound?

Even with the single outbound (internal->wan1) rule, why was there no SA negotiated for this direction? Is there a keyword to make ipsec mandatory?

Nowhere to be found is the port 1701. It is not hardcoded in fortiOS, is it?[/ol]