2

I have run into a similar problem as in this question about a wrong IP in LAN. However, the standard addr alias trick on the NIC did not help. I have no direct access to the server console, I might get physical access in a week or more if I'm lucky, but I hope I can find a faster way.

I can arping the (Linux) server on the address 10.0.0.1 from a server (Linux, with IP $MY_IP) on (supposedly) the same L2 segment and it replies with the $TARGET_MAC which is the correct and expected MAC for that server

root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from $MY_IP $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.746ms
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.796ms
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.807ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)

I have hidden my IPs and MACs as these machines are publicly accessible.

If I add an address alias for that interface, I can still arping the target, but I cannot ping it. No other interface has the 10.0.0.0/24 range, it fails even with ping -I $IFACE.

root@host:~# ip addr add 10.0.0.2/24 dev $IFACE
root@host:~# arping -c 3 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.788ms
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.766ms
Unicast reply from 10.0.0.1 [$TARGET_MAC]  0.794ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

The target server listens for SSH connections, but ssh won't get through

root@host:~# ssh -vvv 10.0.0.1
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.0.1 [10.0.0.1] port 22.
debug1: connect to address 10.0.0.1 port 22: Connection timed out
ssh: connect to host 10.0.0.1 port 22: Connection timed out

I have tried forcing the target to update its ARP table by sending it ARP REPLY packets, but that didn't seem to help.

root@host:~# arping -A -c 3 -s 10.0.0.2 -I $IFACE 10.0.0.1
ARPING 10.0.0.1 from 10.0.0.2 $IFACE
Sent 3 probes (3 broadcast(s))
Received 0 response(s)
root@host:~# ping -c 3 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

There is a slight chance that there is some L3 component, because the server sent me email updates (apt-listchanges output), but the email headers contain an IP that is assigned to some switch, yet the hostname in the headers was correct (the target's hostname). Other admins have told me that it should be on the same L2 segment and arping seems to suggest that. Are there other ways to rule out L3 components?

The goal is to establish an SSH connection to the target server so that I can fix the problem.

Ondřej Grover
  • 131
  • 3

1 Answers1

2

Apparently your on the same L2 ethernet segment, using IPs 1 and 2 in the same range. I can think of two reasons why it wouldn't work:

  • Server with IP 10.0.0.1 has some kind of layer 3 filtering active (most probably IPTable) and drop the ICMP packets you're sending, despite everything is setup right to make it work on a network point of view. Try other probes (ssh, telnet, http, or whatever network service is known to be listening on the server).
  • For whatever reason your ping probes are not leaving through $IFACE (for example if the same IP range is also configured on another interface). Try using ping -i $IFACE
CuriousFab
  • 121
  • 2
  • Thank you for your answer, but it didn't help so far, I've updated the question. ping fails even with $IFACE and so does ssh. There might be some L3 stuff going on, see mail stuff in the updated question. – Ondřej Grover Oct 08 '15 at 14:57
  • Obviously you don't have access to the server console, neither locally with plain old keyboard and monitor, nor with a virtual remote KVM ? And you know for sure that there's no IPTable layer 3 filtering on the serveur ? – CuriousFab Oct 08 '15 at 15:55
  • are you sure the arping answers you get are indeed sent by the server, and not by some other network device using that IP ? Can you verify that `$TARGET_MAC` matches the expected MAC address of this server ? – CuriousFab Oct 08 '15 at 16:00
  • Yes, I have no direct access to the server console. I'm waiting for physical access, but that might take a week or more. The $TARGET_MAC is indeed the expected MAC. I'll add this info to the question. I'm not entirely sure about the L3 layer though. In terms of arping it looks like there is none and other admins told me that it's the same L2 segment, but that mail thing suggests otherwise. Are there any other ways I could check for L3 components? – Ondřej Grover Oct 09 '15 at 06:18