I've spent a lot of time with Vudu tech support about this and I now agree that there is something fishy about the FiOS connection to Vudu.
(as backgroound I'm a network engineer by trade so know my way around tcp/ip connections)
Suddenly a couple months ago my LG blu-ray player stopped being able to connect to Vudu. Computer wsa OK but not the LG. After much back and forth with their tech support they concluded (bold added by me):
Lately Verizon has been pushing DSL folks to opt-out of a Carrier Grade NAT setup, which in essence can act as a "proxy" of sorts in a sense that many (hundreds) users come from a common IP address. This shouldn't apply to FiOS, but it may be something to consider if Verizon has recently started to take advantage of CGNAT.
Away from that, would it be possible to share the traceroute results? I've never seen proxy-like behavior even on my DSL connection, which has been opted out of Carrier Grade NAT since I use applications that will break behind CGNAT. When sharing the traces, please filter out anything sensitive so the moderators don't have to do it for you. Alternatively, you can send me an unedited trace via PM so it isn't floating around on the public forums.
Also, I'm sure you've checked all of this already, but please be sure to verify the Blu-Ray player or other devices on your network are not going through a proxy, or are set up behind a VPN or IPv6 tunnel.
Sure! Posted at bottom.
Definately no VPN, tunnel or proxy on my site.
I wonder if the http header the LG sends out identifies it as an appliance versus a PC and Verizon senses that and sends it to a video caching farm.
[balderdash:~] john% traceroute llgvault.vudu.com
traceroute to vudu.re.llnwd.net (126.96.36.199), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.668 ms 0.391 ms 0.371 ms
2 l100.washdc-vfttp-115.verizon-gni.net (188.8.131.52) 12.586 ms 6.955 ms 7.454 ms
3 g0-8-3-2.washdc-lcr-22.verizon-gni.net (184.108.40.206) 7.842 ms 7.442 ms 24.731 ms
4 ae0-0.res-bb-rtr1.verizon-gni.net (220.127.116.11) 19.851 ms 42.489 ms 7.380 ms
5 0.xe-8-3-0.xl2.iad8.alter.net (18.104.22.168) 7.523 ms 7.290 ms 7.627 ms
6 0.xe-11-3-1.gw9.iad8.alter.net (22.214.171.124) 7.360 ms
0.xe-11-0-1.gw9.iad8.alter.net (126.96.36.199) 6.378 ms
0.xe-11-1-1.gw9.iad8.alter.net (188.8.131.52) 11.516 ms
7 llnw-gw.customer.alter.net (184.108.40.206) 9.521 ms 17.072 ms 17.279 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * *^C
[balderdash:~] john% traceroute llpvault.vudu.com
traceroute: Warning: llpvault.vudu.com has multiple addresses; using 220.127.116.11
traceroute to vudu-p.vo.llnwd.net (18.104.22.168), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.686 ms 0.380 ms 0.380 ms
2 l100.washdc-vfttp-115.verizon-gni.net (22.214.171.124) 14.362 ms 7.338 ms 7.878 ms
3 g0-8-2-0.washdc-lcr-21.verizon-gni.net (126.96.36.199) 27.400 ms 9.419 ms 10.287 ms
4 so-7-1-0-0.res-bb-rtr1.verizon-gni.net (188.8.131.52) 7.802 ms 9.530 ms 10.226 ms
5 0.xe-5-0-1.xl1.iad8.alter.net (184.108.40.206) 9.823 ms 10.146 ms 9.510 ms
6 0.xe-10-0-0.gw9.iad8.alter.net (220.127.116.11) 10.567 ms
0.xe-8-2-0.gw9.iad8.alter.net (18.104.22.168) 9.261 ms
0.xe-10-3-0.gw9.iad8.alter.net (22.214.171.124) 10.040 ms
7 llnw-gw.customer.alter.net (126.96.36.199) 12.165 ms 15.381 ms 9.621 ms
8 ve5.fr4.iad.llnw.net (188.8.131.52) 9.780 ms 17.248 ms 9.636 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
[balderdash:~] john% traceroute lldvault.vudu.com
traceroute: Warning: lldvault.vudu.com has multiple addresses; using 184.108.40.206
traceroute to vudu-rd.vo.llnwd.net (220.127.116.11), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.689 ms 0.414 ms 0.443 ms
2 l100.washdc-vfttp-115.verizon-gni.net (18.104.22.168) 7.813 ms 9.521 ms 8.112 ms
3 g0-8-3-2.washdc-lcr-22.verizon-gni.net (22.214.171.124) 26.827 ms 14.956 ms 7.644 ms
4 ae2-0.res-bb-rtr1.verizon-gni.net (126.96.36.199) 15.013 ms 89.626 ms 70.240 ms
5 0.xe-4-1-1.xl4.iad8.alter.net (188.8.131.52) 25.147 ms 17.592 ms 76.773 ms
6 tengige0-5-2-0.gw1.iad8.alter.net (184.108.40.206) 17.751 ms 9.992 ms
tengige0-5-1-0.gw1.iad8.alter.net (220.127.116.11) 12.499 ms
7 limelightnetworks.customer.alter.net (18.104.22.168) 10.659 ms 7.620 ms 9.948 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
You might find this thread interesting:
thanks. One more thing. Vudu asked me to chenge from default dns IP to Google at 22.214.171.124 hooping that maybe Verizon is pointing to wrong Vudu server or redirecting to a cache farm.
did not help anything, though.
So the traces are proving you're at least making it to the border router between Verizon and Limelight Networks, but you're also getting at least one hop beyond a Verizon controlled router. The traffic is staying within the US, so that's a plus. In addition, it's dumping off of Verizon rather close to you in a grand scheme of things. Afterwards the traces time out, so is it a question of the endpoint not accepting UDP Echo (default for *nix systems), or is it a question of a range being filtered outward.
I would try running Wireshark against the LG player or at minimum, see if you can get a dump of the NAT Table for your router which should show the destination, since if Verizon was manipulating the route on the fly by simply sending data to another place (rather than redirect via HTTP/DNS) you'd likely not be able to communicate at all with Vudu. If you have equipment capable of doing a man-in-the-middle capture, such as a switch with port mirroring, a hub, or a Wi-Fi adapter capable of capturing traffic, I'm curious if the Blu-Ray player is getting a particular response back from Vudu or if it's a case of just not getting a route. Assuming the traffic is not encrypted I suspect it should be easy to get.
I'm honestly not sure what Vudu is trying to accomplish blocking proxies and VPNs, though. I feel like they're shafting more than just the foreigners. VPNs and Proxies come in so many forms it's nearly impossible to filter them out without breaking things for others.
I would also consider checking the WHOIS record history for your Public IP address from Verizon. I know in recent months folks have been having on and off issues with getting to services due to Verizon assigning out freshly allocated IP addresses. Some of them came from other providers, for example that were not within the US. It's also noteworthy to point out that many folks run Tor exit nodes on FiOS. I don't know if they run them off of Dynamic IP accounts, but since you can switch between Exit nodes, that's something to consider.
All fairness to Vudu I suspect they have no interest in blocking anyone who has a good credit card. I'm sure it's the content providers demanding US only. Netflix doesn't work outside US either IIRC.
Well that was fun.
I set up wifi internet sharing on my mac and routed the LG through it and ran Wireshark against the interface.
First thing the LG does is send a dns query for startup.vvond.net. It gets back 126.96.36.199 which is an IP at peakwebhosting. Vvond is the original name of Vudu I read and peakwebhosting appears to be associated with Vudu as well.
From then on all traffic is https between the LG and 188.8.131.52.
The traceroute bewteen my home and that IP is
1 192.168.1.1 (192.168.1.1) 1.136 ms 0.444 ms 0.417 ms
2 l100.washdc-vfttp-115.verizon-gni.net (184.108.40.206) 8.720 ms 7.362 ms 7.524 ms
3 p9-2.bstnma-lcr-03.verizon-gni.net (220.127.116.11) 7.524 ms 12.210 ms 11.945 ms
4 so-12-1-0-0.res-bb-rtr1.verizon-gni.net (18.104.22.168) 7.853 ms 10.063 ms 7.285 ms
5 0.xe-7-0-0.br1.iad8.alter.net (22.214.171.124) 7.712 ms 7.135 ms 7.367 ms
6 xe-2-1-0.er2.iad10.us.above.net (126.96.36.199) 7.635 ms 7.087 ms 7.610 ms
7 xe-4-1-0.cr2.dca2.us.above.net (188.8.131.52) 10.269 ms 9.292 ms 9.403 ms
8 xe-1-0-0.cr1.dca2.us.above.net (184.108.40.206) 10.515 ms
xe-0-2-0.cr2.iah1.us.above.net (220.127.116.11) 64.714 ms 55.179 ms
9 xe-0-2-0.cr1.iah1.us.above.net (18.104.22.168) 44.689 ms 44.210 ms 45.047 ms
10 xe-1-3-0.cr1.lax112.us.above.net (22.214.171.124) 97.889 ms 78.284 ms 77.534 ms
11 xe-4-1-0.cr1.sjc2.us.above.net (126.96.36.199) 80.053 ms 79.676 ms 99.963 ms
12 xe-4-3-0.er1.sjc2.us.above.net (188.8.131.52) 82.892 ms 92.206 ms 82.408 ms
13 te2-4.cr1.mlp1.peakwebhosting.com (184.108.40.206) 80.053 ms 82.233 ms 82.190 ms
14 220.127.116.11 (18.104.22.168) 80.012 ms 79.519 ms 79.941 ms
15 22.214.171.124 (126.96.36.199) 80.006 ms 78.587 ms 79.988 ms
Danged if I can see a proxy in there.
1. Verizon assigns IP addresses dynamically. It's an automatic process, no one is manually handing out IPs.
2. The issue is not with the IP addresses that Verizon assigns, but with the blacklists not updating the IP addresses when they are changed. Verizon can't change third party sites' lists; it is up to the listing site to keep their filters updated.
Right, so that trace is showing a normal trace for the Verizon network. Since the traffic is via HTTPS, unless the traffic is somehow being proxied through another host without interference, a MITM redirect or hijack would instalty raise red flags for the application being used, causing the connection to halt or terminate.
There's some data you can check within the Wireshark dump if you saved it to see if there's a transparent proxy being used. One key bit to check for is for the IP address of the source and/or destination. Source should be either your computer's IP if you're sending out, or the remote server's IP if receiving. Vice versa for the other direction. If something's different, you're getting pointed to what could be a proxy. What you're also looking for is the difference or delta between the time it takes for a SYN to be sent and a resulting ACK to be received. The latency betweeen the two should be within the range of the latency you get to the server on the other end. If you get 70ms of latency in a trace/ping and a normal initial connection setup takes something like 8ms to set up, there's a red flag right there. If it's taking same or even slightly more time than the latency to the server to set up, you likely do not have a proxy in the mix.
I would run the Netalyzer tool on your computer to see if it detects any sort of proxy. It won't display the technical details, but it does have a few proxy detection mechanisms in it, one of which is a Transparent proxy detection. It's not 100% reliable since ISPs can manipulate results, but I've never seen Verizon do such a thing.
At this point though, I would consider talking to Vudu a bit more, or trying the same type of Wireshark capture against your neighbor's Comcast connection. I suspect the problem is with Vudu terminating the connection due to their "proxy/VPN" detection system, unless they've checked and have claimed otherwise.
http://netalyzr.icsi.berkeley.edu/ is the link to Netalyzr