When I tried to establish a Secure Shell (SSH) connection to a Windows 11 PC at a remote location today, I was unable to do so. I usually connect to the Windows domain controller at the location and establish the SSH connection to the user's Windows 11 system through it, but that was not working. I thought the problem was likely due to McAfee stopping providing firewall protection for incoming connections to ports on PCs as part of their antivirus software, since the antivirus software on PCs at that location was McAfee Antivirus Plus. When McAfee stopped providing that firewall service as part of McAfee AntiVirus Plus, the software reverted firewall protection for incoming connections to Microsoft's default firewall software, Microsoft Defender Firewall, aka Windows Firewall. When I check firewall protection on a Windows system running McAfee AntiVirus Plus, I now see the following message:
McAfee and Windows Defender are now working side by side
Our Advanced Firewall provides enhanced protection by blocking risky outgoing connections. Windows Defender Firewall provides protection for incoming connections.
Keep both firewalls on for complete protection.
So I thought I likely needed to create similar firewall rules for incoming connections in the Windows Firewall software as had existed previously in the McAfee firewall software.
I was able to connect to the server there via Remote Desktop (RDP) and Secure Shell (SSH), so I could use PowerShell on that system to do some troubleshooting. And I was able to connect to the Windows 11 system via RDP, since I had previously created a rule in the Windows Firewall to allow remote connectivity for the user of that system, though I wasn't now able to connect to it via SSH even from the server on the same Local Area Network (LAN). I thought I might have forgotten to establish an appropriate SSH rule in the Windows Firewall when I had created the RDP rule for the user.
From the server, I used the Test-NetConnection PowerShell
cmdlet with the command Test-NetConnection -ComputerName Thelma -Port 22
to test whether
TCP
connectivity was open to the SSH port, port 22 (you can provide the computer
name or the IP address to the command to query a port on a system).
PS C:\Users\Administrator> Test-NetConnection -ComputerName Thelma -Port 22 WARNING: TCP connect to (192.168.1.17 : 22) failed ComputerName : Thelma RemoteAddress : 192.168.1.17 RemotePort : 2217 InterfaceAlias : Embedded NIC 1 SourceAddress : 192.168.1.10 PingSucceeded : True PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : False PS C:\Users\Administrator>
The command showed the system could be pinged, but the SSH port on the system wasn't accessible. Yet, when I checked whether the 192.168.1.17 system was listening on that port from a command prompt on the Windows 11 sysrem at 192.168.1.17 system, I found it was listening on the port.
C:\>netstat -an | find "22" | find "LISTENING" TCP 0.0.0.0:2217 0.0.0.0:0 LISTENING TCP [::]:2217 [::]:0 LISTENING C:\>
And, when I checked on whether a firewall rule existed in the Windows
Firewall using the Get-NetFirewallPortFilter command from
a PowerShell prompt opened with administrator privilege, I found one was
present.
Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. Try the new cross-platform PowerShell https://aka.ms/pscore6 PS C:\WINDOWS\system32> Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 22 } | Get-NetFirewallRule Name : {3BE2A4E6-2D4A-40CA-9495-7FE337EE80B0} DisplayName : SSH Description : Inbound Secure Shell (SSH) connectivity to Thelma's PC. DisplayGroup : Group : Enabled : True Profile : Any Platform : {} Direction : Inbound Action : Allow EdgeTraversalPolicy : Block LooseSourceMapping : False LocalOnlyMapping : False Owner : PrimaryStatus : OK Status : The rule was parsed successfully from the store. (65536) EnforcementStatus : NotApplicable PolicyStoreSource : PersistentStore PolicyStoreSourceType : Local RemoteDynamicKeywordAddresses : PolicyAppId : PS C:\WINDOWS\system32>
Since the firewall rule was in place for inbound connectivity to the port,
I didn't at first understand why I couldn't connect via SSH to the system
from the server on the same LAN and why the query I ran with the PowerShell
Test-NetConnection command failed to connect to the system on
the specified port. But I was able to determine the cause of that problem
when I checked the scope of the firewall rule.
PS C:\WINDOWS\system32> $rule = Get-NetFirewallRule -DisplayName "SSH" PS C:\WINDOWS\system32> Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $rule | Select-Object LocalAddress, RemoteAddress LocalAddress RemoteAddress ------------ ------------- Any {10.64.0.0/255.240.0.0, 172.16.1.95} PS C:\WINDOWS\system32>
Since I knew the DisplayName for the rule was SSH
I set a variable equal to the data returned by Get-NetFirewallRule
for a query with that DisplayName with $rule = Get-NetFirewallRule
-DisplayName "SSH" and then used the
Get-NetFirewwallAddressFilter cmdlet to check the scope of
the rule, i.e., restrictions on the remote addresses used to connect to
the system on the port to which the rule applied with the command
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $rule |
Select-Object LocalAddress, RemoteAddress. I found that the rule
was not permitting connectivity from other systems on the LAN, i.e.,
addresses in 192.168.1.17/25. I was able to add the LAN
addresses to the rule as permitted systems using the
Set-NetFirewallRule cmdlet
Set-NetFirewallRule -DisplayName "SSH" -RemoteAddress "192.168.1.0/25",
"10.64.0.0/255.240.0.0", "172.16.1.95". Note: you can either
specify a subnet mask as
/v.x.y.z, e.g., the 255.240.0.0 subnet mask specified
for the 10.64.0.0 network below, or in
CIDR notation, i.e. the /25 for the 192.168.1.0 network
in the example below. After setting the rule with the Set-NetFirewallRule
cmdlet, I verified it with the Get-NetFirewallAddressFilter
cmdlet with Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $rule | Select-Object LocalAddress, RemoteAddress.
PS C:\WINDOWS\system32> Set-NetFirewallRule -DisplayName" "SSH" -RemoteAddress "192.168.1.0/25", "10.64.0.0/255.240.0.0", "172.16.1.95" PS C:\WINDOWS\system32> Get-NetFirewallAddressFilter -AssociatedNetFirewallRule $rule | Select-Object LocalAddress, RemoteAddress LocalAddress RemoteAddress ------------ ------------- Any {192.168.1.0/255.255.255.128, 10.64.0.0/255.240.0.0, 172.16.1.95} PS C:\WINDOWS\system32>
After I added the LAN addresses to the scope of the firewall rule, when
I checked TCP connectivity to the SSH port from the server with the
command Test-NetConnection -ComputerName Thelma -Port 22.
I then saw it was able to successfully connect.
PS C:\Users\Administrator> Test-NetConnection -ComputerName Thelma -Port 22 ComputerName : Thelma RemoteAddress : 192.168.1.17 RemotePort : 2217 InterfaceAlias : Embedded NIC 1 SourceAddress : 192.168.1.10 TcpTestSucceeded : True PS C:\Users\Administrator>
I was also then able to establish an SSH connection from the server to the user's Windows 11 system.
Related articles: