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

[Finger79]

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?

[Finger79]

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.

[Finger79]

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

}

}</redacted></redacted>

[Finger79]

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.

[Finger79]

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?

[Gertjan]

@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).