Trying to understand the firewall rules
-
At the same time this was happening with my workstation Hulu had time outs streaming. Hulu had been streaming for over an hour without any time outs but I came home and fired my laptop up from sleep and Hulu started having time out problems.
-
Assuming all those blocks are from the laptop's IP, none from the system running Hulu, that's unrelated.
That would either be a coincidence, or maybe bringing the laptop on the network does something that impacts the device that's streaming Hulu. Something like creating an IP conflict, or extremely heavy bandwidth usage by the laptop, are the first couple things that come to mind.
-
Maybe a coincidence. I have a TWC 300 meg connection and all this hardware was in place with 2.2.6. No time outs with 2.2.6.
No conflict with IP addresses as the TV streaming Hulu is in a different VLAN.
-
With a connection that fast, you almost certainly wouldn't be hitting it hard enough to cause issues for other devices. Probably the only case where that'd happen is if the laptop had malware on it that blasted a bunch of traffic out, maxing out your upload with a flood of traffic, which will significantly impact your downstream performance. That doesn't sound likely either. It being on a different VLAN eliminates all the local network specific possibilities.
I'd packet capture on the VLAN where the TV resides, filtered on its IP, and see what the traffic looks like when it stalls.
-
I have a packet capture with Hulu streaming freezing and starting over. I can't add it as an attachment. What do we want to do with it?
-
yeah that is pretty useless. Can you not just attach the actual capture or upload it somewhere we can grab it..
-
I zipped it. This is a capture of the LAN interface when Hulu freezes and replays.
-
There is nothing wrong in that short capture of whole .6 seconds.. What exactly are we suppose to see in such a small sniff.. I see 1 dup ack.. Did you forget to change it from the default 100 packets? Which is what that sniff is..
-
OK. I will enter 0 for packet count. Anything else I need to change? I will run it again.
-
I have another capture but the file is too large to attach. I get an error from your system.
-
Can you upload it somewhere else and post a link? How big is it? Forum size limit is ~5 MB per file, ~10 MB per post. For these purposes it might be just as useful to change the packet length being captured to 64 bytes, and end up with a much smaller capture as a result.
-
It is 8.56 MB file. I will look into changing packet length to 64 bytes.
Who is free for file storage now days? So I can post a link.
-
OK I have run it with 64 byte packets.
[packetcapture (2).zip](/public/imported_attachments/1/packetcapture (2).zip)
-
I am seeing the same issue with 2.3.1 which I loaded tonight. I will be out of town for a few days but I will be back and can help. Hulu still freezes and replays after Ads.
-
Any idea when my problem is going to be fixed? My wife is getting tired of Hulu replaying.
-
I just loaded 2.3.1_1 and I still have a problem which seems the same. Hulu streams and freezes. Any ideas? I can run more packet captures if it would help.
-
Out of the box, PFSense doesn't attempt to block or mess with anything, other than new incoming connections on the WAN. Have you made sure it is PFSense doing it? Have you tried to by-pass PFSense and connect directly and see if the problem persists?
-
The only thing that seems a bit odd in that trace is this connection. But is that have anything to do with hulu? Its some company called doubleverify
NetRange: 204.154.110.0 - 204.154.111.255
CIDR: 204.154.110.0/23
NetName: DOUBLEVERIFY-INCSince its in https its hard to be sure - but its odd that your client sends Fin,ACK and then 2 RSTs for this connection. You would normally see fin, then fin,ack from the other side that says sure Im done with this conversation as well. Not sure what the details are with the unknown and encrypted alert.
Without doing MITM on the connections that are https its sometimes quite difficult to trouble shoot what is going on, because you can not really see the meat of the conversation.
-
That is indeed the only atypical thing in the capture. The TV abandoned that connection for some reason, that was the TV's doing. I doubt given how the traffic otherwise looks in general that's related to the issue, but it could be.
Otherwise the capture is 100% perfect - no packet loss, no connection attempts that failed, no DNS lookups that failed, etc. Very clear from that it's not network or ISP or firewall-induced. It's either the TV, or Hulu.
Any idea when my problem is going to be fixed?
Well it's definitely not in anything we control, so no.
