L2TP Daemon + Firewall

[adriand]

Just curious: how do you prevent from the CLI with firewall rules users from establishing L2TP tunnels in clear ?
If I set up a local firewall instance of the WAN interface and I do not allow UDP port 1701, just UDP ports 500 and 4500, the L2TP tunnel cannot be initiated(IKE MM and QM are OK).
If I allow UDP port 1701 too, I can easily establish in clear (without ipsec protection) an L2TP tunnel.
Thanks,
Adrian

[ancheng]

adriand wrote:

[adriand]

hmmmm...
maybe.
But my question was: from the CLI.
So the answer is: you cannot.
This is a security issue.
Knock, knock, this *should* not happen by default...
Where is written in the config guide that this happens ?
To make people aware of this fact.
And post the workaround.
If someone enables the L2TP/IPsec VPN remote access server on Vyatta and if he/she goes and configures the firewall rules from the CLI, is exposed by default to a security issue which is not advertised anywhere in your configuration guide (correct me if I'm wrong).
Maybe this was acknowledged on Jacco's site, but not in your config docs, where people would look, because that's the goal, to configure things from the CLI.
Besides, not all the people are familiar with what's under the hood, Openswan and how to fix something that they are not aware of through iptables ...
They would say, L2TP/IPsec uses this and this, thus I will allow all these in my local firewall instance ...
And then, hey dude I got p0wned!
Adrian

[ancheng]

You are right that this is a security risk that should be documented so that a user can make an informed decision as to what solution is best for his/her environment. Similarly, the risks of using "pre-shared-key", using "local" authentication, or using PPTP should also be documented. However, currently for Glendale we only have the command reference documentation, which only discusses the basic command usage. We'll make sure these are covered in the configuration guide when we publish it.

Also, in the next release, we plan to extend the firewall capability so that a user can define such a firewall rule to minimize this particular risk. Or better yet, we could automatically add such a rule when L2TP is configured. So please stay tuned!

[adriand]

I will stay tuned.
Coming back to the command reference: the truth is that when you use the "vpn l2tp" command to create the configuration node for "Layer 2 Tunneling Protocol (L2TP) Virtual Private Network (VPN) functionality.", in fact you configure L2TP/IPsec(=VPN) and also you will end up with naked L2TP(=VN).
Thus two things are obtain: VPN remote access functionality and VN remote access functionality.
And this can be a bigger security issue than using pre-shared keys or PPTP.

As Paul Hoffman himself said in the past:
http://www.networkworld.com/archive/1999/1122works.html

[ancheng]

adriand wrote:

[adriand]

I do understand what you are saying, but what I am saying it's not quit the same thing.
What I'm saying is: what's happening when an attacker manages to "interconnect" the VPN with the VN ?
If I play a little game: connect with L2TP/IPsec from one host, and then create a naked L2TP tunnel from the "same" host (spoofed), my clear data packets are replied with ESP packets. The control channel of the naked L2TP tunnel is in clear. If I terminate the naked L2TP tunnel this does not affect the L2TP/IPsec connection.
Now what's happening if I inject an L2TP packet in clear with the "correct" tunnel and session ids ?

http://www.ietf.org/rfc/rfc3193.txt

[ancheng]

adriand wrote:

[Talkincat]

For anyone who stumbles upon this from google as I did, there is a documented solution for this issue in VC5. In the VPN reference (http://www.vyatta.com/downloads/documentation/VC5.0.2/Vyatta_VPNRef_VC5_v03.pdf) on pages 7 and 8 (pdf pages 24-25) there is a detailed explanation of the issue as well as a firewall statement example.

rule 10 {
action accept
destination {
port 1701
}
ipsec {
match-ipsec
}
protocol udp
}