Still problems with IOS9 and FR2.2.9

Mark Haselden levsky at gmail.com
Fri Oct 9 05:12:22 CEST 2015


Thanks for the headsup on that Alan,

What I'm not getting is how come this isn't converting to straight MSCHAPV2
in the inner server definition.  We have the eap directive in both
post-proxy and authenticate stanzas defined for the server
(perl-innertunnels is just a quick bit of perl to set the correct realm
based on username)

Our inner tunnel server looks like:

server ttls-proxy {
authorize {
        perl-innertunnels

        update control {
                Proxy-To-Realm := "%{II-Proxy-Realm}"
        }
}
authenticate {
        eap
}
post-auth {
        update outer.reply {
                User-Name := "%{request:User-Name}"
        }
}
post-proxy {
        eap

        perl-innertunnels
}
}

and the eap.conf like
        eap {
                default_eap_type = ttls
                timer_expire     = 60
                ignore_unknown_eap_types = no
                cisco_accounting_username_bug = no
                max_sessions = 4096
                md5 {
                }
                leap {
                }
                gtc {
                        auth_type = PAP
                }
                tls {
                        certdir = /etc/ssl/certs
                        cadir = /etc/ssl/certs
                        private_key_file = ${certdir}/radius_key.pem
                        certificate_file = ${certdir}/radius_crt.pem
                        dh_file = ${confdir}/certs/dh
                        random_file = /dev/urandom
                        CA_path = ${cadir}
                        cipher_list = "DEFAULT"
                        make_cert_command = "${certdir}/bootstrap"
                        ecdh_curve = "prime256v1"
                        cache {
                              enable = no
                              max_entries = 255
                        }
                        verify {
                        }
                        ocsp {
                              enable = no
                              override_cert_url = yes
                              url = "http://127.0.0.1/ocsp/"
                        }
                }
                ttls {
                        default_eap_type = md5
                        copy_request_to_tunnel = yes
                        proxy_tunneled_request_as_eap = no
                        use_tunneled_reply = yes
                        virtual_server = "ttls-proxy"
                }
                peap {
                        default_eap_type = mschapv2
                        copy_request_to_tunnel = yes
                        use_tunneled_reply = yes
                        proxy_tunneled_request_as_eap = no
                        virtual_server = "peap-proxy"
                }
                mschapv2 {
                        send_error = yes
                }
        }


But what gets proxied to the (radiator) home servers looks like
Code:       Access-Request
Identifier: 247
Authentic:
 <213><243><218><183><200><28><177><22>s<165><203><145><160><156><151><188>
Attributes:
    NAS-Port-Type = 19
    Service-Type = Framed
    Tunnel-Type = 13
    Called-Station-Id = "34dbfd24e9e0"
    NAS-IP-Address = 10.13.6.8
    Tunnel-Private-Group-ID = "151"
    Tunnel-Medium-Type = 6
    Calling-Station-Id = "f0f61c739670"
    cisco-avpair = "audit-session-id=0a19d7cb000541d3642e1756"
    User-Name = "levsky"
    NAS-Identifier = "wlc1.per3"
    EAP-Message = <2><0><0><11><1>levsky
    NAS-Port = 1
    Framed-MTU = 1300
    Signature = j<170><210>"Z<214>5<229>G}<31><250><225><189><219><22>
    Proxy-State = 148


On 8 October 2015 at 16:52, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > Like lots of people, we've been hit with the changes to TLS support in
> > IOS9.  I've upgraded to FR2.2.9 (we're a moderate sized ISP and can't
> > upgrade to 3.x in a hurry) but there's still little change to the matter.
>
> no.....theres no change - its not TLS 1.2 yet - they pulled back
>
> > Our configuration is an proxy configuration which forwards normal
> (non-EAP)
> > RADIUS to our customer facing radius platform.
> > The difference that we're seeing between an 8.x connection attempt (which
> > works fine) and a 9.x connection attempt is that we don't see the MSCHAP
> > attributes passed through in the request.
>
> correct...because thats the change - they now send EAP-MSCHAPv2 in the
> inner.
>
> alan
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html


More information about the Freeradius-Users mailing list