1

I have a VM with 2 network interfaces which is running CentOS. One connects to a private network (192.168.6.x) and another to our company wide network. When I try to ssh the private address from a host that has access I get no response. It appears that the request comes in via 1 interface but goes out the other. Being that the other interface doesn't have a route back the packets get lost. Why doesn't it send it back out the same interface? Is there a setting I can enable so it will.

EDIT: please disregard what I previously said about ping working but ssh not, I was mistaken on that.

EDIT: result of route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.192.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.6.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.126.186.0    192.168.6.61    255.255.255.0   UG    0      0        0 eth0
172.91.4.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0.1026
10.126.163.0    172.91.4.1      255.255.255.0   UG    0      0        0 eth0.1026
10.164.0.0      172.91.4.1      255.255.0.0     UG    0      0        0 eth0.1026
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     1008   0        0 eth0.1026
144.0.0.0       172.91.4.1      255.0.0.0       UG    0      0        0 eth0.1026
147.0.0.0       172.91.4.1      255.0.0.0       UG    0      0        0 eth0.1026
0.0.0.0         172.91.4.1      0.0.0.0         UG    10     0        0 eth0.1026
MikeKulls
  • 336
  • 1
  • 2
  • 16
  • what is then output of route -n ? is sshd service running(service sshd status) and listening all interfaces(netstat -puntl | grep sshd) ? is there any firewall(iptables. etc..) to block ssh? did you try ssh verbose mode ( with -v option) ? did you try to connect ssh port on telnet ? – efesaid Sep 02 '14 at 04:53
  • We've confirmed it's not a firewall issue etc. It was a matter of adding a route so it knows to send packets out that interface `ip route add 10.126.186.0/24 via 192.168.6.61 dev eth0` – MikeKulls Sep 02 '14 at 04:55
  • could you show your route -n please ? – efesaid Sep 02 '14 at 04:58
  • I've added it as an edit to the question – MikeKulls Sep 02 '14 at 05:24
  • Can you say what the network address of your source system is? The one you're trying to connect *from*. You might want to be very specific and give the source systems routing table (output of `ip route`) – Ian Macintosh Sep 02 '14 at 08:34
  • Thanks for the reply. This is the details from ifconfig `eth0 Link encap:Ethernet HWaddr 00:50:56:AB:45:F6 inet addr:10.126.186.22 Bcast:10.126.186.127 Mask:255.255.255.128` and this is the output from ip route `10.126.186.0/25 dev eth0 proto kernel scope link src 10.126.186.22 169.254.0.0/16 dev eth0 scope link default via 10.126.186.1 dev eth0` – MikeKulls Sep 02 '14 at 21:13
  • I should add the entry in the routing table `10.126.186.0 192.168.6.61 255.255.255.0 UG 0 0 0 eth0` was added to fix the issue. Without this the packet was not going out eth0, I presume it was going out eth1 hence I would never get a response – MikeKulls Sep 02 '14 at 22:46

1 Answers1

0

Details still a bit fuzzy because you seem to have a lot of static routes going all over the place but one thing does stand out based on your last answer where you added an entry to the routing table:

10.126.186.0    192.168.6.61    255.255.255.0   UG    0      0        0 eth0

to fix the issue. In essence this means 10.126.186.0/24 via eth0 gateway 192.168.6.61

But you (source) are on 10.126.186.22/25. Note the different netmask. This is going to cause problems if the destination server has an IP address above 10.126.186.128.

Furthermore you shouldn't have a gateway address for your own network. So that route should rather be:

route add -net 10.126.186.128/25 gw 192.168.6.61

This routing problem is because you are using a gateway to get to the destination system, but it will try to reply directly because it (the destination) thinks it's actually on the same network as you are (because it's netmask is wider than yours), instead of going back via the gateway 192.168.6.61

Resolving that discrepancy will probably fix it for you if that is the only issue.

Just on your last comment, it's incorrect in stating that it would go out via eth1 because there is no route to cause it to do that. However, without the route that you added, it would have gone out eth0 addressed to your default gateway 172.91.4.1. From this I assume that this 172.91.4.1 gateway does not have a connection to the 10.126.186.128/25 network and is therefor the wrong gateway. You adding the 192.168.6.61 route bears this out.

If you gave the IP address (or network address) of the destination server it would help as well in understanding your question better. You did specify the one network address but didn't give the other in your question.

Ian Macintosh
  • 955
  • 1
  • 6
  • 12