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
  • 151

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
  • 151