Clarification in blocks in the firewall logs.
-
@stewart could be something stupid where server said hey I know that IP and sent the traffic back to the client from its internal IP, and then the client tried to answer that - but firewall was not having it because of lack of state.
Without fully understand your network layout, possible flows of traffic and what exactly your doing maybe port forwards, nat reflection, etc. Its not really clear to what might have caused the traffic.
-
@johnpoz In this instance it's just a port forward to a Web Server, nothing fancy other than limiting who can get to it. I assumed it was because the packet came back knowing the internal IP is where it was supposed to go and when the firewall blocked the packet it logged that IP since it was the intended destination encapsulated in the packet.
-
@stewart yeah if your actually doing nat reflection, ie you have some client on your lan - hitting yoru wan to be forwarded back in, you might want to do the nat reflection so it always answer back to your wan IP vs the source IP.
Not a fan of any sort of traffic going to my wan IP to be forwarded back in - I just setup dns to resolve whatever fqdn I want to use to the internal IP when internal, etc. Or just use the internal IP.
-
@johnpoz I'm not reflecting internal traffic for the WAN IP so not NAT Reflection. These are external locations that are forwarded to an internal server.
-
@stewart well that is easier to explain then.. Its just out of state traffic.. And your server is just answering.. For whatever reason I read that sourceIP as being internal? doh...
You sure your states didn't just get reset, do these come in groups? But yeah as discussed out of state traffic is blocked on a stateful firewall. Why there is no state would be the question - maybe server answering really late? Maybe there was a fin/ack that closed the state and and A after the fact, etc..
If you see it a lot - do some packet captures of this traffic between external IP and your server so you can see if there is fin,acks that close the state and then acks after, that sort of thing.
-
@johnpoz Relatively sporadic it seems. The sites have equipment that check in every 5 minutes or so over port 80 so there are at least 12,000-15,000 checkins per hour. I see a few of these drops per day so nothing widespread.
-
What do you have set here?
https://docs.netgate.com/pfsense/en/latest/routing/gateway-configure.html
if you only seeing a few here or there - it could be something as odd as retrans after a fin,ack that closed the state..
edit: you sure that source IP is one of the devices that should be checking in?? It could just be spurious noise from the internet as well.. I don't log that traffic on my wan, only syns - since there is lots of noise on the internet.
An ACK wouldn't open a state - so yeah pfsense blocks such noise even if you forward the port the traffic comes in on. I turn off logging of the default rule, and have my own rule that only logs tcp SYN.. and than another rule that logs common udp ports that would be of interest.
edit:
-
-
@stewart
Click the "Display Advanced"?Nope, just checked mine, I have it but it's not in advanced.
Odd that you don't.
Was that added in 2.7 maybe? -
@jarhead hmmm - wonder if that is + thing, I'm running 22.05 - maybe will show up in 2.7 of CE?
-
@johnpoz Yeah, it's not under advanced either. Might be a 2.7 thing. Either way I think they question is resolved. Thanks for the insight and have a great weekend!
-
@stewart you too.. But curious now if really out of state or just noise ;)
-
@johnpoz The world may never know...
-
@stewart hahaha <rofl>
