SSH cant connect
-
SSH from what to where ?
-
From my own laptop, which was on DHCP, to a Linux RHEL server. So I wasn't trying to SSH the pfSense box. I did try that though, and it worked. I was also able to SSH some other Linux Debian box.
-
@cheesetoasty and is this box your trying to ssh to on the same network as the box your trying to ssh from? If so pfsense has zero to do with it.
When you swapped out your old device for pfsense, are you on the same network space? ie 192.168.1/24 or whatever.. If not its possible the firewall on this machine your having problems with doesn't allow the current network to talk to ssh.
-
@johnpoz Yes that's what I thought, its all just local traffic on the LAN, and I'd have thought it goes through the switch not the pfSense box which is just the gateway.
Never the less, that seems to be what happened. I swapped back to the Draytek, and it worked again. The subnet didn't change.
So weird.
-
@cheesetoasty I don't know what issue you are having - but pfsense has zero to do I mean zero to do with conversation between 2 devices on the same network..
Is this a windows machine your trying to ssh too? If so changing the gateway could have it go into public mode vs private mode for its firewall. In public mode no inbound would be allowed. Since it would notice its on a new network by the mac of its gateway changing.
Not aware of any linux firewalls that do that sort of thing - but windows sure does.
Your not trying to ssh to it via name - which pfsense might not resolve?
-
@johnpoz I just tested this out again, it still did it. Both machines are Linux, one Fedora and one RHEL, and I was trying to connect by IP address not by name.
-
@cheesetoasty you understand how things talk to each other when on the same network right?
192.168.1.x/24 wants to talk to 192.168.1.y/24 so .x arps for .y, Y then answers so X then sends the traffic to Ys mac..
Pfsense the router at 192.168.1.z/24 has zero to do with that conversation, zero.
Can you ping .y from .x? Look in the arp table of .x - do you see .y mac? Is it the correct mac? Ping .y from .x, then look in the arp table of .x, "arp -a" do you see .y mac?
The only time pfsense would have anything to do with that conversation is if you had a bridge setup on pfsense, and .x was on one side of the bridge and .y was on the other side.
What firewall are you using on these linux hosts.. I have no experience using for example firewalld that is a linux zone firewall, it is possible it is changing zones on you like windows firewall does??
Which I guess can be used on RHEL and Fedora..
Maybe it is the default firewall these days on those distros? And its changing the zone when the gateway mac address changes, ie you change the router at .z from your old router to the new pfsense router. But when host A can not talk to host B on the same network - you need to look at basic connectivity can they see each others mac addresses, does the firewall on the host allow the traffic. The "router" to get off the network is not involved in their A to B or B to A conversations.
The only thing that might also change is if these devices are dhcp, which pfsense provides - maybe address .y is now .q or something and your still trying to talk to .y address?
-
I've maybe a explanation for this behavior :
@cheesetoasty said in SSH cant connect:
I swapped back to the Draytek, and it worked again. The subnet didn't change.
Take a some 'unknow, new' router, and two 'Windows PCs - any Windows version'.
Hook up the two PCs to the router - with the help of a switch.On both PC's open Explorer, and go to 'Network'.
You probably see your own PC, and not the other.
On the other PC : same thing ....
What happened ?On both PCs, when you connect them to a 'new' previously unknown, network, using a cable or Wifi, you will be suing the default Public (= more secure) network = firewall settings : the windows firewall will only communicate with the local gateway = the new unknown router. And no other devices on the same LAN. No connection can be made, and no incoming connections will be accepted.
Switch both PCs to "Private" network setting.
Now, under Network, all network PCs will pop up. You still need user credentials to connect, but you can see them now in Explorer.
(probably optional these days : make sure both PCs using the same work group name).
And now they will accepted connection from the other LAN devices.I never used RHEL, but why wouldn't they use the same initial protection ?
-
@Gertjan the typical firewalls in linux didn't use do this sort of thing.. But I agree with you the firewall called firewalld that rhel and fedora both support is a zone based firewall and I do believe it does the same sort of thing the windows firewall does where you can set a zone that the interface is in, home, trusted, work, public, dmz, etc.
I have no experience with that specific firewall.. I always just used ufw or iptables.. But just a quick breeze over of its docs sure points to being able to dynamically change the zone an interface is in, etc.
A zone change because the mac of the gateway changed for sure could be causing what he is seeing that is for sure.
-
@johnpoz Hmm could be, the other box I have is debian, and seems unaffected. Not sure if they have some other firewall.
-
@cheesetoasty Are the Linux systems static IPs or DHCP?
If they are DHCP they might be changing addresses.
Verify the IP address of both after the FW switch.Establish an SSH session then switch the FWs for a test.
I would not expect the local FW on either system to be the problem on its own because if it is enabled it is more or less just IPTables, nothing fancy and annoying like Windows.
-
@AndyRH said in SSH cant connect:
if it is enabled it is more or less just IPTables
If it was iptables or ufw I would agree with you - but this firewalld is zone based.. And such a firewall coming up in a different zone or not any zone would explain his symptoms exactly.
https://docs.fedoraproject.org/en-US/quick-docs/firewalld/
All Fedora Editions install, configure and activate the firewall by default. No further action is required. The only exception is Cloud Edition, which relies on the higher level cloud system.
That sounds like to me its using firewalld and not iptables or ufw, etc.
I would see if its running
systemctl status firewalld
if it is, shut it down, does ssh now work?
sudo systemctl stop firewalld
If it running, you should be able to see what zone its in and settings with
firewall-cmd --list-all
