0

An EDIT was made at the bottom

I have a macbook on 192.168.12.x subnet, and a debian machine with apache2 server with ssh enabled sitting on 192.168.1.x subnet.

The debian machine has a static IP address that's given from the router (192.168.1.30).

When I try to ping from macbook, it gives

$ ping 192.168.1.30

PING 192.168.1.30 (192.168.1.30): 56 data bytes

Request timeout for icmp_seq 0

92 bytes from 192.168.1.1: Redirect Host(New addr: 192.168.1.30)

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

 4  5  00 0054 4784   0 0000  3f  01 a4fc 192.168.12.186  192.168.1.30 


Request timeout for icmp_seq 1

92 bytes from 192.168.1.1: Redirect Host(New addr: 192.168.1.30)

Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst

 4  5  00 0054 a817   0 0000  3f  01 4469 192.168.12.186  192.168.1.30 

....

^C

--- 192.168.1.30 ping statistics ---

5 packets transmitted, 0 packets received, 100.0% packet loss

If I try ssh...

$ssh -v [email protected]

 OpenSSH_6.9p1, LibreSSL 2.1.7

 debug1: Reading configuration data /Users/Sean/.ssh/config

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 20: Applying options for *

debug1: /etc/ssh/ssh_config line 102: Applying options for *

debug1: Connecting to 192.168.1.30 [192.168.1.30] port 22.

debug1: connect to address 192.168.1.30 port 22: Operation timed out

ssh: connect to host 192.168.1.30 port 22: Operation timed out

From Debian machine, if I do /sbin/route,

# /sbin/route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    1024   0        0 eth0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0

and /sbin/iptables -L gives

# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     icmp --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere

As you may see, I tried to make some rules from iptables to open ssh port (22) and accept ICMP packets, but it didn't help.

I also followed this to unblock icmp from /etc/sysctl.conf.

It almost looks like there's no way to route from 192.168.12.x to 192.168.1.x, but I'm certainly sure that there has to be a way because everything is on the same network.

I don't know much about setting the network so this question may be silly, but hopefully I can learn from some valuable feedbacks from here. Please let me know if there's anything I can try to route them correctly.

Thank you.

EDIT: route table from Macbook

$ netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.12.1       UGSc         1055       14     en0
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              3  5933121     lo0
169.254            link#5             UCS             3        0     en0
169.254.156.168    link#5             UHLSW           1        0     en0
169.254.194.185    link#5             UHLSW           1        0     en0
192.168.12         link#5             UCS            39        0     en0
192.168.12.1/32    link#5             UCS             2        0     en0
192.168.12.1       a0:ec:f9:82:cb:d8  UHLWIir      1056     6720     en0   1198
192.168.12.3       link#5             UHLWIi          1        0     en0
192.168.12.4       link#5             UHLWIi          1        0     en0
192.168.12.5       c0:56:27:68:f5:33  UHLWIi          1     6397     en0    924
192.168.12.13      link#5             UHLWIi          1        1     en0
192.168.12.15      link#5             UHLWIi          1        0     en0
192.168.12.17      link#5             UHLWIi          1        9     en0
192.168.12.30      link#5             UHLWIi          1        3     en0
192.168.12.38      78:7e:61:54:78:68  UHLWIi          1        0     en0    524
192.168.12.47      64:76:ba:b6:24:6a  UHLWIi          1        0     en0    846
192.168.12.50      84:fc:fe:db:6c:77  UHLWIi          1        0     en0    251
192.168.12.52      b8:8d:12:e:33:7c   UHLWIi          1        8     en0    942
192.168.12.116     74:e5:b:81:9c:12   UHLWIi          1       13     en0    436
192.168.12.141     link#5             UHLWIi          1        6     en0
192.168.12.154     link#5             UHLWIi          1        0     en0
192.168.12.168     link#5             UHLWIi          1        0     en0
192.168.12.169     link#5             UHLWIi          1        0     en0
192.168.12.173     link#5             UHLWIi          1        0     en0
192.168.12.186/32  link#5             UCS             1        0     en0
192.168.12.188     link#5             UHLWIi          1       10     en0
192.168.12.194     link#5             UHLWIi          1       12     en0
192.168.12.196     link#5             UHLWIi          1        0     en0
192.168.12.199     e8:b1:fc:ab:1d:78  UHLWIi          1        0     en0   1056
192.168.12.200     48:5a:b6:6b:7a:5d  UHLWIi          1      619     en0   1100
192.168.12.209     link#5             UHLWIi          1        6     en0
192.168.12.211     5c:51:4f:9c:32:54  UHLWIi          1        0     en0   1198
192.168.12.213     0:24:d7:10:e9:ec   UHLWIi          1        0     en0   1161
192.168.12.214     link#5             UHLWIi          1        0     en0
192.168.12.215     link#5             UHLWIi          1        0     en0
192.168.12.218     link#5             UHLWIi          1        0     en0
192.168.12.221     link#5             UHLWIi          1        0     en0
192.168.12.222     5c:c5:d4:f9:1c:9e  UHLWIi          1        0     en0    909
192.168.12.224     link#5             UHLWIi          1        6     en0
192.168.12.228     9c:4e:36:3b:6c:54  UHLWIi          2        0     en0    702
192.168.12.229     link#5             UHLWIi          1        0     en0
192.168.12.230     90:4c:e5:e4:8:dc   UHLWIi          1        0     en0    446
192.168.12.236     link#5             UHLWIi          1        0     en0
192.168.12.238     link#5             UHLWIi          1        0     en0
192.168.12.240     a8:86:dd:b5:49:5d  UHLWIi          1       41     en0   1184
192.168.12.255     link#5             UHLWbI          1     4358     en0
192.168.56         link#12            UC              3        0 vboxnet
192.168.56.255     link#12            UHLWbI          1      841 vboxnet

EDIT2

It's weird that when I restart 12.30 machine, it accepts SSH connection for a few seconds (I can log in and browse through directories), and immediately few seconds after, it start redirecting. ping works the same way. Few first one or two packets, I get response back < 10ms, but after that I get the same redirect (new addr:...) message.

Is it possibly the router setting?? (VLan is enabled).

Also, I can ping from 12.30 to 1.186 without any problem. nvm. It does the same thing. Only able to ping for a few seconds. It's a little bit longer time.. :p But after that, it shows Destination Host Unreachable message

Improve this question
5
  • Routing table for your Macbook too, please.
    – Chris Davies
    Nov 10, 2015 at 0:40
  • Can you ping or ssh to the server from the router?
    – jftuga
    Nov 10, 2015 at 0:55
  • @jftuga this will sound stupid, but how can you ping FROM router? is there any console I can use?
    – Saehun Sean Oh
    Nov 10, 2015 at 0:56
  • by the way, internet connection of the 192.168.1.30 machine works perfectly fine.
    – Saehun Sean Oh
    Nov 10, 2015 at 0:57
  • Since it is a cisco router, you can ssh into the router itself and it has a cmd line interface where you can execute a ping command.
    – jftuga
    Nov 10, 2015 at 0:57

2 Answers 2

Reset to default
0

If you have followed the link you provided to reconfigure ICMP redirections, you need to revert the changes. That document explains how to disable processing of ICMP redirects, whereas in your configuration you need to accept them.

This is because you are running two subnets on the same physical network. The router can therefore send a redirect to your Macbook telling it that the Debian server is on the same LAN and can be reached directly. The Debian server, on the other hand, will try to route responses back via its default gateway (your router). The router will again send a redirect telling the server that the Macbook is on the same LAN but if the Debian server is configured to ignore those ICMP redirects, the packets will simply get dropped on the floor.

Improve this answer
3
  • I will revert the changes and come back shortly. Thank you for the suggestion and explanation.
    – Saehun Sean Oh
    Nov 10, 2015 at 0:59
  • I made sure all changes were reverted so now net.ipv4.conf.eth0.accept_redirects = 1 and net.ipv4.conf.eth0.send_redirects = 1 entries are correctly configured. However, it still gives the same issue.
    – Saehun Sean Oh
    Nov 10, 2015 at 1:08
  • What's even more weird is if I restart the machine with 1 subnet, it would accept very first packet from Macbook, but it again redirects so leads to Broken pipe error :/
    – Saehun Sean Oh
    Nov 10, 2015 at 1:26
0

It's possible I'm missing something, but seems to me that you need to add a route on the mackbook for 192.168.1.0/24 and on the debian machine for 192.168.12.0/24.

run route add -net 192.168.12.0 netmask 255.255.255.0 gw 192.168.1.1 dev eth0 on the debian machine

and route -n add 192.168.1.0/24 192.168.12.1 on the macbook (unable to test, copypasta from here)

Improve this answer
1
  • Thank you for the suggestion, but it didn't work :'(
    – Saehun Sean Oh
    Nov 10, 2015 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .