Interoperating with Microsoft Windows and Apple Mac OS X

The L2TP Openswan Server

For Mac OS X and some PocketPC versions, only L2TP with PSK is currently working properly. However, it is possible to have both L2TP with PSK and L2TP with X.509 configurations on the Openswan VPN server, so clients that support X.509 can use it, while clients that do not support it can connect using PSK.

Configuring Openswan for L2TP/IPsec

We need to create a connection that is used solely for securely transporting L2TP packets from the client to the VPN server. Some people get confused here and try to configure a leftsubnet= on the Openswan server, because they want access to that subnet, but this is wrong. The l2tpd daemon and the pppd daemon handle the assignment of the virtual IP address to the client. This virtual IP is already part of the subnet at the server side. The only thing we are setting up is a host- to-host tunnel that will be used like a PPP connection. Your ipsec.conf would look like this:

version 2 config setup

#klipsdebug=none

#plutodebug="control parsing" nat_traversal=yes

virtual_private=%v4:192.168.0.0/16,%v4:!192.168.1.0/24,%v4:10.0.0.0/8

include /etc/ipsec.d/examples/no_oe.conf

conn west-l2tp-psk left=193.110.157.131 leftnexthop=193.110.157.158 leftprotoport=17/1701 rightprotoport=17/%any rightsubnet=vhost:%priv,%no right=%any

auto=add

authby=secret

pfs=no

# type=transport

conn west-l2tp-x509 left=193.110.157.131 leftnexthop=193.110.157.158 leftprotoport=17/1701 leftrsasigkey=%cert leftcert=aivd.xelerance.com.pem rightprotoport=17/%any rightsubnet=vhost:%priv,%no right=%any

rightrsasigkey=%cert

auto=add

authby=rsasig

pfs=no

#type=transport

#rightca=%same

Note that even though we are configuring a transport-mode tunnel, and so should specify type=transport, this currently does not work in combination with the rightsubnet= statement we need for NAT-Traversal. However, leaving out type=transport will work as a transport mode connection is still requested and granted to the incoming client connection. As of Openswan-2.4.5, when this bug was fixed, one should enable the proper option specifying transport mode, which is the reason we left it in our configuration file as a comment. Updated l2tpd configuration examples are located in /etc/ipsec.d/examples/ as of openswan-2.4.5

160

Chapter 8

Most clients do not support PFS, so this is disabled using pfs=no. However, Openswan will ignore this option if the incoming client suggests PFS anyway, since there is no reason to decline this added benefit. Using the option pfs=no therefore allows us to support all clients, irrespective of whether they support PFS.

Further note how we are using rightprotoport=17/%any. This will allow all UDP packets to be transported through the IPsec connection. Ideally, this could be limited to UDP port 1701. Unfortunately, unpatched Windows XP machines propose a rightproto=17/0 and some other implementations use a random high source port to connect to the L2TP daemon instead of port 1701. The configuration we used, though more liberal, will work for all clients. If you are using a dedicated VPN server, that runs no other UDP based services, this should not matter, as the IPsec transport mode connection is only allowed to connect to the VPN server itself, and not to other servers running UDP services. That is only allowed through the L2TP packets.

There is currently a problem with having both an L2TP-PSK and a L2TP-X509 based connection at the same time. A workaround is described at http://bugs.xelerance.com/ view.php?id=348 but it is not pretty. If you can avoid using PSK altogether that would be best. Another possible approach would be to use two different public IP addresses on the same server or to use two different VPN servers.

If using PSK, we need to add an entry for our PSK. If we are using X.509, we need an entry for our RSA private key, including password if it is still locked. In our examples we are using aivd.xelerance.com (193.110.157.131). This is configured in /etc/ipsec.secrets:

193.110.157.131 %any: PSK "TheSecretIsSquemischOssifrage" : RSA /etc/ipsec.d/private/aivd.xelerance.com.key "foobar"

You might have noticed another commented-out option: rightca=%same. This option should be enabled when you have clients that need to connect to multiple Openswan servers that have different CAs. The reason we do not add it by default is that some setups could involve intermediate CAs.

Linux Kernel Runtime Parameters for L2TP/IPsec

Since the Linux VPN server will be forwarding packets (between an ethX and a pppX interface), you must make sure ip_forwarding is enabled. You should also disable the inbuilt anti-spoof filters. Disabling various ICMP redirection packets is also recommended, especially on the 2.6 kernel, to prevent the kernel sending redirects for packets that come from and go to the same interface, something that usually happens when using NETKEY. These can be configured in

/etc/sysctl.conf:

net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.icmp_ignore_bogus_error_responses = 1 net.ipv4.conf.all.log_martians = 0

161

Interoperating with Microsoft Windows and Apple Mac OS X

Alternatively, you can use one of the rc scripts, such as rc.local, to set up these options by adding the following commands:

echo "1 " > /proc/sys/net/ipv4/ip_forward

echo "0 " > /proc/sys/net/ipv4/conf/default/rp_filter echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects = 0

echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo "0" > /proc/sys/net/ipv4/conf/all/log_martians

You do not need to configure any proxyarp setting, since the pppd daemon will that that for you.

Protecting the L2TP Daemon with IPsec using iptables

L2TP could in theory be used without IPsec. It is therefore recommended to make the L2TP server only available through an IPsec connection, to prevent L2TP connections being established without IPsec, and to add some additional security. Only clients who are able to establish an IPsec connection are then able to negotiate anything with the L2TP server. If there are any specific L2TP problems, either in the software or the protocol, they should be unreachable for any remote attacker that has no valid IPsec credentials. This can be accomplished on a single VPN server by binding IPsec to the external interface and binding L2TP to the internal interface, and then only forwarding packets that have arrived through an IPsec connection from the external IPsec interface to the internal L2TP interface.

First we need to limit the accessibility of the L2TP daemon from the outside for non-IPsec hosts. This can be done by ensuring the L2TP daemon listens only on the internal IP address using a listen-addr option, and using an iptables rule to NAT the traffic from the public IP address to the private IP address, if it has been determined that the packet came in through IPsec. Remember we cannot access the internal IP address until after we have a working L2TP connection that will give the client its internal IP address.

If KLIPS is being used, it is easy to distinguish those packets and use an iptables rule:

iptables -t nat --append PREROUTING -i ipsec0 -p udp --dport 1701 -j DNAT -- to-destination 192.168.1.98

iptables -i eth0 -p udp –-dport 1701 -j DROP

With NETKEY, the rule is a bit more complex, but you can mark the IPsec packets before they are decapsulated. The mark actually survives this process, so any plaintext packet with a mark on it originally came in through an IPsec tunnel:

#iptables -t mangle -A PREROUTING -i eth0 -p esp -j MARK --set-mark 1

#iptables -A INPUT -i eth0 -m mark --mark 1 -j ACCEPT

#iptables -A INPUT -i eth0 -p udp –-dport 1701 -j DROP

You could also dynamically add and remove these firewall rules in a custom _updown script, which can be configured for the Openswan L2TP connection using leftupdown=/path/to/your/script.

It might make more sense to first perform a standard setup, with the L2TP daemon listening on all interfaces, so you do not need complex firewall rules. Once the IPsec/L2TP combination works, you can secure the L2TP daemon as described above.

Remember that you will also need to allow IKE traffic on port UDP 500 and 4500, L2TP traffic on UDP port 1701, and ESP packets. The rules will be slightly different for KLIPS or NETKEY because the incoming interface is different, but should look roughly like:

162