Trying to understand the firewall rules
-
Can you tell me what is going on here with this firewall log? It seems to me pfsense is blocking one of my LAN devices from talking out. Why would this happen? Is this normal? I don't have any firewall rules to block those ports. I am running 2.3_1.
This seems to be happening with lots of my LAN devices. Here is another one.
-
That packets are out of state: https://doc.pfsense.org/index.php/Why_do_my_logs_show_"blocked"_for_traffic_from_a_legitimate_connection
Maybe you have an asymmetric routing issue.
https://doc.pfsense.org/index.php/Asymmetric_Routing_and_Firewall_Rules -
I have a layer3 switch routing to pfsense with a 24 bit mask but I have no connections other than pfsense and a Cisco L3 SG300-28 switch. This has been in place since 2.2.6 with no changes.
Is this an issue with 2.3? How am I going to fix this?
Update
I checked the static routing filtering option under Advanced Firewall/NAT. I will watch and see. -
Nope still seeing the same thing.
-
Nope still seeing the same thing.
What's the problem? PFSense is a stateful firewall and enforces proper TCP connections. If some of your devices are not following proper TCP protocol, PFSense blocks those packets.
Your images are full of dropped FIN and RST packets, where are used to signal to tear down a connection. The problem is the connection has already been torn down and no longer exists. Sending out of state packets to non-existent states are by definition invalid packets, under all circumstances.
If you can show the PFSense is improperly blocking new states or blocking valid packets for existing states, then you have something to show, but blocking invalid packets for non-states is a feature.
-
The 993 traffic (IMAP/S to Google) is probably phones that try to retain their mail connection after switching networks (which can't work, but some phones apparently aren't smart enough to figure out their TCP sessions don't remain valid if they change IPs). The HTTPS shown is to Facebook, which might be the same. Usually that's phones switching from cell network to wifi.
If those are all cell phones, or other devices that switch IPs, that's expected.
-
^ exactly if you do not want to log out of state packets then turn off default blocking.. And just create a block rule at the bottom of the interface that blocks but only logs with syn flag. Your default block rule is still there but not logging. And you can just log stuff that has syn set so you don't see the blocked out of state packets.
-
I think you are correct about one of the devices is my wife's iPhone 6s which has cell service also. The other device 192.168.0.77 is her iPad which does not have cell service. It only runs using wireless in my house. My wife is complaining about slow email. This and the Hulu TV issue are the 2 issues I am trying to resolve which were not issues under 2.2.6
My wife is complaining about her Apple devices not checking email very fast even if she stands right next to the wireless device. It seems real slow to respond. I run 3 Cisco wireless APs using single point setup. This system has not changed since before 2.2.6. The wireless APs all run from my Cisco layer3 switch which has not changed either. So all the traffic is routed LAN traffic.
I have included my gateway does this look correct? I was wondering about the monitor IP on the LAN side?
-
The email problem is solved. My wife had her iPhone in the guest network and her iPad in the main LAN. There is a ACL blocking the 2 VLANs. Both are now back in the same VLAN where they should be.
-
I just noticed I woke up my Windows 10 machine and I see this in the firewall log. Is this normal to block all this out bound traffic? The list is longer than a screen full so I only captured one screen. This is all routed traffic from my Cisco layer3 switch.
-
Yes, when you brought it out of sleep it tried to disconnect the connections it had open at the time it went to sleep (mostly, those are the FIN ACKs, others it was still trying to use), but those were already timed out. Not a SYN, and not part of an established TCP connection means blocked.
-
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.
