[SOLVED] TCP:FA and TCP:RA and TCP:FPA

[mtn406]

Hello! Please excuse me if this is an ignorant question. I did look through these forums and Google.

The issue is users complaining about slow performance of a custom application (and blaming the network). The network is proven fast with "regular" applications (browsing, downloads, etc) and that lead me to dive into the log files (section copied below). Unfortunately, I am at a loss to understanding what these log files mean and would appreciate some assistance and solution.

It appears the issue is in TCP:FA and TCP:RA and TCP:FPA.

First question is: What do these mean, please?

In Googling I found some pages talking about pfSense and was able to follow the suggestions, but it has NOT solved
the problem.

https://knowledge.zomers.eu/pfsense/Pages/How-to-solve-connectivity-issues-with-dropped-RA-and-PA-packets.aspx

In OPNsense I found the settings in Firewall --> Settings --> Advanced and did set things to "conservative   Tries to avoid dropping any legitimate idle connections at the expense of increased memory usage and CPU utilization." Again, it does not appear to have worked as the TCP:FA/RA/FPA messages are still showing up.

Next, this page (https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting) mentions:

Asymmetric Routing
If reply traffic such as TCP:A, TCP:SA, or TCP:RA is shown as blocked in the logs, the problem could be asymmetric routing. See Asymmetric Routing and Firewall Rules for more info.

I do not understand how this can be "Asymmetric Routing" as the OPNsense box only has 1 WAN and 1 LAN and 0 VLAN.

I understand this might be an issue with the custom application. What can I go back to the application team with to help them (and defend the network team), please?

--------------------------------------------------------------------------------------------------------
https://www.supermicro.com/products/system/1u/5018/sys-5018d-fn4t.cfm
8 core Xeon with 64 GB RAM and M.2 SSD
running:
OPNsense 17.1.2-amd64
FreeBSD 11.0-RELEASE-p7
OpenSSL 1.0.2k 26 Jan 2017
--------------------------------------------------------------------------------------------------------
Act   Time   If   Source   Destination   Proto
Feb 23 20:16:27   LAN     192.168.13.112:54441     23.194.108.175:443
a23-194-108-175.deploy.static.akamaitechnologies.com   TCP:RA
Feb 23 20:16:27   LAN     192.168.13.112:54442     23.194.108.175:443
a23-194-108-175.deploy.static.akamaitechnologies.com   TCP:RA
Feb 23 20:12:28   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:RA
Feb 23 20:12:18   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:14   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:10   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:09   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FPA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:FA
Feb 23 20:12:08   LAN     192.168.13.112:54510     104.197.115.115:443
115.115.197.104.bc.googleusercontent.com   TCP:PA
--------------------------------------------------------------------------------------------------------

[mtn406]

Update:

Today, the software team is running 3 different versions of the custom application with no issue. We made no network changes. Therefore, perhaps this issue came about because of something on the server we were connecting to on the Internet.

IF anyone has any thoughts on this, please share.

Thank you!

[franco]

This could be previously running TCP sessions that the firewall didn't see begin, e.g. after a reboot. It can also happen with slow timeout services where the firewall state tracking is too aggressive in state timeouts. In those cases setting "conservative" under Firewall: Advanced: Settings "Firewall Optimization" can help.


Cheers,
Franco

[mtn406]

Franco,

Thank you for the reply. We did set to "conservative" and rebooted both the OPNsense firewall and clients but it did not help which makes me think it was an issue in the cloud at the hosting site. (And the fact that the next day suddenly everything worked.)

Thank you!