I wanted to see how many combinations of websites and browsers are still vulnerable to a tls stripping attack (like, by implementing HSTS or disabling cleartext HTTP altogether). To do it I wanted to see it firsthand by using the sslstrip tool, but I was unable to get it working (by following the instructions on the project page itself): the ARP spoofing apparently is working fine, since the target pc cannot browse anymore, but sslstrip doesn't receive anything.

I tried to listen with a TCP socket on the port redirected by iptables, but I received nothing, so I excluded also iptables, and now I'm just trying to receive connections directly on the port used by the victim client. I tried by both enabling and disabling ip forwarding (with /proc/sys/net/ipv4/ip_forward), and using wifi or ethernet as the interface from the attacking host, but nothing changes:

This is the command I'm using from the attacking host (address hostname macbook, a Linux 3.11 box):

sudo arpspoof -i eth0 -t

( is the gateway) and then

sudo socat TCP4-LISTEN:80 STDOUT

on the victim host (

socat - TCP4:

I can open the connection, but if I try anything, I don't receive anything on the attacking host (pointing socat to the attacker's ip address obviously works)

traceroute shows that apparently the ARP spoofing is successful:

> traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 macbook.local ( 2.719ms 5.932ms *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
28 * * *
29 * * *
30 * * *

arp -n output from the victim host

Address                  HWtype  HWaddress           Flags Mask            Iface             ether   00:1d:4f:fc:af:fc   C                     wlan0              ether   00:1d:4f:fc:af:fc   C                     wlan0
  • Please provide the output of "arp -n" on both gateway and victim. This will show is cache poisoning was successful at both hosts. Nov 22, 2013 at 6:09
  • I updated the post with the output from the victim you asked, the output from the gateway is not relevant (should it be?) since I'm not poisoning the gateway's arp... I'm just poisoning the victim's arp making it believe I'm the gateway... also: I'm not a security researcher and I'm new to this kind of thing: my setup was simply using my router (which is not powered by dd-wrt or the like) thus I cannot easily access its arp cache
    – berdario
    Nov 23, 2013 at 14:23

1 Answer 1


There's an IP collision going on. Although you've convinced that you're with the following command (meaning you've influenced its routing table):

sudo arpspoof -i eth0 -t

... the still thinks its, so when it sees arp requests for its own IP both your machine and the router will respond with a MAC address. The first MAC address received will be the one to get the packet (don't think that because you see an entry for your poisoned IP in arp -n that arp requests for that IP will necessarily cease). Also, it doesn't know NOT to send packets to the victim machine, or to respond to other packets that appear to come from that machine.

Typically, man-in-the middle is just that, "in the middle" so you should try the following:

sudo arpspoof -i eth0 -t

sudo arpspoof -i eth0 -t

The second one tells your router to send packets addressed to IP to you (rather than the original victim machine). If your victim machine gets a packet from the real with the real MAC address of that machine, do you know what it's behaviour will be? So it's best to avoid this possibility by redirecting any packets from the real destined to to you, since you're suppose to be in the middle.

  • Good answer. Would just like to add that this can actually be done with only one arpspoof command by specifying the -r flag. sudo arpspoof -i eth0 -r -t
    – Scaum
    Feb 25, 2020 at 14:54

You must log in to answer this question.

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