TiVo Says Port 8080 Closed. Tools to Check?

[beremonavabi]

For the last couple of months, I've been running my TiVo without problem through AirVPN on my SG-4860.  Yesterday, the TiVo started complaining it was running out of Guide data.  When I checked, it hadn't been able to connect successfully for a while.  It now thinks port 8080 is being blocked.  I pulled the TiVo out from using the VPN and it has no problem.  Putting it back through the VPN causes it to again complain about port 8080 is being blocked and it won't connect.  My pfSense box is set to not block any outgoing stuff.  Ditto for traffic on the local network.  According to:

http://www.cox.com/residential/support/internet/article.cox?articleId={cacf82f0-6407-11df-ccef-000000000000}

Cox (my ISP) doesn't block port 8080.  And, according to:

https://support.tivo.com/articles/Troubleshooting/Which-Network-Ports-and-IP-Addresses-Need-to-be-Open-When-Using-my-TiVo-DVR

the TiVo needs no open incoming ports.  Also, it doesn't complain about any of the other ports that need to be open for outgoing traffic (or within the local network) as being closed.

Are there any tools (hopefully, those a newb can use) I can use to try to see if something is blocking port 8080 on my network?  I've attached a screenshot of my firewall rules for the interface the TiVo (and, basically, everything else) is on.

[Derelict]

If it is being routed out the VPN, Cox has nothing to do with it.

Look at states on 8080 while you try to connect.

Maybe packet capture on OpenVPN on port 8080 while you try to connect and see what is there.

Maybe set something up on the outside to listen on 8080 and try to connect to it.

[beremonavabi]

Good idea to check the state table.  I'd checked the logs, but there's nothing.  Here's what shows up in the state table during a connection attempt:

States
Interface	Protocol	Source (Original Source) -> Destination (Original Destination)	State	Packets	Bytes	
VPN_LAN	tcp	192.168.20.6:60422 -> 208.73.181.202:8080	TIME_WAIT:TIME_WAIT	1 / 1	60 B / 40 B	
VPN2_WAN	tcp	10.8.0.214:55750 (192.168.20.6:60422) -> 208.73.181.202:8080	TIME_WAIT:TIME_WAIT	1 / 1	60 B / 40 B	

192.168.20.6 is my TiVo
208.73.181.202 is on the list of TiVo's servers
10.8.0.214 is that VPN WAN interface's address

So, it looks like the traffic is at least leaving my system.  I'll try to figure out something with a packet capture.

[beremonavabi]

Here's a packet capture for port 8080 on that OpenVPN client:

17:35:15.115962 IP 10.8.0.214.30048 > 208.73.181.202.8080: tcp 0
17:35:15.129437 IP 208.73.181.202.8080 > 10.8.0.214.30048: tcp 0

And, here's one for the TiVo's IP address and port 8080 on the local VPN interface:

17:40:51.048594 IP 192.168.20.6.60503 > 208.73.181.202.8080: tcp 0
17:40:51.063299 IP 208.73.181.202.8080 > 192.168.20.6.60503: tcp 0

And, just for grins, here's one for the TiVo's IP address and port 8080 on the local VPN interface while the TiVo's doing its port diagnostics and saying port 8080 is closed:

18:06:24.626166 IP 192.168.20.6.60600 > 208.73.181.202.8080: tcp 0
18:06:24.642865 IP 208.73.181.202.8080 > 192.168.20.6.60600: tcp 0

I'm 99.99% clueless, but to me, that looks like during the diagnostics, port 8080 is working fine and during a download something went there and back again involving port 8080.  I guess that means this isn't related to pfSense at all.  Heck, it doesn't even look like it's related to the VPN.

[Derelict]

That looks like good two-way traffic - at least from something.

[beremonavabi]

Anyone know what the time codes in those packet captures mean?  The first three parts are obviously hours, minutes, and seconds.  But, is the last part millionths of a second?

[Derelict]

Yeah, 6 decimal places is milliseconds.

[beremonavabi]

Thanks.  I couldn't find anything saying that that final clump of numbers was some kind of fractional second or something else entirely.

BTW:  10^(-6) seconds is actually microseconds:

https://en.wikipedia.org/wiki/Microsecond

A millisecond is a thousandth of a second.

[Derelict]

right

[jimp]

If I had to guess, I'd say TiVo is blocking access from the VPN provider.

Especially if it works fine from your regular network.

Mine don't seem to do anything fancy with the traffic that leaves my network, nothing I'd expect to break that way at least. But they are a bit strict with region stuff so it would not surprise me to hear they block known VPN/Proxy providers.

[beremonavabi]

I, too, am guessing TiVo has somehow started blocking access via VPN.  I've reported this on the TiVoCommunity forum:

http://www.tivocommunity.com/community/index.php?threads/tivo-bolt-thinks-port-8080-closed.551422/#post-11242891

and to TiVo (corporation), itself.  But, so far, nothing.  It's just odd that the sole check that's (supposedly) failing is the one for port 8080 instead of something more general.

I've worked around it by simply adding a firewall rule to have all traffic coming from my TiVo go through the WAN instead of the VPN interface.  That's not really what I want to do, but it works.

[Derelict]

I was forcing a tivo through an OpenVPN that egresses from AWS Oregon until about a week ago and it worked fine for geo-shifting MLB.Tv. Probably just a matter of time. (Don't have the tivo any more.)

Didn't try any other streaming services and tivo updates seemed to be fine.

Hard for me to fathom why tivo would care where you get updates from. The streaming apps all have their own enforcement methods I would think.

You could tailor the rule to only put traffic sourced from the tivo and destined for port 8080 out WAN.