Arpspoofing - internet connection error

Hi,

I am working on virtual box trying to do the arpspoofing, I achieved to have target laptop has the mac address of my kali machine as gateway. The problem is that there is no internet connection on the target machine (i got response when i ping the ip address of google, but i can’t open it using the browser)…
i put the ip forwarding to 1 but this has no effect on this issue.
Please advise.

Thank you

1 Like

Hi Learner,

Can you show us the result of:

  • ifconfig in Kali
  • ipconfig in the target machine
  • Kali network settings in Vbox

Thank you.

1 Like

Hi AJS,
Thank you for your response;
Please see below the requested information:

1- ifconfig:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.4 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00:27ff:fe7c:8e8e prefixlen 64 scopeid 0x20
ether 08:00:27:7c:8e:8e txqueuelen 1000 (Ethernet)
RX packets 34 bytes 5000 (4.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 28 bytes 2400 (2.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

2- ipconfig:
Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::c50d:519f:96a4:e108%8
IPv4 Address. . . . . . . . . . . : 10.0.2.15
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :10.0.2.1

3- Kali network setting:
image

Regards

Hi Learner,

Please flush all IP tables rules by iptables -F, then do the arpspoof:

arpspoof -i eth0 -t 10.0.2.1 10.0.2.15

In another terminal window:

arpspoof -i eth0 -t 10.0.2.15 10.0.2.1

Enable IP forwarding again

echo 1 > /proc/sys/net/ipv4/ip_forward

If the above didn’t work, then please try to create a new nat network for both of the virtual machines, and try it again:

Please remove the browsing data on the target browser before running the spoofer.

1 Like

Hi AJS,
Thank you,

It worked one time, but when i tried to do the same using my wlan0 adapter to arp spoof my laptop but it failed, and i can’t do it now again through the eth0 even i flushed all ip tables again and made sure that the IP forwarding is enabled.
Please advice.

thank you

Hi Learner,

Please disable the wired interface eth0, and make sure that only wlan0 is connected and have an IP address. Then do the ARP spoofing again. If you still have issues, then try to forget the target network from Kali and Windows, then connect them again, and see. You can also reboot the router from the router wen interface (you can enter the local IP address which is the 1st IP in the subnet if you want to access it), and see.

Thank you.

I know this is an old post, I have seen the same question over and over. And I have spent the last two days (on and off) fighting the same thing. I wanted to share my results in the event I could help someone else. My apologies its not the most recent, an argument could be the videos are getting dated and should be updated judging by some of the other replies I have seen to other questions.

I’m no pro, but I have fought through many of the problems I keep seeing on the forums over and over. This may get long winded, but that’s because it contains details that you may need to know, as well as some info to help you understand not just random commands to paste… Again, I’m just working through the course myself, and my answers may not be the best answers, but they worked for me after a lot of googling.

First, I haven’t gotten bettercap to downgrade HTTPS to HTTP yet, but I just started working on that, so I don’t have answers yet. I will be referring to ARP spoofing via arpspoof or bettercap and losing connectivity on the target machine, also, not actually making the ARP change.

My setup. ubuntu host computer, running vmware(licensed - not the free version). inside vmware running the custom kali provided by zaid. I am using an alfa USB 2.4 ghz wifi adapter on kali (that does indeed have all the bells and whistles needed - monitor mode, etc.). I have NOT tested using virtual ethernet.

I have 2 target PC’s. One is the host ubuntu pc, that is also connected to the same router (mine) via wifi (2,4 ghz band), and a windows 10 pc also connected to the same router via wifi (5ghz band)

enable promiscous mode on the interface adapter so you can change MAC:

First hurdle is when you try ARP spoofing in vmware (i’m doing this in vm ware remember using custom Kali build) you must configure the interface (i.e. wlan0) as promiscuous, otherwise vmware gets upset, and worse yet, nothing gets spoofed since vmware disallows the promiscuous command. I have not tried/or even installed virtualbox so I don’t know if there is a comparable hurdle in that software. In vmware I can only imagine the same happens for eth0. There are at least 2 ways to do it, one is by group and chmod permissions, the other is much simpler.
simpler version:

ifconfig wlan0 promisc

if you run ifconfig before and after you run that command you will see the first line of your interface change, adding PROMISC after you run it.

Example:
before → wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
after → wlan0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500

again, I imagine a similar thing needs done for eth0. The other way to allow prmiscuous mode I did not go into involves command like this:

chgrp your_user_group /dev/vmnet0
chmod g+rw /dev/vmnet0

for each device

chgrp your_user_group /dev/vmnet0
chmod g+rw /dev/vmnet0

or this for all groups

chmod a+rw /dev/vmnet0

feel free to google them to get a better feel for them and the level of security that is right for you, your changing network security with that command and it is persistent, so be careful. I chose the non-persistent version.

i imagine you can add a /dev/wlan0, I don’t know, I only used the chgrp method when I was trying eth0 for something once, never tried it for wlan0, so i don’t have personal experience and urge you to investigate on your own.

That should allow the ARP Spoof part to work, and actually change the gateway MAC on the target device if thats what your trouble was.

Now, if your losing internet connectivity on the target after you start an arp spoof either by using arpspoof or bettercap, this is what I encountered.

I was using wlan0 as I stated previously. I fired up wireshark and saw that the target machine was indeed sending info to my vm, but after that, things started breaking down. It pointed me to the forwarding mechanism. I found lots of stuff on the internet, but none of it worked. I tried some commands that started with sysctrl, I tried iptables until I was blue in the face. I still believe iptables would have worked had I don’t them correctly, but that I was doing iptables wrong. But there was a much simpler solution. I was using wlan0. My arpspoof and bettercap commands started like this:

bettercap -iface wlan0
arpspoof -i wlan0 -t 192.168.0.1 192.168.0.199

as it turns out, (and I didn’t see in wireshark because I filtered out eth0) was that the port forwarding was forwarding traffic to my eth0. I don’t know why, I don’t know how to change that. But I know how to stop it.

ifconfig eth0 down

if eth0 is off, kali stopped using it to port forward and could only forward to my wlan0, and it all worked. I view this as a work around, i wish I knew all the proper command to do this the ‘right’ way, but as I just started with linux a month ago, I haven’t learned this yet.

conversely, if your attempting an arp spoof on eth0, and you have other adapters plugged in, try turning those adapters off by:

ifconfig unused_adapter down

and see if it helps you.

1 Like

I ran into the exact same issue while testing arpspoofing and packet sniffing (Zaid’s Ethical Hacking and Python course). I have my Kali VM in bidged mode, connected to a wired network. The victim Windows 10 would have the arp table poisoned, by lost internet connectivity. This is what solved the problem for me.

i found that on my Kali VM, iptables was set to DROP the FORWARD chain. I did a iptables --policy FORWARD ACCEPT and everything worked fine from then on.
Hope this helps.
Note: I did not have ip forwarding set to true on my host machine.
IP forwarding was set to true on the Kali VM though.

On a NAT network, setting the Promiscuous Mode to “Allow All” solved it for me.