pfSense Support Subscription

Author Topic: Win7 Supplicant Acting Weird (Unable to browse websites) q1 hr  (Read 302 times)

0 Members and 1 Guest are viewing this topic.

Offline Finger79

  • Full Member
  • ***
  • Posts: 188
  • Karma: +17/-0
    • View Profile
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?
« Last Edit: August 02, 2017, 09:04:18 pm by Finger79 »

Offline Finger79

  • Full Member
  • ***
  • Posts: 188
  • Karma: +17/-0
    • View Profile
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.

Offline Finger79

  • Full Member
  • ***
  • Posts: 188
  • Karma: +17/-0
    • View Profile
EAP config:

/usr/local/etc/raddb/mods-enabled/eap
### EAP
eap {
   default_eap_type = tls
   timer_expire     = 60   <--- This?
   ignore_unknown_eap_types = no
   cisco_accounting_username_bug = no
   max_sessions = 4096

### DISABLED WEAK EAP TYPES MD5, GTC, LEAP ###

#   pwd {
#      group = 19
#      server_id = theserver@example.com
#      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 = "http://127.0.0.1/ocsp/"
         # 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
#   }
}
« Last Edit: August 02, 2017, 08:41:20 pm by Finger79 »

Offline Finger79

  • Full Member
  • ***
  • Posts: 188
  • Karma: +17/-0
    • View Profile
Bump.  Some help would be greatly appreciated.

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

PING
- Can ping internal and external IPs
- Can NOT ping by hostname or FQDN

NSLOOKUP
- Can lookup internal and external hosts

Non-authoritative answer:
Name:    forum.pfsense.org
Addresses:  2610:160:11:1000::18
          208.123.73.18


TRACERT
- Can tracert internal and external IPs.
- Cannot tracert when using hostnames
       
tracert forum.pfsense.org
Unable to resolve target system name forum.pfsense.org.

WEB BROWSING
- Can NOT browse using FQDN
- CAN browse using IP.
   Example:  Can navigate to https://208.123.73.18 but not https://forum.pfsense.org
   
Verified:
* DHCP lease has not expired.
* Power saving on WLAN adapter is not enabled.
* Bitdefender and Malwarebytes Full System Scans show clean.
« Last Edit: August 02, 2017, 08:54:07 pm by Finger79 »

Offline Finger79

  • Full Member
  • ***
  • Posts: 188
  • Karma: +17/-0
    • View Profile
Re: Win7 Supplicant Acting Weird (Unable to browse websites) q1 hr
« Reply #4 on: August 02, 2017, 09:33:30 pm »
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 - 10.65.10.6 -> 10.21.10.10 - 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?

Offline Gertjan

  • Hero Member
  • *****
  • Posts: 2147
  • Karma: +165/-9
    • View Profile
Re: Win7 Supplicant Acting Weird (Unable to browse websites) q1 hr
« Reply #5 on: October 20, 2017, 03:27:15 am »
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).