Messages

[SSLyze]

I have noted some unusual behavior with the TLS ciphers available in 18.1.8.  I enabled several "secure" ciphers and, naturally, locked myself out temporarily (always have backups!).  After restoring the last good config, I decided to probe a bit further to see what was actually reciprocated in the TLS handshake and was quite surprised.  Specifically, I hoped to lockdown the ciphers for remote administration to only ECDHE_ECDSA using GCM, but apparently those ciphers aren't actually working.  I ran some tests using SSLyze and these are the results that concerned me.

Code Select Expand

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384             ECDH-384 bits  256 bits
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256             ECDH-384 bits  128 bits
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384           TLS / Alert: handshake failure
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256           TLS / Alert: handshake failure

I switched to LibreSSL with no difference in the handshake results, so I don't think the library is at fault (but obviously I'm not certain).  Perhaps it's a known bug, but I couldn't find anything here in the forums or elsewhere.  And I'm sure there may be other ciphers that should work, but I didn't try.  I can post my full handshake results if anyone's interested.

I don't expect that this issue rates very highly on anyone's list given the other issues noted, but I thought it was worth posting here in case someone is looking in the future for why they were locked out after tightening their ciphers.  In particular, it appears that the best option available with modern browsers is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

I still had a VM that I used after a hardware change to test this with. Confirmed as working. The redacted IP is the LAN IP of the firewall.

Bart...

Thanks, Bart.  That did the trick.  It's still confusing to me why a filter rule cannot permit SSH to the WAN inteface, when the listener is active and I can tcpdump the inbound packets, but this works like a top.

Click System>Settings>Administration>...about the middle of the page you have options

-Enable Secure Shell
-Permit root user login
-Permit password login

Below is the
-SSH Port (blank) -enter 22

Thats it..no firewal rule...but will be added auto...

All already enabled, but no dice.  The root option isn't needed, and I do plan to use certs so the password option also won't be required.

I noted that you said this is for a lab environment.  That almost always means private IP address used on the WAN interface. Please double check on the WAN interface settings that the "Block Private Networks" option is not checked.  Otherwise it would block all traffic coming into the WAN interface.

Yep, I unchecked the private and bogon networks options previously.

A little background:

• This particular firewall is part of a lab environment, so there's no ISP involved.
• I've tried several combinations for the destination address, with no difference.
• Adding a port-forward rule also didn't seem to help.
• If I disable pf via the shell, the firewall responds (as one would expect any FreeBSD system to do so).

Certainly, I intend to deploy OPNsense using OpenVPN for remote management, but that won't be feasible for every deployment scenario and really don't want to be stuck relying on TeamViewer with a LAN workstation.  :o

em0 is WAN, em1 is LAN

I'm trying to enable SSH for remote administration but seem stuck on the pf rules.  I've confirmed that SSH is enabled and available from the LAN, but after adding what I think to be the right rule, it doesn't seem to work.  Here's what I have in the WebGUI:



When I look at rules output from pfctl, this is the rule present (sans WAN IPs):

Code Select Expand

pass in log quick on em0 reply-to (em0 xxx.xxx.xxx.xxx) inet proto tcp from any to xxx.xxx.xxx.xxx port = ssh flags S/SA keep state label "USER_RULE: Remote SSH Admin"

This should be possible right?  I looked for a while and can't find any references that don't lead back to pfSense instead.