[SOLVED] Remote administration via SSH

[roundtree]

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.

[ThuTex]

first, personal opinion.... firewall to protect your network, remotely manageable... yikes.

secondly, try a port above 1024  with a forward (maybe your isp blocks low ports)

and last (not sure about this one)... maybe you also need to have a port forward to specify the fact that you want the firewall to respond and not a server behind it. (maybe this can be fixed with destination "this firewall" instead of "wan address" ?)

[franco]

The image is cropped. Is em0 LAN or WAN?

[roundtree]

em0 is WAN, em1 is LAN

[roundtree]

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

[abalsam]

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.

[istok011]

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

[roundtree]

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.

[roundtree]

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.

[bartjsmit]

Do you have a NAT port forward rule to expose sshd on the WAN side?

Bart...

[bartjsmit]

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

[roundtree]

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.