mpd as LAC using radius to define LNS

Help
2012-10-26
2013-03-27
  • I've been successfully using mpd to terminate L2TP (PPPoE) tunnels. I now have another application where I'd actually like to be able to use it as a LAC as well.

    I've got most of it working - if I explicitly define the l2tp peer as an arbitrary LNS it works - it hands off the tunnel to the LNS correctly, though unauthenticated at the LAC level.

    I need to extend that so that the LAC is querying a Radius (freeradius) server to get the tunnel endpoints and tunnel secrets to support failover, amongst other things.

    I've gotten close to sorting it out myself, but I need a little assistance with the last bit. As I have it now, I can see the radius request coming from the LAC and an access-accept gets sent back. The radius reply is:

    Sending Access-Request of id 190 to X.X.97.34 port 1812
            User-Name = "test@domain"
            User-Password = "password"
            NAS-IP-Address = X.X.97.34
            NAS-Port = 1812
            Message-Authenticator = 0x00000000000000000000000000000000
    rad_recv: Access-Accept packet from host X.X.97.34 port 1812, id=190, length=122
            Framed-IP-Address = X.X.88.88
            Framed-Protocol = PPP
            Framed-MTU = 1454
            Service-Type = Framed-User
            Session-Timeout = 604800
            Idle-Timeout = 86400
            Tunnel-Medium-Type:0 = IPv4
            Tunnel-Type:0 = L2TP
            Tunnel-Server-Endpoint:0 = "X.X.209.35"
            Tunnel-Password:0 = "tunnelsecret"
            mpd-action = "forward L2"

    The mpd.conf from the LAC:

    default:

            create link template L1 pppoe
            set pppoe iface em0
            set link enable incoming

            load radius
            set link action bundle B1

            set link disable eap
            set link enable pap
            set link disable acfcomp
            set link disable protocomp
            set link disable check-magic
            set link deny acfcomp
            set link keep-alive 10 60
            set link deny protocomp
            set link mtu 1492
            set link mru 1492
            set link disable peer-as-calling
            set link enable multilink

            create link template L2 l2tp

    radius:
            set radius server X.X.97.34 sharedsecret 1812 1813
            set auth enable radius-auth
            set auth enable radius-acct
            set auth acct-update 7200

    I'm sure it's something thoroughly obvious I am missing so any assistance would be appreciated. This mailing list post (http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029659.html) was what suggested I change the link action and add the AV pair to the Radius reply.

    Thanks!

     
  • Unfortunately MPD doesn't support Tunnel-* attributes in auth response now. All required tunnels (or templates) should be configured beforehand. You can't pass peer IP or secret with auth response. But MPD allows RADIUS server to specify which tunnel (or template) to use with attribute like mpd-action = "forward L2". So load balancing is still possible.

     
  • Okay - so if I am understanding that properly I'd actually need to define more than one template setup (i.e. the 'default' one above) and staticaly specify the destination IP and secret? And then Radius would need to reply with which link to use?

    That would imply then that you can load balance (i.e. have some users on one LNS, and others on another) but not that you could have any failover, correct?

    Do you have any configuration examples of this type of setup so I can compare to my own and see what I'm missing?

    Thanks again for your quick response.

     
  • You don't need to duplicate all 'default' section, only outgoing link creation/configuration:
        create link template L2 l2tp
        set l2tp peer 1.2.3.4
        create link template L3 l2tp
        set l2tp peer 1.2.3.5
        create link template L4 l2tp
        set l2tp peer 1.2.3.6
        …

    It is only depends on your RADIUS server how to generate mpd-action attribute. If you configure it per-user - it will be per-user. If you configure some module to do it dynamically - you may get any imaginable distribution algorithm. In my practice I've mostly used custom FreeRADIUS modules that allowed me to implement any logic I needed.

     
  • My mpd.conf config above (with a single link template definition) looks generally correct, though?

    When I modify it slightly to include:

            set link action bundle B1

            create link template L2 l2tp
            set l2tp peer X.X.209.35
            set l2tp secret password

    and return mpd-action := forward L2 from radius the tunnel doesn't come up so I must be missing something at that level as well.

    My apologies for my lack of knowledge in this area - i've had minimal exposure to L2TP up to this point so it's been a bit of a learning process.

     
  • It it difficult to say something without any information. Start reading MPD logs. There should be all information to diagnose the problem.

     
  • I've been trying to isolate the problem. It's definitely a configuration issue of my own making as I'm trying to cobble together multiple different examples.

    Oct 29 12:32:36 testlac ppp:  Link: No actions defined
    Oct 29 12:32:36 testlac ppp:  No bundle specified
    Oct 29 12:32:36 testlac ppp:  link did not validate in bundle

    my mpd.conf:

    default:
            create bundle template B1
            set iface idle 1800
            set iface enable tcpmssfix
            set ipcp disable vjcomp
            set ipcp deny vjcomp

            create link template L1 pppoe
            set pppoe iface em0
            set link enable incoming

            load radius

            set link disable eap
            set link enable pap
            set link disable acfcomp
            set link disable protocomp
            set link disable check-magic
            set link deny acfcomp
            set link keep-alive 10 60
            set link deny protocomp
            set link mtu 1492
            set link mru 1492
            set link disable peer-as-calling
            set link enable multilink

            create link template L2 l2tp
            set link action bundle B1
            set l2tp peer X.X.209.35
            set l2tp secret secretkey

            create link template L3 l2tp
            set link action bundle B1
            set l2tp peer X.X.209.36
            set l2tp secret secretkey

    radius:
            set radius server X.X.97.34 password 1812 1813
            set auth enable radius-auth
            set auth enable radius-acct
            set auth acct-update 7200

    I'm definitely specifying something wrong in the bundle and/or link creation.

     
  • You should specify 'link action bundle B1' for incoming link, not for outgoings. Otherwise MPD does not know what to do with the connection. Specifying it for incoming connection will make MPD to run authorization process and send request to the RADIUS, where it will get real action (outgoing link).

     
  • Ah-hah! That gets me closer. If I don't return an mpd-action with the radius reply, it terminates the tunnel locally. If I do return a 'forward L2' or 'forward L3' then I error.

    It looks like the problem is that when the LAC queries radius, it gets the mpd-action response and passes it on to the LNS (another mpd instance). The LNS queries radius as well, and then it sees the 'forward L2' response for mpd-action and as there is no such definition it errors from that side.

    Any obvious workarounds I am missing, or for this to work would I need to be returning different radius responses to the LAC and LNS to ensure no conflicts?

     
  • There is no workaround on the MPD side. RADIUS should not send mpd-action to LNS, otherwise also it will try to work as LAC. If I am not mixing, in FreeRADIUS it is possible to configure attribute filters to remove unwanted attributes. And those filers could be applied to specific NASes (NAS types).

     
  • Great! Thanks so much for your help. I think you've got me pointed down the right path.