0

I have COMPUTER B on two networks -- 10.132.2.* and 10.132.1.* The 10.132.1.* network is wired; the 10.132.2.* network is wireless. I have opened an ssh port on each network, but something strange is happening on the wireless network. The ssh port is open and I can connect to it from other devices on the 10.132.2.* network -- EXCEPT, forwarded connections from the WAN on the wireless network.

enter image description here

  • If I connect the cable on 10.132.1.10, COMPUTER B stops responding to SSH requests from EA6350 on 10.132.2.20. If I disconnect the cable on 10.132.1.10, COMPUTER B will respond to SSH requests from EA6350.
  • In either case, COMPUTER B will respond to SSH requests from COMPUTER A.

If I set up a simple listener (so taking SSH out of the picture) on COMPUTER B using nc and try to telnet at it from the internet, again, I can see the packet coming through using tcpdump, but the nc listener doesn't actually do anything.

Bottom line, something in the system is not allowing the connection to come through.

I am wondering if the problem is what is related to "https://askubuntu.com/questions/166068/port-seems-to-be-open-but-connection-refused". Looking at one response here: "You will also need to ensure that "mydomain.com" resolves to the correct IP address for your machine, such that connecting to it will result in communication with the external interface of that machine."

I don't really know what this means in my context. I don't understand if this is saying that I need the IP address of COMPUTER B (10.132.2.20)? I tried adding an entry in /etc/hosts, but that did not seem to help. Does this mean I need an entry for my domain? On my LAN, what IP address do I give to my entire domain?

Output from "ip route" (which, I confess, I don't truly entirely grok):

default via 10.132.1.1 dev eno1 proto dhcp metric 100 
default via 10.132.2.1 dev wlp1s0 proto dhcp metric 600 
10.132.1.0/24 dev eno1 proto kernel scope link src 10.132.1.10 metric 100 
10.132.2.0/24 dev wlp1s0 proto kernel scope link src 10.132.2.20 metric 600 
169.254.0.0/16 dev wlp1s0 scope link metric 1000

Here is the output from "iptables -L"

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Here's the output from "ufw status":

Status: inactive

Here's the output from "egrep -v -e ^# -e ^$ /etc/ssh/sshd_config", though I don't think the problem is with SSH as NC displays similar behavior (see comments above).

Port 20
Port 22
Port 80
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/lib/openssh/sftp-server
Christopher Donham
  • 131
  • 5
  • As I said above, "I can see the packets coming in with tcpdump. I can even use another computer that is wired on the 10.132.2.* network to forward the ssh connections to the wireless.". The issue is not the router. – Christopher Donham Sep 27 '20 at 16:36
  • In case the second part of that is not clear, this works: Router -> WIRED Computer (on 10.132.2.* network forwarding to) -> WIRELESS Computer (on 10.132.2.* network). This does NOT work: Router -> WIRELESS Computer (on 10.132.2.* network). All computers involved have static IP addresses. – Christopher Donham Sep 27 '20 at 16:41
  • I've added a picture and tried to make the description more clear about what works and what doesn't. – Christopher Donham Sep 27 '20 at 17:09
  • You are using port forwarding on the Linksys to allow the inbound ssh connections? Also, could you post ```egrep -v -e ^# -e ^$ /etc/ssh/sshd_config``` for both Computer A & B – Frobozz Sep 27 '20 at 18:02
  • Computer B has 2 network interfaces -- one wired and one not. The goal is that Computer B receive SSH requests from the EA6350 and service them. I have shown via tcpdump that the EA6350 is sending the SSH packets through. I have shown via a tunnel from Computer A to B that Computer B is setup to receive the SSH packets and process them correctly. The problem, then, is that when the EA6350 sends the packets directly to Computer B, Computer B ignores them. I have also shown that this is NOT a problem with how SSH is set up because other programs, such as NC (see "man nc") are also broken. – Christopher Donham Sep 27 '20 at 22:25
  • I have updated the picture based on your comments to try to make it more clear. – Christopher Donham Sep 27 '20 at 22:36
  • I tried disconnecting the 10.132.1.10 on COMPUTER B, and COMPUTER B will now accept SSH requests directly on 10.132.2.20 (no other change other than to disconnect the cable). I reconnect 10.132.1.10, and COMPUTER B stops accepting requests on 10.132.2.20. – Christopher Donham Sep 27 '20 at 23:06
  • Please note that in either case, COMPUTER B will accept SSH connections from COMPUTER A, so the WiFi connection is there even when the cable is connected. – Christopher Donham Sep 27 '20 at 23:32

1 Answers1

0

tl;dr: Delete the default route to 10.132.1.1 and incoming connections on 10.132.2.x will be successfully returned on the 10.132.2.x network. Note that this relies on the fact that I do not use the 10.132.1.1 for incoming connections.

LONG VERSION:

After posting this question on various forums, someone suggested that my configuration is what is called "dual home", and that I was not set up correctly to support two networks. Some research on this brought me to these entries from "ip route":

default via 10.132.1.1 dev eno1 proto dhcp metric 100 
default via 10.132.2.1 dev wlp1s0 proto dhcp metric 600

This is saying that the machine is currently set up with two default routes. Putting a tcpdump on the 10.132.1.10 side of COMPUTER B and then attempting to ssh in to 10.132.2.20 showed that COMPUTER B was attempting to send responses with the IP address 10.132.2.20 out on the 10.132.1.x network -- which failed.

The weird thing is that before this, I never detected any problems with this setup. The simple solution for my system was simply to delete the default route on 10.132.1.1. Since the routing tables also include the following:

10.132.1.0/24 dev eno1 proto kernel scope link src 10.132.1.10 metric 100

any connections to local devices continue to work.

Christopher Donham
  • 131
  • 5