Win7 Supplicant Acting Weird (Unable to browse websites) q1 hr

  • I'm normally a pretty good troubleshooter, but I'm not sure exactly when this issue started happening, so it's hard to narrow it down to any "changes" made to my environment.

    Supplicant:  My Windows 7 Pro x64 laptop
    Authenticator:  Asus RT-N66U running in AP mode.  Latest firmware.
    Authentication Server:  pfSense 2.3.4-p1 amd64 running freeradius3 package 0.8

    WLAN Architecture:  WPA2-Enterprise (EAP-TLS)

    Symptoms:  I've had no problems with this setup since Fall 2016, but for the past several weeks or so, every hour (ish), my laptop will lose connectivity, but it won't show any outward signs other than web pages suddenly not working.  It still shows connected to my wireless network.

    [Edited to Add:  The 1 hour mark came and went, and I didn't lose connectivity this time.  I saw a new "radiusd" entry in the pfsense System Logs showing a successful authentication attempt by my laptop, via the AP.  I guess this issue is inconsistent.]

    Workaround:  Manually disconnect from my wireless network then reconnect.  Everything immediately works again.  pfSense System logs show a fresh authentication attempt to FreeRADIUS.

    Possible causes:

    • Something changed with the latest June or July Windows Updates?

    • Something changed in the latest Asus RT-N66U firmware updates?

    • Something changed going from the freeradius2 to freeradius3 package?

    • Hardware failure?  Overheating?

  • Since this seems to be happening every 1 hour (it may be a different interval), that's a clue to look for something in a config somewhere…

    In the freeradius3 config, EAP tab:

    Expiration of EAP-Response / EAP-Request List:  60
    A list is maintained to correlate EAP-Response packets with EAP-Request packets. Define the expire time of the list here. (Default: 60)

    Could it possibly be this setting?  I haven't changed anything in freeradius configs ever since I got this running in 2016, so it's weird it would suddenly start giving me issues.

  • EAP config:



    eap {
    default_eap_type = tls
    timer_expire    = 60  <–- This?
    ignore_unknown_eap_types = no
    cisco_accounting_username_bug = no
    max_sessions = 4096


    pwd {

    group = 19

    server_id =

    fragment_size = 1020

    virtual_server = "inner-tunnel"


    tls-config tls-common {

    private_key_password = <redacted>private_key_file = ${certdir}/server_key.pem

    certificate_file = ${certdir}/server_cert.pem
    ca_path = ${confdir}/certs
    ca_file = ${ca_path}/ca_cert.pem

    auto_chain = yes

    psk_identity = "test"

    psk_hexphrase =

    dh_file = ${certdir}/dh
    random_file = /dev/urandom
    fragment_size = 1024
    include_length = yes
    check_crl = no
    check_cert_issuer = <redacted>check_cert_cn = %{User-Name}
    cipher_list = "DEFAULT"
    cipher_server_preference = no

    disable_tlsv1_2 = no

    ecdh_curve = "prime256v1"
    cache {
    enable = no
    lifetime = 24
    max_entries = 255
    #name = "EAP module"
    #persist_dir = "/tlscache"
    verify {

    skip_if_ocsp_ok = no

    tmpdir = /tmp/radiusd

    client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-Client-Cert-Filename}"

    ocsp {
    enable = no
    override_cert_url = no
    url = ""

    use_nonce = yes

    timeout = 0

    softfail = no

    tls {
    tls = tls-common

    virtual_server = check-eap-tls

    ttls {
    tls = tls-common
    default_eap_type = tls
    copy_request_to_tunnel = no
    include_length = yes

    require_client_cert = yes

    virtual_server = "inner-tunnel-ttls"
    #use_tunneled_reply is deprecated, new method happens in virtual-server
    } ### end ttls
    peap {
    tls = tls-common
    default_eap_type = mschapv2
    copy_request_to_tunnel = no

    proxy_tunneled_request_as_eap = yes

    require_client_cert = yes

    MS SoH Server is disabled

    virtual_server = "inner-tunnel-peap"
    #use_tunneled_reply is deprecated, new method happens in virtual-server
    mschapv2 {

    send_error = no

    identity = "FreeRADIUS"


    fast {

    tls = tls-common

    pac_lifetime = 604800

    authority_identity = "1234"

    pac_opaque_key = "0123456789abcdef0123456789ABCDEF"

    virtual_server = inner-tunnel



  • Bump.  Some help would be greatly appreciated.

    It just happened again, and here are the results of more testing:


    • Can ping internal and external IPs
    • Can NOT ping by hostname or FQDN


    • Can lookup internal and external hosts

    Non-authoritative answer:
    Addresses:  2610:160:11:1000::18


    • Can tracert internal and external IPs.
    • Cannot tracert when using hostnames

    Unable to resolve target system name



    • DHCP lease has not expired.
    • Power saving on WLAN adapter is not enabled.
    • Bitdefender and Malwarebytes Full System Scans show clean.

  • I noticed in System Logs that php-fpm is signalling to restart other packages, including radiusd.

    I'll try to observe if this is correlated to the symptoms I'm experiencing.

    Aug 2 18:32:51 php-fpm 28550 /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - -> - Restarting packages.
    Aug 2 18:32:51 check_reload_status Starting packages
    Aug 2 18:32:52 php-fpm 28550 /rc.start_packages: Restarting/Starting all packages.
    Aug 2 18:32:52 php-fpm 28550 lcdproc: Sync: Begin package sync
    Aug 2 18:32:52 php-fpm 28550 lcdproc: Sync: End package sync
    Aug 2 18:32:52 php-fpm 28550 [pfBlockerNG] Starting cron process.
    Aug 2 18:32:56 radiusd 76053 Signalled to terminate

    Does anyone know what php-fpm is and why it's sending signals to restart other packages?

  • @Finger79:

    I noticed in System Logs that php-fpm is signalling to restart other packages, including radiusd.

    Simple to answer this one : pfSEnse is using a GUI for setuo.
    This means it uses a web server and some "extension" that executes scripts that make the GUI web pages. As you might guess, this PHP (half of the Interweb web sites uses PHP).
    "php-fpm" is you the name of the mode how PHP is executed and communicates web the web server (nginx).

    Somehow, pfSEnse IS actually all these PHP scripts (well, not entirely, but mostly). So, yes, it is PHP that restarts packages is some system wide settings are changed, interface drop and repop and other conditions.
    Should it restart "radiusd', that is the real question : it depends what happened. A new WAN IP is such a condition. It's probably non needed to restart radiusd when the WAN IP restarts ….
    Of course, the time radiusb restarts, all communication (authentication) is out of business. If this happens very often, well, the issue would pop up more often.

    Btw : I'm not using radius myself, but your question proves me that it wouldn't be a bad idea NOT to run radius on the firewall - if possible (needs another local (LAN) server device).