[L2tpd-devel] Re: L2TP/IPSEC

[Eric S. <er...@tr...>]

On Mon, 10 Dec 2001 ho...@ei... wrote:

> Seems to have problems here. I would appreciate if anyone who has set up a similar
> or same scenario to point me in the right direction or provide me with more information
> on howto set it up if available. My first aim is to get the scenario working without
> IPSec and then with it

Your configuration may be leading into ground that the l2tpd code has not
tread yet. This is the "compulsory tunneling" model, and it seems like you
might be expecting LAC-side l2tpd to do proxy authentication (i.e. forward
ppp auth info to the LNS-side l2tpd for LCP/IPCP negotiation. Also, check
your /etc/ppp/options file on both ends to make sure there's no 'noauth'
keyword lurking around somewhere.

By the way.. Although the following is not a direct answer to your question,
I have seen a couple of other posts in the archives asking along these lines
so maybe it will help someone.

With some effort, I have been able to use Freeswan+L2TPD to mimic the
the Win2K / WinXP builting VPN client. The LNS in my case is a
Lucent/Xedia Access Point 450 router, not another freeswan box. Here
are a few gotchas I ran into:

- I patched freeswan to use x509 certs and used an internal-only "standalone"
CA to assign a certificate for the linux box. Freeswan<->freeswan you can
probably just use rsasigs or PSK and be OK.
- the connection you want to L2TP over needs to specify 'type=transport'
in ipsec.conf
- freeswan _updown doesn't handle transport mode connections very well,
and will try to add a route to the eth0 network thru the
ipsec0 interface, which is not what you want. you want a host route to
the other tunnel endpoint through ipsec0.
- pppd will try to add a route to the LNS' IP address through the ppp0
interface, which is also not what you want. you want a route to the
remote network (behind the far gateway) through ppp0.

/etc/init.d/ipsec start
/usr/local/sbin/ipsec auto --up xedia-to-mobile-linux-l2tp
/sbin/route del -net <local-public-network> dev ipsec0
/sbin/route add -host <remote ip> dev ipsec0

/usr/local/sbin/l2tpd > /dev/null 2>&1 &
echo "c work" > /var/run/l2tp-control
/sbin/route del -host <remote ip> dev ppp0
/sbin/route add -net <tunneled-private-net> dev ppp0


- freeswan will not behave *exactly* like the win2k client as far as the
remote end is concerned; there's no way to specify 'any/any->udp/1701'
in the ike p2 exchange, as win2k does. i had to make a new security policy
for the transport-mode freeswan connections which says allows any port/any
protocol for both the local and remote endpoints.

in xedia-land it looks like this:

          IPSEC TRANSPORT-INTERFACE.0.0.0.0 TRANSPORT.FREESWAN SUMMARY

                     Type* = clientGroup
                     Mode* = up
                    State  = up
        Last State Change  = 676 (0 hours 0 min 6 secs)
              Remote Addr  = 0.0.0.0
                 Protocol* = 0
               Local Port* = 0
              Remote Port* = 0
         Security Profile* = freeswan
IKE Authentication Method  = none
               Row Status* = active


                    IPSEC SECURITY-PROFILE.FREESWAN SUMMARY

          Protocol* = esp   Inactivity Timer* = 0
        Encryption* = des3        Enable PFS* = true
    Authentication* = md5       Oakley Group* = second
       Compression* = null Assignment Status  = assigned
  Expiration Timer* = 3600        Row Status* = active
 Expiration Volume* = 0


which matches up to an ipsec.conf entry with:

conn xedia-to-mobile-linux-l2tp
	left=<remote ip>
	leftrsasigkey=0x<longstring>
	right=%defaultroute
	rightcert=mycert.cer
        type=transport
        ikelifetime=8h
        keylife=1h
        pfs=yes
        auto=add

- I had to hardcode the username/password into /etc/ppp/pap-secrets
which is sort of sub-optimal. I'd rather l2tpd force the user to
type his/her password instead of keeping it on disk, but I understand
this is difficult to do cleanly since its running as a daemon

/etc/l2tp/l2tpd.conf
[lac work]
lns = <remote ip>
refuse pap = no                         ; * Refuse PAP authentication
refuse chap = yes                       ; * Refuse CHAP authentication
;refuse authentication = no             ; * Refuse authentication altogether
require authentication = no             ; * Require peer to authenticate
name = <radius-username>         ; * Report this as our hostname

/etc/ppp/pap-secrets
<radius-username> * <radius-password> *

- There is a bug with ESP fragment handling in the Freeswan version I used
(1.92) so any large packets which resulted in ESP frags (gateway->linux)
got dropped instead of reassembled.  I hear this (is|will be) fixed in 1.94.

I was pretty suprised when the tunnel came up, but it does indeed work.

-=Eric