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
  • 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 2 '14 at 4: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 2 '14 at 4:55
  • could you show your route -n please ? – efesaid Sep 2 '14 at 4:58
  • I've added it as an edit to the question – MikeKulls Sep 2 '14 at 5: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 2 '14 at 8:34
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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.