Page 1 of 2 12 LastLast
Results 1 to 10 of 20
  1. #1
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default LogMeIn - Sessions Disconnect after 65seconds

    I hope I have this in the right section

    Never used to, but I'm now having issues with Untangle and LogMeIn after re-installing as Router Mode.

    I have had Untangle in Bridge mode for over a year with no issues.
    But my Linksys router crapped out on me.
    So I reloaded Untangle and made it into Router mode.

    Now, LogMeIn sessions from my house to any remote computer consistenly dis-connects the session after 65 to 70 seconds.
    Always the same amount of time till the LogMeIn session is disconnected.

    Tried different browsers, PC's, Mac's, iPod, rebooting, re-installing...
    Any LogMeIn session started from behind Untangle to the outside world will disconnect after 65 to 70 seconds.

    Never had this issue when it was in Bridge Mode.
    I have default setting applied for when it was a Bridge, and same now as a router.

    Since I work a lot from home, we use LogMeIn services to connect back.
    So it's a need, not a wish.

    Tried turning everything I could off and still got disconnected.

    Ended up going and buying another Router and removed Untangle... and everything works again

    I looked at the live sessions.... port 443 and 80
    And a random higher port number session in the 20,000's

    It's great to hear from people who say that they have Untangle and LogMeIn works great for them.
    But it would be more useful for ideas on solving, since it seems there's a few who are now effected.

    Thanks in advance for your help!

    Zeb

  2. #2
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,325

    Default

    I don't know if this will have anything at all to do with your problem, and I know little about LogMeIn (other than what it is), but I have seen behaviour like this when double-NATing a network. That is, when you connect one NAT router to another NAT router. I did this once by accident when putting a wireless router behind an ISP-supplied modem that was already doing NAT, and have run into it once or twice when it was done by someone else.

    So the question is then, did your untangle have a routable public IP on it's external interface?

  3. #3
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default

    No...

    When it was in Bridge Mode, it had a private IP, as given by the DHCP on the Linksys Router.

    In this new Router Mode, it is directly connected to my cable modem and the ext interface does have a public IP

  4. #4
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,325

    Default

    ah, yes, I meant when you had in router mode of course. well, that's the only thing that came to mind when you described your problem.

    maybe someone else has an idea then?

  5. #5
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default

    I did visit some of the LMI (LogMeIn) forums and see that others have issues with LMI disconnections behind different firewalls.

    Seems higher end firewalls use better methods than cheap home firewall/routers.
    I would like to believe that Untangle is a higher end firewall/router and is too good

    http://community.logmein.com/t5/Free...ht/true#M18906


    What I have gathered...
    LMI proxys thru LMI's Server to make the initial connection between the remote Host and you the Client.
    Then tries to pass the session from being proxies to a direct Host to Client session.

    It's in that handoff that the disconnection is happening.

    This helps explain more.... but still not a fix.

    Wondering is ICMP Redirect has anything to do with this?

    No guesses yet, since I do not know how Untangle processes handoffs

  6. #6
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default

    Re-enabled Untangle:

    ICMP-Redirect doesn't help solve anything... so I put it back to default.

    However, from the LMI link above, it had talked about port 1152 being used to talk to the LMI Server and used for the Direct Host to Client handoff.

    By blocking it, it does not allow LMI to make a handoff and forces the proxy between Host and Client to continue.



    Watched the live sessions and found it is using port 1152 and 1153
    I blocked them both, and so far the LMI session has not disconnected!

    So there's a patch... but not a fix.


    How or what needs to happen on the Untangle Box to allow the Handoff to happen without losing the session or compromising my computer by punching holes in Untangle to make it work?

    Any ideas?

  7. #7
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,325

    Default

    have you tried a bypass rule for ports 1152 and 1153?

  8. #8
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default

    No.

    Ports 1152 and 1153 are being used to begin UDP Hole Punching between the Host and Client (from what I have read and can watch)

    Shortly after that, I can watch a connection trying to be made dirctly to the HOST's NAT using random ports each time.

    The last one was port 545391
    But it changes every time....

    It looks more like Untangle does not allow UDP Hole Punching or there is a timeout that happens before the Handoff is completed.

    Bypassing the 1152 and 1153 only stops the process of starting the UDP Hole Punching.
    It seems to be the Hole Punching and handoff that are the issue.

    Block 1152 and 1153, and LMI gives up trying to establish a direct HOST to CLIENT connection and remains the Proxy between them,

    But at a scarifice of speed and latency (according to LMI's White pages)

  9. #9
    Untangle Ninja
    Join Date
    Jan 2011
    Posts
    1,325

    Default

    Quote Originally Posted by zebfink View Post
    Bypassing the 1152 and 1153 only stops the process of starting the UDP Hole Punching.
    It seems to be the Hole Punching and handoff that are the issue.

    Block 1152 and 1153, and LMI gives up trying to establish a direct HOST to CLIENT connection and remains the Proxy between them.
    In those two sentences you seem to be using Bypass and Block to mean the same thing? They're almost exactly opposite. I can't tell from the way you're wording it whether you have or have not tried Bypassing the LMI traffic on ports 1152 and 1153.

    edit: you would probably want to bypass the UDP traffic going both from and to those two ports
    Last edited by johnsonx42; 03-11-2011 at 12:02 AM.

  10. #10
    Untangler
    Join Date
    Apr 2010
    Posts
    39

    Default

    You're right.

    My reasoning is...
    If they are blocked, then no Direct connection process is started.
    And I can verify that process.

    I understand "ByPassing" to mean "do not apply any filtering"
    But since there is no filtering on those ports, I can watch them pass thru and also watch the start of the UPD Hole Punching of the two end devices trying to establish a direct connection via other random ports.

    But you are right in the fact that I have not actually tried to ByPassed them, because I'm not seeing them blocked or filtered... so I assumed there was not point.

    I could try though and test

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2