Reverse http and https broken about metasploit-framework HOT 11 CLOSED

seems to be working just fine for me. the STDAPI and other dlls take a bit to load especially over the Internet. Try 'getuid' a few times before giving up on it.
proof: http://pastie.org/private/8mdsyq7j6szhfxhucdwzeg

from metasploit-framework.

Something odd going on here - mine doesnt even do the checksum for the URI seen in your pastie (take a look). What're you running for env? I'm ruby 1.9.3-p194 with framework-dev. Which revision are you @?

from metasploit-framework.

1.8.7 and 1.9.2 and the latest revisions as of today

from metasploit-framework.

Ran this on 1.9.3-p125 and 1.9.3-p194, on different machines, using a fresh git clone of trunk. No dice on either machine, sometimes (on both) it will show itself addressing the URI checksum bit, but in all cases it's a dead session (no loaded libs, dead half of a socket pair). I'm running this across the WAN from an amazon box and port forwarding through the NAT at my edge.

from metasploit-framework.

Working scenario: routed network (cisco IPSEC VPN client), psexec a remote host with rev http/https, WinXP and 2k8r2 targets
Fail scenario: rev http/https over WAN link to forwarded port on provider firewall

from metasploit-framework.

After a deeper look, the problem is only on reconnect, not on the initial session. Reconnected sessions (orphaned) are not getting packets to the meterpreter dispatcher from the handler

from metasploit-framework.

Additional new (bad) behavior witnessed: initial connection flops when being pushed through a Forefront TMG app layer FW (http proxy). Need to do more testing on this, but it worked very well a couple of months ago. Behavior seen with http, https did not pass the FW @ all this time (not even a dummy session).

from metasploit-framework.

This got reported again by a Rapid7 user. I'll take another run at fixing this for the next weekly update.

from metasploit-framework.

Different issue (the Rapid7 report)

from metasploit-framework.

I seem to recall fixing something like this due to failed checksum in the reconnect URI. Is this still happening? Will close this soon if there's no response.

from metasploit-framework.

I'm certain this was resolved with http://dev.metasploit.com/redmine/issues/7350

Optimistically closing this.

from metasploit-framework.