Ubuntu not replying to ARP requests

Question

I experience a behavior on my linux machine that I cannot explain. I see incoming ARP requests but they are not answered by my machine. When I plug the Ethernet cable into a Windows 10 machine those ARP requests are being answered.

I also noticed that I cannot capture the traffic on this device when I try to nmap the target 192.168.1.106. I see incoming ARP requests but no outgoing packets at all. When I switch the target (and the interface) I do see outgoing traffic from nmap. I do not know whether this has something to do with the ARP issue. I just had this idea because without an ARP response how is a nmap scan supposed to work...

I have a Ubuntu 16.04 machine with a few interfaces. I set the IPs for those myself. The device sending out ARP requests is connected to the enp0s25 interface. The output of the ifconfig command produces this:

enp0s25   Link encap:Ethernet  HWaddr b0:5a:da:ee:38:cd  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::3f90:bbf0:85e2:6423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:603 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:404096 (404.0 KB)  TX bytes:50704 (50.7 KB)
          Interrupt:20 Memory:d2100000-d2120000 

enx00249b1963d4 Link encap:Ethernet  HWaddr 00:24:9b:19:63:d4  
          inet addr:192.168.1.99  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5ecb:670e:5bd1:7ac1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:393532 errors:0 dropped:0 overruns:0 frame:0
          TX packets:393429 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:19874193 (19.8 MB)  TX bytes:30957637 (30.9 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:141121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:141121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7408865 (7.4 MB)  TX bytes:7408865 (7.4 MB)

wlp61s0   Link encap:Ethernet  HWaddr a4:c4:94:5c:a3:aa  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2600:1007:b000:743e:265b:1fb5:bb6c:2e5/64 Scope:Global
          inet6 addr: fe80::e5a4:4dcb:ed06:e981/64 Scope:Link
          inet6 addr: 2600:1007:b00e:643d:244c:2307:f4ac:1b16/64 Scope:Global
          inet6 addr: 2600:1007:b000:743e:244c:2307:f4ac:1b16/64 Scope:Global
          inet6 addr: 2600:1007:b00e:643d:c233:8501:765e:d4f6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14764 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6658 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13720070 (13.7 MB)  TX bytes:822384 (822.3 KB)

When I set up tcpdump this is a snippet of the output:

14:58:49.666404 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:50.676781 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:52.666512 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:54.666590 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:55.676786 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:57.666634 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:59.666768 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:00.676963 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:02.666846 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:04.666932 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:05.677240 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:07.667045 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:09.667172 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42

I have already done some research but could not find (or understand) what I need to solve my problem. If that helps this is the output of the commands ip rule show and ip route show table local. I found this on another question on this site but I was not able to use this information.

john@john:~$ ip rule show
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
john@john:~$
john@john:~$
john@john:~$ ip route show table local
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlp61s0  proto kernel  scope link  src 192.168.1.2 
broadcast 192.168.1.0 dev enx00249b1963d4  proto kernel  scope link  src 192.168.1.99 
broadcast 192.168.1.0 dev enp0s25  proto kernel  scope link  src 192.168.1.100 
local 192.168.1.2 dev wlp61s0  proto kernel  scope host  src 192.168.1.2 
local 192.168.1.99 dev enx00249b1963d4  proto kernel  scope host  src 192.168.1.99 
local 192.168.1.100 dev enp0s25  proto kernel  scope host  src 192.168.1.100 
broadcast 192.168.1.255 dev wlp61s0  proto kernel  scope link  src 192.168.1.2 
broadcast 192.168.1.255 dev enx00249b1963d4  proto kernel  scope link  src 192.168.1.99 
broadcast 192.168.1.255 dev enp0s25  proto kernel  scope link  src 192.168.1.100

It would help if your ethernet and wireless were in different networks. It would also probably help saying you are in kali faking the MAC of the wifi chip. — Rui F Ribeiro, Aug 21 '18 at 19:37
I tried that but it seems like the IPs got reset. Now that you are saying that I should look into why this happened and whether I can find a permanent solution. And it is indeed Ubuntu, but I installed macchanger on it. How could you see that? UPDATE: I put all three adapters in different networks but still the same behavior — JRsz, Aug 21 '18 at 19:42
Having multiple interfaces in the same LAN never behaves as expected by default: usually only one interface will handle all traffic for all IPs. See related answer there: https://serverfault.com/questions/900385/ghost-ping-on-a-multi-nic-linux-system/900958#900958 — A.B, Aug 21 '18 at 20:29
Unix Wizards have special crystall balls so I know you are using MacChanger :) On a serious note, changing MACs can give you temporary network problems, and some cards/drivers do not like when you change the manufacturer ID MAC part. I advise you adding that large detail to the question. — Rui F Ribeiro, Aug 21 '18 at 20:29

Rui F Ribeiro · Answer 1 · 2018-09-10T09:01:17.190

So trying to tackle the several technical aspects of your question.

The biggest technical problem is having the same netblock on your two ethernet and your one wifi network interfaces. That will mess up your routing.

I also see you seem to be shifting too fast between MAC addresses in the wifi interface. That will interfere with your current connections (and shut down them).

As wifi is authenticated, once you spoof a new MAC address, you have to take down your interface (before spoofing), and put it up again (after spoofing), going again by all the authentication process with the new MAC address. Otherwise, the AP with stop dealing with you as it does not know your interface as being authenticated.

Caveats: on some equipments/setup/brands it is necessary to wait a while or repeat the process a couple of times with the same new MAC, for the old MAC to be out of the picture (caches, others). In some more rarer wifi drivers, the driver might not like if you change the first three bytes of the MAC address that identify the brand of the wifi, so you are only able to spoof the lower three bytes.

Furthermore, your IPv6 addresses are bleeing to the outside your MAC addresses. As your provider is giving IPv6 and you are already assuming several IPv6 addresses, this will give you problems, as in Linux, IPv6 by default takes precedence over IPv4. Furthermore, such bleeding will quickly let any network administrator pick up you are up to no good. A possible work around is disabling IPv6 altogether while you are spooing MAC addresses.

Aditionally, the name of your interface denotes you are using a realtek based-chipset. While cheap, their quality is low, and they are know to give connection stability problems. Certain models of ralink or atheros are much better for this kind of activities. see related Wi-Fi problems using ASUS USB-N13 adapter

PS. Obviously, there are no crystal balls. It is due to a set of clues put together that point out the kind of activities your system is up to. I advise trying to understand better what are the consequences of using less well behaved utilities for doing more obscure operations.

I am quite busy currently but I will definitely look into your answer once I find a bit of time again. Thank you already and I will come back to you! — JRsz, Aug 23 '18 at 20:11

Ubuntu not replying to ARP requests

1 Answers1