Ssh on port 443… not working
-
A service on the firewall cannot affect traffic passing through to other hosts.
If anything on the firewall is affecting it, it would have to be a NAT rule (Port forward, etc), or possibly a port forward in combination with NAT reflection.
Under Firewall, NAT, Port Forward has no entries. 1:1 has no entries. Outbound is set to manual with no mappings listed. NPt has no entries.
-
This is traffic to SSH on the pfSense box though, no?
When you set SSH to run on port 443 do you see anything in the logs? I would expect some error if two services try to claim the same port.
Steve
Ok when I make a successful ssh into my system, the system log looks like this:
Nov 10 17:25:24 sshd[34537]: Received disconnect from x.x.x.x: 11: Closed due to user request. Nov 10 17:25:11 sshd[34537]: Accepted keyboard-interactive/pam for admin from x.x.x.x port 54142 ssh2I also have it create a log entry every time this event is triggered which shows up in the Firewall log.
Now when I change the System, Advanced entry to 443, and also my corresponding WAN rule which handles this traffic to 443, my ssh client keeps trying to connect but I don't get anything which prompts me for a login/password, so it times out. I look in the System Logs and find the change I made in the Advanced settings shows up as this:
Nov 10 17:29:08 sshd[14583]: Server listening on 0.0.0.0 port 443. Nov 10 17:29:08 sshd[14583]: Server listening on :: port 443.Here is some other diagnostic output from the change:
$ sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sockstat 68630 20 udp4 *:40679 *:* root sleep 67072 20 udp4 *:35821 *:* root sh 20054 20 udp4 *:35821 *:* root lighttpd 19588 14 tcp4 *:80 *:* root lighttpd 19588 16 tcp4 (removed):80 (removed):1538 root lighttpd 19588 20 udp4 *:35821 *:* root sshd 14583 5 tcp4 *:443 *:* root bandwidthd 76479 20 udp4 *:16009 *:* root bandwidthd 76380 20 udp4 *:16009 *:* root bandwidthd 76325 20 udp4 *:16009 *:* root bandwidthd 76027 20 udp4 *:16009 *:* root ntop 74219 2 tcp4 *:3000 *:* root ntop 74219 20 udp4 *:16009 *:* root syslogd 43918 13 udp4 *:514 *:* root php 35707 10 udp4 *:* *:* root php 35707 20 udp4 *:40679 *:* root php 35635 10 udp4 *:* *:* root php 35635 20 udp4 *:52556 *:* root ntpd 33736 21 udp4 *:123 *:* root ntpd 33736 22 udp4 (removed):123 *:* root ntpd 33736 25 udp4 127.0.0.1:123 *:* root php 23667 10 udp4 *:* *:* root php 23667 20 udp4 *:40679 *:* root php 22571 10 udp4 *:* *:* root php 22571 20 udp4 *:52556 *:* root inetd 12110 10 udp4 127.0.0.1:6969 *:*I don't know why it shows up with the 0.0.0.0 address in the log. My LAN port is set to 'none' and WAN is a static IP address. I have the OPT1 interface set up as Bridge0 between the two and there are no VLANs in use.
-
0.0.0.0 means bind to all addresses on the host. So you could ssh to your LAN address, WAN address, etc. Firewall rules permitting, of course.
-
0.0.0.0 means bind to all addresses on the host. So you could ssh to your LAN address, WAN address, etc. Firewall rules permitting, of course.
I guess I don't understand what you mean. My LAN port has no address; my WAN port's address isn't routable. How would I be able to ssh to the WAN port?
-
If you're not using the WAN address to SSH to what are you using?
What address do the logs show sshd is listening on when it's set to use port 22?
Steve
-
If you're not using the WAN address to SSH to what are you using?
What address do the logs show sshd is listening on when it's set to use port 22?
Steve
Oh I see what you're saying now. Let me clarify: I posted this thread because I wasn't able to ssh remotely, as in, via the internet, to my pfsense box on port 443. I am always able to ssh from any machine on the LAN to the WAN port address.
And here are the log entries when I change it back to port 22 in the Advanced settings:
Nov 10 20:51:14 check_reload_status: webConfigurator restart in progress Nov 10 20:51:14 check_reload_status: starting sshd Nov 10 20:51:14 php: /system_advanced_admin.php: webConfigurator configuration has changed. Restarting webConfigurator. Nov 10 20:51:14 php: /system_advanced_admin.php: secure shell configuration has changed. Restarting sshd. Nov 10 20:51:14 php: /system_advanced_admin.php: secure shell configuration has changed. Stopping sshd. Nov 10 20:51:14 sshd[19816]: Received signal 15; terminating. Nov 10 20:51:13 check_reload_status: Reloading filter Nov 10 20:51:13 check_reload_status: Syncing firewall Nov 10 20:50:35 php: rc.restart_webgui: Creating rrd update script Nov 10 20:50:35 kernel: Bump sched buckets to 256 (was 0) Nov 10 20:50:35 kernel: Bump sched buckets to 256 (was 0) Nov 10 20:50:35 kernel: Bump sched buckets to 256 (was 0) Nov 10 20:50:35 kernel: Bump sched buckets to 256 (was 0) Nov 10 20:50:35 kernel: Bump sched buckets to 256 (was 0) Nov 10 20:50:33 sshd[19816]: Server listening on 0.0.0.0 port 22. Nov 10 20:50:33 sshd[19816]: Server listening on :: port 22.Edit: Now that I just posted this, I realize that the problem may in fact not be on pfsense, rather it's probably my router not properly passing traffic on 443. Let me look into that one for a bit and I'll try to report back soon.
-
Ah OK. Also do you know that your ISP isn't blocking port 443? I haven't seen that for a while but it used to be quite common.
Steve
-
When running the pfsense gui on 443 its possible you may run into problems running something like SSH on 443 also.
Its so hit and miss with systems that when I run services on 443 or 80 I just put the pfsense gui somewhere else, like 7443But yeah - could also be your modem.
-
Ok well I feel like an idiot now. Turns out the problem was on the router actually in that there was a nat rule I previously setup to pass traffic from the outside in on set ranges of ports. I literally have not logged into this device in several years and completely forgot all about this. Once I modified some of the nat settings, traffic on 443 was passed just fine. The problem never was on the pfsense side.
Sorry for wasting everyone's time on this but I do appreciate the help in trying to track down the issue.
-
No problem. Easily done. ;)
Steve
