Running ettercap in vmware environment connections say "opening"

[meteordefect]

Hello, I am trying to run Ettercap 0.8.3.1 (EB) on Ubuntu 22.04 and it successfully finds the targets mac/ip's and runs the attack. Sometimes it works and sometimes it doesn't. 75% of the time the connections just say "opening" and the connection times out. Are there any tricks? Because it works 25% of the time, I know the setup should work.

• disabled IPV6 on all 3 machines
• ipv4 forwarding is enabled
• VMWARE ESXI 6.7
• tested with promisc mode enabled on card and vmware level

[koeppea]

It’s important that you don’t mess with ip_forward. Ettercap must be the only instance forwarding packets. Otherwise it’s competes with the Kernel.

[meteordefect]

Thanks for looking! I was forcing ipv4_forward on. Ok in this new test, I stopped messing with that entirely, removed it from my systctl.conf and restarted. I still seem to just get the "Opening" over and over again then it times out, any ideas?

[koeppea]

Can you please re-run it with -w /tmp/packets.pcap and provide the PCAP file?

[meteordefect]

Thanks here is the pcap while the issue was going on.

[koeppea]

where can I find (download) the PCAP file?

[meteordefect]

Sorry not sure why it did not attach.

captures.zip

[koeppea]

I've had a look at the packet capture.
First of all what's strange is that the MAC addresses in the packet capture are different from the screenshots above.
IP 192.168.200.40 has MAC ending on 9E:D4 while in the screenshot it ends on 98:B0
IP 192.168.200.129 has MAC ending on 9E:D3 while in the screenshot it ends on 98:B1
But this might be due to some other reason e.g. you might have rebuild the VMs.

The attacker seem to have a MAC ending on 9E:D5 in the packet capture.
It seems that there is something wrong with the ARP handling inside the VMWare Setup.
The ARP-Scan reveals that the MAC for 192.168.200.40 and 192.168.200.129 is responded with the MAC of the attacker itself.

This could be due to a certain VMWare related networking (optimization) setting or a networking setup other than Bridge.
Due to the false MAC information from the ARP Scan, the ARP poisoning goes completely crazy.

Something on your virtualized networking setup is doggy. Try to use one or two nodes of the game outside the VMWare host as "real" attached Ethernet members.

[koeppea]

Could also be something like Security Feature from VMWare protecting against ARP-Scans and therefore ARP poison-based MITM. However this goes beyond my expertise.

[meteordefect]

Thanks very much for looking at the captures. Immensely useful to get your insight.

Yes, I had to rebuild it to perform the test and set it up a little differently. VMware does have an ARP protection feature but it is switched off for this test.

I began to suspect that the OS itself not being rebooted after being placed in the new virtual network, and retaining entries from the local setup was causing the issue and testing along these lines. I will continue looking thanks mate :)