This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TCP retransmissions when attempting to access Plex by one client

I'm having an issue with one user attempting to stream content from a Plex media server.  Other external clients can access this host fine and are using the same ports, etc.  This is affecting multiple devices on this clients network (2x roku's and a PC) however doesn't affect this client when they are outside this one particular network.  This just started happening about 2 weeks ago, before that, all was well for this user.

Everything is pointing to his network/ISP doing something (or not doing something) however I want to confirm I'm not missing anything at the UTM.  

I've reviewed rule #1 and I only see firewall traffic from this host saying NAT rule #3 is being obeyed which is consistent with what I would expect as that is the NAT rule that forwards traffic to the internal Plex server.

I ran a packet capture on the Plex server, one from a known good client and one from the affected client.  In the affected client's pcap I see retransmissions and not really anything else.

##.##.1.58 = Plex internal IP
##.##.80.19 = Affected client
##.##.20.32 = Working client

Image attached for failing Plex connection (not-working-client.jpg)


Image attached for working Plex connection (working-client.jpg)


Unfortunately this user is remote and not technical so reviewing logs on that side is almost not possible.

From the Plex server logs, it looks like the client never establishes the connection (nothing logged). 

One odd (not really) thing is that my public IP address ends in .255 which is normally reserved for broadcast in a /24 network but my ISP is using a /20 network so its a valid address.  Could this be causing issues?

What am I missing?  Could the UTM be causing the retransmissions or is this squarely on the remote side?


This thread was automatically locked due to age.
  • Hi, CR and welcome to the User BB!

    This is almost certainly the client.

    Cheers - Bob
    PS Honestly, I didn't look at those externally-hosted images. Please [Edit] that post, delete your external links, click on [Go Advanced] and attach your images to the post. We can't know if that external site is properly protected. The only malware I've gotten in over 10 years was from an external link to a picture in this forum several years ago.
  • Hi, CR and welcome to the User BB!

    This is almost certainly the client.

    Cheers - Bob
    PS Honestly, I didn't look at those externally-hosted images. Please [Edit] that post, delete your external links, click on [Go Advanced] and attach your images to the post. We can't know if that external site is properly protected. The only malware I've gotten in over 10 years was from an external link to a picture in this forum several years ago.


    Thanks Bob.  I've edited the original post with the attached images.  

    While I agree, I also really know nothing about packet captures or the network layer so I am really hoping for another set of eyes.
  • If it's not the client, it's the network between the two of you.  What do you see if you do a tracert from your PC to his IP?

    Cheers - Bob
    PS Thanks for making that change.  This is a Security community, so hopefully that's the only thing we're uptight about. [;)]
  • Goes for a bit then apparently never completes.  Could be that the destination is not responding to trace routes or maybe UDP trace routes?

    $ traceroute ##.###.80.19
    traceroute to ##.###.80.19 (##.###.80.19), 64 hops max, 52 byte packets
     1  www.########.net (10.10.1.1)  0.822 ms  0.619 ms  0.447 ms
     2  * * *
     3  172.30.67.217 (172.30.67.217)  11.656 ms  15.341 ms  15.630 ms
     4  172.30.24.121 (172.30.24.121)  10.089 ms  11.517 ms  10.355 ms
     5  12.249.235.5 (12.249.235.5)  10.092 ms  10.496 ms  9.886 ms
     6  cr81.mpsmn.ip.att.net (12.122.132.202)  23.178 ms  20.800 ms  19.402 ms
     7  cr2.cgcil.ip.att.net (12.122.153.6)  22.575 ms  20.228 ms  23.444 ms
     8  gar13.cgcil.ip.att.net (12.122.132.121)  22.513 ms  23.614 ms  23.938 ms
     9  ae3.chi11.ip4.gtt.net (173.241.128.29)  23.859 ms  27.298 ms  24.657 ms
    10  xe-9-0-0.was14.ip4.gtt.net (141.136.111.82)  42.106 ms  40.240 ms
        xe-1-1-0.was14.ip4.gtt.net (141.136.111.30)  42.294 ms
    11  cequel-gw.ip4.gtt.net (216.221.157.174)  40.261 ms  41.715 ms  39.958 ms
    12  173-219-253-235.suddenlink.net (173.219.253.235)  49.486 ms  48.185 ms  63.532 ms
    13  173-219-228-62.suddenlink.net (173.219.228.62)  71.149 ms
        173-219-253-120.suddenlink.net (173.219.253.120)  61.479 ms  61.835 ms
    14  * * 173-219-253-65.suddenlink.net (173.219.253.65)  49.740 ms
    15  * * *
    16  * * *
    17  * * *
    18  * * *
    19  * * *
    20  * * *
    21  * * *
    22  * * *
    23  * * *
    24  * * *
    25  * * *
    26  * * *
    27  * * *
    28  * * *
    29  * * *
    30  * * *
    ...
    64  * * *
    $
  • It appears it stops 4 hops sooner.


    hop rtt rtt rtt   ip address fully qualified domain name
    1 0 0 0   208.101.16.73 208.101.16.73-static.reverse.softlayer.com
    2 0 0 0   66.228.118.153 ae11.dar01.sr01.dal01.networklayer.com
    3 0 0 0   173.192.18.210 ae6.bbr01.eq01.dal03.networklayer.com
    4 * * *  
    5 43 44 43   173.219.221.99 173-219-221-99.suddenlink.net
    6 * * *  
    7 * * *  
    8 * * *  
    9 * * *  
    Trace aborted

    -- end --
  • From you, it died at:
      173-219-253-65.suddenlink.net (173.219.253.65)

    From CentralOps, it died at a spot that didn't even appear  the other traceroute:
      173.219.221.99 173-219-221-99.suddenlink.net

    If the client's IP is inside the SuddenLink network, it would appear that SuddenLink has an issue.

    Cheers - Bob
  • The client is within the suddenlink network.  Thanks for your help. Much appreciated!
  • From you, it died at:
      173-219-253-65.suddenlink.net (173.219.253.65)

    From CentralOps, it died at a spot that didn't even appear  the other traceroute:
      173.219.221.99 173-219-221-99.suddenlink.net

    If the client's IP is inside the SuddenLink network, it would appear that SuddenLink has an issue.

    Cheers - Bob


    So I did a little more troubleshooting.

    I put an old Linksys router in place of my UTM and access was restored to the client.  Two things changed.

    1) My IP address changed when I swapped out the new router.
    2) No more Sophos

    It appears something is going on either with how Sophos UTM is responding OR how the client, sophos or both are dealing with my IP that is ending in 255.

    My ISP says the IP is dynamic and can't be "changed".  I've attempted to renew the IP via Sophos and also attempted to power and unplug the cabled modem down with the hopes it pulls a new IP.  No luck.

    The other side is that Sophos is doing something wrong and either, I can't find the right log, its not logging it, or its a bug.  I've reverted the configs back to a known working date, no change in behavior.  The only thing I haven't done is rebuild an older firmware version and see if that fixes it.

    Any thoughts?
  • So I did a little more troubleshooting.

    I put an old Linksys router in place of my UTM and access was restored to the client.  Two things changed.

    1) My IP address changed when I swapped out the new router.
    2) No more Sophos

    It appears something is going on either with how Sophos UTM is responding OR how the client, sophos or both are dealing with my IP that is ending in 255.

    My ISP says the IP is dynamic and can't be "changed".  I've attempted to renew the IP via Sophos and also attempted to power and unplug the cabled modem down with the hopes it pulls a new IP.  No luck.

    The other side is that Sophos is doing something wrong and either, I can't find the right log, its not logging it, or its a bug.  I've reverted the configs back to a known working date, no change in behavior.  The only thing I haven't done is rebuild an older firmware version and see if that fixes it.

    Any thoughts?


    Well I used the "virtual MAC address" feature and changed my device hardware address to force a new IP.  ISSUE GONE!

    Apparently something on either of our ends or a router in between that couldn't deal with the .255/20 IP address and was failing to make a connection.  Once the IP changed to something other than .255, everything works as expected.