Hi,

This is a long story, the 2 little questions, one regarding a clarifictaion I'd 
like to 
have, and another followup question are at the end.

my final goal is to connect mobile phones via IPSec/L2TP to OpenBSD vpn servers.
Since I don't have a capable smart phone around, I thought about trying it with 
a Linux client first. On the linux client I use strongswan-4.4.0-4.1.1, and 
xl2tpd-1.2.4-2.7

I try to follow the instructions in the 
/usr/src/usr.sbin/npppd/HOWTO_PIPEX_NPPPD.txt

This is my npppd.conf:
$ grep -v "^#" /etc/npppd/npppd.conf                                            
                                                                                
                                                                                
              
interface_list:                         tun0
interface.tun0.ip4addr:                 10.66.66.1
pool.dyna_pool:                         10.66.66.0/25
pool.pool:                              10.66.66.128/25
auth.local.realm_list:                  local
auth.local.realm.acctlist:              /etc/npppd/npppd-users.csv
realm.local.concentrate:                tun0
lcp.mru:                                1400
auth.method:                            mschapv2 chap
pptpd.enabled:                          true
pptpd.ip4_allow:                        0.0.0.0/0
l2tpd.enabled:                          true
l2tpd.ip4_allow:                        0.0.0.0/0
l2tpd.require_ipsec:                    false

and my npppd-users.csv:
Username,Password,Framed-IP-Address,Framed-IP-Netmask,Description,Calling-Id
user1,top-secret-password-for-user1,10.66.66.129,,memo for user1

So first I tried "normal" pptp, on the client side, for that, I loosely 
followed this howto:
http://www.cyberciti.biz/tips/howto-configure-ubuntu-fedora-linux-pptp-client.html

so I have this in my /etc/ppp/chap-secrets file:
user1 PPTP top-secret-password-for-user1 *

and this in my /etc/ppp/peers/blah file:
pty "pptp 10.0.0.81 --nolaunchpppd"
name user1
remotename PPTP
require-mppe-128
file /etc/ppp/options.pptp
ipparam delhi-idc-01

and this is my /etc/ppp/options.pptp:
sre:~ # cat /etc/ppp/options.pptp 
#
# Lock the port
#
lock
#
# We don't need the tunnel server to authenticate itself
#
noauth
#
# Turn off transmission protocols we know won't be used
#
nobsdcomp
nodeflate
#
# We want MPPE
#
require-mppe
#
# We want a sane mtu/mru
#
mtu 1000
mru 1000
#
# Time this thing out of it goes poof
#
lcp-echo-failure 10
lcp-echo-interval 10

Now starting the client to connect to the server:

on the client side, it looks like this:
Using interface ppp0
Connect: ppp0 <--> /dev/pts/10
CHAP authentication succeeded
MPPE 128-bit stateless compression enabled
local  IP address 10.66.66.129
remote IP address 10.66.66.1
Script /etc/ppp/ip-up finished (pid 14576), status = 0x0

and on the server I get the following output from npppd:
2012-01-17 09:42:16:INFO: pptpd ctrl=0 Starting peer=10.0.0.31:43050/tcp 
sock=10.0.0.81:1723/tcp
2012-01-17 09:42:16:INFO: pptpd ctrl=0 RecvSCCRQ protocol_version=1.0 
framing=async,sync bearer=analog,digital max_channels=65535 
firmware_revision=1(0x0001) host_name="local" vendor_string="cananian"
2012-01-17 09:42:16:INFO: pptpd ctrl=0 SendSCCRP protocol_version=1.0 result=1 
error=0 framing=sync bearer=digital max_channels=4 
firmware_revision=1282(0x0502) host_name="" vendor_string=""
2012-01-17 09:42:17:INFO: pptpd ctrl=0 call=0 RecvOCRQ call_id=0 
call_serial_number=0 max_bps=2400 min_bps=10000000 bearer=analog,digital 
framing=async,sync recv_winsz=3 packet_proccessing_delay=0 phone_nunmber= 
subaddress=
2012-01-17 09:42:17:INFO: pptpd ctrl=0 call=48978 SendOCRP call_id=48978 
peers_call_id=0 result=1 error=0 cause=0 conn_speed=10000000 recv_winsz=64 
packet_proccessing_delay=0 physical_channel_id=48978
2012-01-17 09:42:17:NOTICE: pptpd ctrl=0 call=48978 logtype=PPPBind ppp=0
2012-01-17 09:42:17:INFO: ppp id=0 layer=base logtype=Started 
tunnel=PPTP(10.0.0.31:43050)
2012-01-17 09:42:17:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1000 
auth=MS-CHAP-V2 magic=62d614bb/5a299c53
2012-01-17 09:42:17:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success 
username="user1" realm=local
2012-01-17 09:42:17:INFO: ppp id=0 layer=mppe mismatch our=128bit,stateless 
peer=40bit,128bit,stateless
2012-01-17 09:42:17:INFO: ppp id=0 layer=mppe logtype=Opened 
our=128bit,stateless peer=128bit,stateless
2012-01-17 09:42:17:DEBUG: ppp id=0 layer=ipcp Unhandled Option 02 6
2012-01-17 09:42:17:INFO: ppp id=0 layer=ipcp IP Address peer=0.0.0.0 
our=10.66.66.129.
2012-01-17 09:42:20:INFO: ppp id=0 layer=ipcp logtype=Opened ip=10.66.66.129 
assignType=static
2012-01-17 09:42:20:NOTICE: ppp id=0 layer=base logtype=TUNNELSTART 
user="user1" duration=3sec layer2=PPTP layer2from=10.0.0.31:43050 
auth=MS-CHAP-V2  ip=10.66.66.129 iface=tun0
2012-01-17 09:42:20:NOTICE: ppp id=0 layer=base Using pipex=yes


So far,so good, this all works.

Then I did setup ipsec on the server loosely following the 
HOWTO_PIPEX_NPPPD.txt: 
ike passive esp transport \
         proto udp from 10.0.0.81 to any port 1701 \
         main auth "hmac-sha" enc "3des" group modp1536 \
         quick auth "hmac-sha" enc "aes" \
         psk "secret"

started up isakmpd and ran ipsecctl

On the client side I use strongswan, loosely following this howto:
 http://www.jacco2.dds.nl/networking/linux-l2tp.html
the /etc/ipsec.conf looks like this:
conn L2TP-PSK-CLIENT
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=transport
        left=%defaultroute
        leftprotoport=17/1701
        right=10.0.0.81
        rightprotoport=17/1701
        auto=add

And in the /etc/ipsec.secrets I have: 
10.0.0.81 10.0.0.31 : PSK "secret"

I startup strongswan, and then initiate the connection, and it successfully 
establishes the IPSec connection, afterwards I can check on the OpenBSD server:

$ netstat -rn -f encap
Routing tables

Encap:
Source             Port  Destination        Port  Proto 
SA(Address/Proto/Type/Direction)
10.0.0.31/32       1701  10.0.0.81/32       1701  17    10.0.0.31/esp/use/in
10.0.0.81/32       1701  10.0.0.31/32       1701  17    
10.0.0.31/esp/require/out


So far, still all good, now the trouble starts, when it comes to start the l2tp 
connection.
I use xl2tp package for Linux.

in my /etc/xl2tp/xl2tp.conf I have:
[global]
debug avp = yes

[lac L2TPserver]
lns = 10.0.0.81
require chap = yes
refuse pap = yes
require authentication = yes
; Name should be the same as the username in the PPP authentication!
name = user1
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = no

and in my /etc/ppp/chap-secrets file I have:
* * top-secret-password-for-user1 *


Starting nppd on OpenBSD, and then starting xl2tpd on the Linux client, and 
initiating the connection 
I see the following in the logs of the server:

2012-01-16 16:23:33:INFO: l2tpd ctrl=5 SendSCCRP
2012-01-16 16:23:33:INFO: l2tpd ctrl=5 RecvSCCN
2012-01-16 16:23:33:INFO: l2tpd ctrl=5 SendZLB
2012-01-16 16:23:33:INFO: l2tpd ctrl=5 call=1728 RecvICRQ session_id=11662
2012-01-16 16:23:33:INFO: l2tpd ctrl=5 call=1728 SendICRP session_id=1728
2012-01-16 16:23:33:WARNING: l2tpd ctrl=5 call=1728 AVP (RX_CONNECT_SPEED/38) 
is not supported, but it's mandatory
2012-01-16 16:23:33:INFO: l2tpd ctrl=5 call=1728 SendCDN result=ERROR_CODE/2 
error=UNKNOWN_MANDATORY_AVP/8 messsage=none

Digging the code, I came across RFC2661, I found here:
here it says for AVP type 38: 
This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this AVP MUST 
be set to 0. The
Length (before hiding) of this AVP is 10. 

So I guess the linux x2ltpd is on failure here?

Anyways, since I only have the sources of npppd around, I commented out the 
checking for the mandatory field to get past the error, so that npppd ignores 
the mandatory bit, trying again, it goes on:

2012-01-17 10:43:29:NOTICE: l2tpd ctrl=1 logtype=Started RecvSCCRQ 
from=10.0.0.31:1701/udp tunnel_id=1/49744 protocol=1.0 winsize=4 hostname=sre 
vendor=xelerance.com firm=0690
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 SendSCCRP
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 RecvSCCN
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 SendZLB
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 call=28017 RecvICRQ session_id=9332
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 call=28017 SendICRP session_id=28017
2012-01-17 10:43:29:WARNING: l2tpd ctrl=1 call=28017 AVP (RX_CONNECT_SPEED/38) 
is not supported, but it's mandatory
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 call=28017 RecvICCN session_id=9332 
calling_number= tx_conn_speed=10000000 framing=sync
2012-01-17 10:43:29:NOTICE: l2tpd ctrl=1 call=28017 logtype=PPPBind ppp=0
2012-01-17 10:43:29:INFO: ppp id=0 layer=base logtype=Started 
tunnel=L2TP(10.0.0.31:1701)
2012-01-17 10:43:29:INFO: l2tpd ctrl=1 call=28017 SendZLB
2012-01-17 10:43:29:INFO: ppp id=0 layer=lcp logtype=Opened mru=1400/1410 
auth=MS-CHAP-V2 magic=6ce37f1d/29a19697
2012-01-17 10:43:29:INFO: ppp id=0 layer=chap proto=mschap_v2 logtype=Success 
username="user1" realm=local
2012-01-17 10:43:29:DEBUG: ppp id=0 layer=ipcp Unhandled Option 02 6
2012-01-17 10:43:29:INFO: ppp id=0 layer=ipcp IP Address peer=0.0.0.0 
our=10.66.66.129.
2012-01-17 10:43:29:INFO: ppp id=0 layer=ccp CCP is stopped
2012-01-17 10:43:29:INFO: ppp id=0 layer=ipcp logtype=Opened ip=10.66.66.129 
assignType=static
2012-01-17 10:43:29:NOTICE: ppp id=0 layer=base logtype=TUNNELSTART 
user="user1" duration=0sec layer2=L2TP layer2from=10.0.0.31:1701 
auth=MS-CHAP-V2  ip=10.66.66.129 iface=tun0
2012-01-17 10:43:29:NOTICE: ppp id=0 layer=base Using pipex=yes


Finally the two questions I have:

I acutally just want a clarification whether I'm right with my understandings:
npppd doesn't implement AVP38, but reading the RFC, it seems, since its not 
mandatory, that should not be a problem.
xl2tpd is wrong, requiring AVP 38 as mandatory.

After the client got its IP address, it can access the VPN server via the 
tunnel.
But how to access hosts behind the tunnel endpoint?
I wonder how to tell the client about routes? Is the isakmpd responsible to set 
this up prior the L2TP authentication, and this has to be configured in the 
ipsec.conf? Or have routes to be pushed via npppd when it gives the IP to the 
client, like OpenVPN is doing it?
Or something else, i.e. the client must know what to access behind the VPN and 
setup routes on its own?

regards,
Sebastian

Reply via email to