Arpspoof & packet forwarding

[burpsmirk]

Could anyone describe how to get packet forwarding to work for me? I had thought the process was pretty simple, and have followed the instructions of many similar tutorials. ie:

# echo "1" > /proc/sys/net/ipv4/ip_forward
# arpspoof -i eth0 -t 192.168.1.18 192.168.1.1

At this point the arp table on the .18 PC is correctly poisoned, and wireshark shows all its traffic flowing from .18 to the BackTrack PC, but the .18 PC gets no reply and its internet goes dead. I can't see traffic flowing back out of BT towards the default gateway in Wireshark, but I could maybe be mistaken there - maybe I shouldn't expect to.

All iptables chains (including the nat table) show default policies of "ACCEPT", and no rules are setup.

Ettercap manages to set up IP forwarding ok (and when it does, nothing appears to change in iptables), but I am just trying to understand the basics first, and I thought ip_forward = 1 was all that's required to get the kernel forwarding packets that wasn't its own to the default gw.

Must be something stupidly simple?

[gunrunr]

you have to also poison the ap as well as the client to do a two way arp poisoning.
so it would be like

arpspoof -t 192.168.1.18 192.168.1.1
arpspoof -t 192.168.1.1 192.168.1.18

otherwise the ap would not know to send packets back to you to forward to the client

[burpsmirk]

Never tried that, but still no luck. Both NIC's poisoned but no connectivity from .18 to the internet.

And I wouldn't have thought I would need 2-way poisoning... as far as I'm concerned, response traffic can go direct from the AP to the victim. It's what the .18 PC sends out I'm interested in. Or doesn't it work like that?

Cheers for your help

[burpsmirk]

So I've tried this now with BT5 R1 32bit, BT5 R1 64bit, and BT5 64bit, and tried swapping the to PC's round (so my .18 machine was the attacker).

Still the same.

What I have spotted though... in Wireshark, when I ping from the poisoned victim to the gateway, the MITM machine sees the ICMP coming in, and then Wireshark picks up a "Redirect (redirect to host)" packet, which is marked as from attacker back to victim. Almost as if the attacker is forwarding the victims packets to the wrong machine.

Attacker's arp table is good though, and default gateway is correctly set.

Surely I can't be the only person getting this wrong?! Any suggestions would be gratefully received.

[Eltanin]

I'm not sure if the OP ever figured out their problem, but I believe that I am having a similar issue. I hope that a reply to a dusty thread is acceptable instead of starting an entirely new one.

If I'm reading the OP's posts correctly, he successfully spoofed both target nodes but was having a hard time with the networking aspect. This is about where I'm at.

I can successfully poison the respective arp caches and can even get traffic routed and everything working, but only if I boot to BT5 (and/or BT5R1). If I run it from a VM (VMware player, Windows 7 x64, though the VMware image is naturally 32-bit), then the host OS gets in the way somehow. The target machine is spoofed, but traffic is not forwarded, resulting in a DoS instead of MitM. Bummer!

I've been trying to figure this out for quite some time and I'm beating my head against the wall.

I've got my virtual machine set to Bridged networking and I've tried with and without the "Replicate physical network connection state" checkbox (what does that even do?). I can browse the web and all sorts of other stuff, but the MitM doesn't work from a VM. Presumably because the host machine knows where the default gateway is? Hmmm. Maybe I need to do a triple poison? Gateway, target, and my host OS?

I appreciate any replies.

[aeronavi]

When you running virtualmachine what your victim sees isn't your virtual MAC address but the mac address of the host card. It happens then that your host system whenrecieve the reply, drop/forwards packet to real gateway. So packet doesnt arrive to your virtualmachine. You may try to spoof the host too, it may work that way.