Default Deny Rule blocking traffic between interfaces
-
Trying to figure out why this is happening:
Browser on network port igc1 (172.29.2.0/24, aka Trinity) trying to access web site (Home Assistant) on port igc2 (17.29.3.0/24, aka Neo) and the return packets are getting block by a Default Deny Rule. The odd part is this used to work just a few days ago, but I don't recall changing anything in the Firewall Rules:
Ping between the two devices works both ways, and traceroute reports just 2 hops (both ways).
Not sure what I've done wrong or how to fix this.
I realize I can just click on the + in the log and pass those packets, but I'd like to understand how/why they are being blocked to begin with.Any ideas or need more info?
pfSense CE 2.7.2 -
@DaHai8 it may be https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html
-
@SteveITS : Thank you for the suggestion. I checked the “Allow IP Options” for IPv4 on both Neo and Trinity, but I'm still not able to access the HA server on Neo from Trinity. The browser just sits and spins.
And these entries are still appearing in the Firewall Log:
No perhaps NOT a firewall issue?
I was just over on the HA forum thinking it was a HA issue and that's when a suggestion to check the pfsense logs led me here.
Now I don't know what to think...argh -
@DaHai8 ok, you had said the return packet was being blocked, which isn’t a thing because pfSense is stateful. Packets are allowed or blocked as they arrive on an interface.
The IP Options thing I don’t think would be relevant here. I was more referring to the “out of state” part of the doc.
So the connection isn’t blocked by pfSense, and you’re seeing responses at pfSense. And pinging works. Does your browser network console/output show anything? Incognito window?
-
@SteveITS : Thanks for the suggestions!
When trying to connect to HA on 172.29.3.3 from 172.29.2.x from a Chrome Web browser, the connection eventually times out with "The Connection was reset".
Running Windows Network Diagnostics returned "The troubleshooter couldn't identify the problem"
Looking at the DevTools Network Console, when I first try to access HA via its URL, it does a Request URL data:image/png;base64, Request Method: GET. The Response failed (there was no response).
The summary at the bottom shows: 5 requests, 0 B transferred -
This is odd. I could have sworn I could ping the browser PC on 172.29.2.104 from HA on 172.29.3.4, but now I cannot. Maybe I had confused myself before.
From Windows PC to Home Assistant
From Home Assistant to Windows PC
The more things I check, the more confused I get!
-
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.
