Solved: Unable to download files over HTTPS due to TLS encrypted alert
-
I have an interesting issue with one of my pfSense instances (Running 2.3.3-RELEASE-p1), in that the firewall is unable to download bogon definition files for IPv4 and IPv6 - the system log outputs the following:
Jun 5 17:07:24 root Could not extract fullbogons-ipv6.txt Jun 5 17:07:24 root Could not download https://files.pfsense.org/lists/fullbogons-ipv6.txt Jun 5 17:05:39 root Could not extract fullbogons-ipv4.txt Jun 5 17:05:39 root Could not download https://files.pfsense.org/lists/fullbogons-ipv4.txt Jun 5 17:03:54 root rc.update_bogons.sh is beginning the update cycle.
Having looked at rc.update_bogons.sh, I am trying to do a similar (yet simplified) manual download of the same files from a shell:
[2.3.3-RELEASE][admin@xyz.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt looking up files.pfsense.org connecting to files.pfsense.org:443
At this point the command will hang like this for quite a while (over a minute), until proceeding with the following:
[2.3.3-RELEASE][admin@xyz.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt looking up files.pfsense.org connecting to files.pfsense.org:443 SSL options: 83004bff Peer verification enabled Using CA cert file: /usr/local/etc/ssl/cert.pem Verify hostname TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384 Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA requesting https://files.pfsense.org/lists/fullbogons-ipv4.txt fetch: transfer timed out fetch: fullbogons-ipv4.txt appears to be truncated: 0/60268 bytes
I can successfully resolve files.pfsense.org from the pfSense instance - I have also checked, using openssl, that the certificate on files.pfsense.org verifies fine via /usr/local/etc/ssl/cert.pem. I also have a similar pfSense instance in which the same fetch command works just fine:
[2.3.3-RELEASE][admin@abc.com]/tmp: /usr/bin/fetch -v -o fullbogons-ipv4.txt https://files.pfsense.org/lists/fullbogons-ipv4.txt looking up files.pfsense.org connecting to files.pfsense.org:443 SSL options: 83004bff Peer verification enabled Using CA cert file: /usr/local/etc/ssl/cert.pem Verify hostname TLSv1.2 connection established using ECDHE-RSA-AES256-GCM-SHA384 Certificate subject: /OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.pfsense.org Certificate issuer: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA requesting https://files.pfsense.org/lists/fullbogons-ipv4.txt local size / mtime: 60268 / 1496638861 remote size / mtime: 60268 / 1496638861 fullbogons-ipv4.txt 100% of 58 kB 5776 kBps 00m00s
Taking a packet capture while trying to download the bogons file via fetch, I see what appears to be a successful TLS handshake between pfSense and 162.208.119.41 (one of the two servers for files.pfsense.org), followed by around 20 1514-byte packets being received and acknowledged, followed by pfSense sending a TLSv1.2 encrypted alert ("Alert (21)") towards the far end followed by pfSense sending a RST.
As far as I understand, an encrypted alert of type 21 means that the data could not be decoded - could this mean I have some dodgy memory in my server, or could this be something else? This pfSense instance is running on VMware ESXi 6 on top of a Dell PowerEdge R630, in case that is relevant.
I am not seeing any other odd behavior on this pfSense except for the problem mentioned above.
Any input or suggestions appreciated.
Edit: It seems that the issue is more generic than being unable to download the bogons files - I seem to be having issues downloading other, unrelated files via HTTPS using fetch as well.
Edit 2: The problem turns out to be that IPv6 was configured on WAN with no apparent connectivity. Enabling System > Advanced > Networking > Prefer to use IPv4 even if IPv6 is available appears to have resolved the issue (Since files.pfsense.org was available both via v4 and v6. It is however strange that this is the cause and fix since an IPv4 HTTPS connection was made and was to some extent working until it failed.
-
In case it is relevant,
Disable hardware checksum offload
Disable hardware TCP segmentation offload
Disable hardware large receive offloadare all ticked in System > Advanced > Networking.