Basic firewall blocking for TCP:RA and TCP:PA

[user2]

Hello friends.

I've read a lot about this, but haven't solved it. I am humbly asking to get the benefit of your experience. Is there any way to correct these errors (rather than suppressing them with firewall rules that are silent)?

With basic rules to 'allow all inbound on LAN', I currently see lots of repeating Firewall log entries e.g.:

Blocked on LAN - Default deny rule IPv4 (1000000103): src x.x.1.31:44597 dst <amazon1>:443 TCP:RA
Blocked on LAN - Default deny rule IPv4 (1000000103): src x.x.1.31:44597 dst <amazon1>:443 TCP:PA

I thought these were 'normal' out of TCP/state errors, but now I think it's because of my network configuration and my devices cannot close sessions properly.

What is the best way to configure my pfSense firewall? Currently I have:

• Firewall is "Automatic outbound NAT rule generation.
  (IPsec passthrough included)"
• UPnP & NAT-PMP (not selected) * This is probably my biggest configuration question.
• IP Do-Not-Fragment compatibility / Clear invalid DF bits instead of dropping the packets (selected)
• Firewall optimization: Normal

If it helps I can capture packets regarding this device.

Kind regards,
u2

[user2]

Corrected drawing ... it's an Amazon Fire device.

I port mirrored the Switch's port connecting to pfSense LAN (1.1). Here's what I found so far:

• pfSense blocks the 2 packets at the end of the TLS v1.2 session.
• However, the TCP:PA TLS v1.2 "Encrypted Alert" is normal and is used by the TLS protocol for notifying the peer that the connection can be closed -- usually when there is no more traffic to send.
• I guess the TCP:RA is because the previous packet was dropped.

So, maybe pfSense knows the TLS session is complete? Could it know this from receiving a RST packet on the WAN side? But still, should it not pass down the RST to my device?

I'll check the WAN side and post back later...

[stephenw10]

Those two packets look like they are ~30mins after the rest of the session. TCP states normally close as soon as the session is complete so they would certainly be closed at that point.

Steve