Trying to understand the firewall rules
-
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)
