Default Deny Rule blocking traffic between interfaces
-
Ok. Turns out Windows PCs don't like to be pinged.
iPads don't care.
So data (pings) are crossing over between 172.29.2.x and 172.29.3.x
Back to square one...
-
@DaHai8 said in Default Deny Rule blocking traffic between interfaces:
Windows PCs don't like to be pinged
Possibly, a firewall rule on it is only allowing ICMP from the local subnet.
-
@DaHai8 that screams asymmetrical, I would expect to see a SA though. Maybe you just didn't post screenshot with SA?
Your states could of gotten flushed, so pfsense no longer sees a state to allow the return traffic.
If that was the case I would expect it to recover - since the device should give up and start a new session.
-
@johnpoz : Thanks for the suggestions!
I let it run again, from my Pixel Phone on 172.29.2.102 until its finally timed out, then checked the Firewall logs: No 'SA' anywhere. Just 'A' and 'PA'
At this point, I don't know what's going on. I think I'll just 'Listen to the Music Play' and set this aside for awhile.
Thanks everyone!
-
@DaHai8 you were doing this on a phone? they have problems with using old sessions, possible it just didn't open a new one after pfsense had closed an old state.
But yeah can always just listen to the music play!!
-
@johnpoz : I've tried Pixel 6 Chrome Browser, Windows 10 and 11 Chrome Browser and iPad Home Assistant App.
Grateful Dead, nice choice. I'm more Dark Side of Moon myself
Cheers.
-
@DaHai8 I would sniff to see if you are seeing the SA, and then just traffic stops? Maybe one side sent a fin or a rst - and the state closed.
You really need to see a packet capture that captures the full conversation.
The reason ack are blocked is there is no state to allow it.. Why the state is not there is what you need to figure out. Either your traffic is asymmetrical and pfsense never saw the syn to open the state. Or the state went away at some point and that is when you start seeing blocks.
You can sniff on pfsense with packet capture under diagnostics, or you could always fire up wireshark on your windows machine.
edit - this trace looks really wrong to me.. Why would you have 2 hops in the same network? And that first hop - that is odd name for your pfsense box ;)
Can you put together a napkin drawing of how you have this connected together - what are the 3.3 and 3.1 boxes?
This is how a trace should work from a device in one network talking to another network attached to pfsense
$ tracert 192.168.3.32 Tracing route to ntp.home.arpa [192.168.3.32] over a maximum of 30 hops: 1 1 ms 1 ms 1 ms sg4860.home.arpa [192.168.9.253] 2 1 ms 1 ms 1 ms ntp.home.arpa [192.168.3.32]My pc at 192.168.9.100/24 sends traffic to its gateway (pfsense) then pfsense sends that on to the 192.168.3.32 IP address.. Since pfsense is directly attached to both the 192.168.9 and 192.168.3 network.
Also that first hop - .007 ms - that has to be itself that your tracing from - is that a container network or something? Are you running this stuff as VM?
If your tracing from a 172.29.2.x - why is your first hop an IP in 172.30.32??
-
@johnpoz : I will look into this after the weekend, and post back soon after.
Thanks for all the help/suggestions! -
@DaHai8 Have a look at this : NetGate IP-Options.
I was having similar problems which seemed to appear within the last week. I tried everything, and this finally appears to have worked.
-
@Spiney ip options is not his issue that is for sure.
