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.8WLAN 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:
/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 = 4096DISABLED 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.pemauto_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 = nodisable_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-commonvirtual_server = check-eap-tls
}
ttls {
tls = tls-common
default_eap_type = tls
copy_request_to_tunnel = no
include_length = yesrequire_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 = noproxy_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>
-
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.18TRACERT
- 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.
-
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 terminateDoes anyone know what php-fpm is and why it's sending signals to restart other packages?
-
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).