Excessive TCP: PA FA RA
-
Hi All,
Lately I am seeing an overly excessive amount of TCP: PA, FA, FPA dropped packets to legit traffic in the firewall logs.
I have the Optimization set to Conservative.
I cannot find anywhere with suggestions to take to reduce this packet loss.
Could the Traffic Shaper help if I throttle my bandwidth down? I am not using the shaper now.
I have a single WAN, LAN and OPT1 network. The only package is PFblockerNG.
Any help or suggestion is highly appreciated.
Dan -
Comes up in search.
Are you using vpn or 2 wans?
-
No VPN and one WAN.
Only suggestion in a search I could find was the Conservative setting.
I also increased the nmbclusters to 1000000. I am using all igb interfaces.
All the offloading is checked/disabled.PA, RA, FA happens on all the interfaces and happens 20-30 times a minute. The good traffic does eventually get through but I have a lot of broken packets.
-
Here is an example in my firewall log. There has to be something wrong here!
-
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connection
Any time there are excessive ACKs being dropped, it's almost always out of state traffic. Weird that it's logging a block between 20.1 and 20.2. Any wireless clients on the network? They are notorious for leaving connections hanging and switching networks on a whim.
-
No there are not any Wireless networks, just one WAN and 2 subnets (192.168.1.0/24, 192.168.20.0/24)
I am also not doing any Clustering or Load Balancing.My issue is that this is a new problem.
So what else could be causing this issue?
-
First off, are you actually seeing any problems on your network or are you just reacting to log spam?
-
I haven't noticed any issues, but these logs alarmed me since I have never seen this before. I suspect my internal network speed must be slower if there are all these bad packets but not sure how to test that.
-
Some of those are to loopback, 127.0.0.1
What are you running on pfsense on port 19006??
-
As far as I know nothing is running on port 19006. But those eventually disappeared.
The real issue is that every connection to PFsense gets a PA, RA, or FA before it goes through. Even local to local connections. Every HTTP access gets one too, but then goes through.
There is something wrong here when every incoming or outgoing packet drops before it goes through.Any suggestions?
-
FA and RA are just FIN and Reset packets. They're trying to close the connection. No point worrying about blocking packets that are meant to kill a connection if the connection is already dead.
-
Post screens of your LAN configuration and firewall rules. Something screwy is going on. Local traffic doesn't hit the firewall at all, and I noted this when I said it was funny that it's logging a block between 192.168.20.1 and 192.168.20.2. No VLANs configured?
-
Are you running some sort of port forward or weird nat reflection setups… I agree with I can think of nothing that would be running on pfsense that listens on that port.. Post up a output of sockstat -4 -l
example of mine
[2.3.2-RELEASE][root@pfsense.local.lan]/root: sockstat -4 -l USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root php-fpm 4623 5 udp4 *:* *:* root radiusd 76653 13 udp4 192.168.2.253:1812 *:* root radiusd 76653 14 udp4 192.168.2.253:1814 *:* proxy ftp-proxy 68730 3 tcp4 127.0.0.1:8021 *:* ladvd ladvd 38973 9 udp4 *:* *:* root ladvd 38787 5 udp4 *:* *:* dhcpd dhcpd 12642 16 udp4 *:67 *:* dhcpd dhcpd 12642 20 udp4 *:64384 *:* unbound unbound 93283 4 udp4 192.168.9.253:53 *:* unbound unbound 93283 5 tcp4 192.168.9.253:53 *:* unbound unbound 93283 8 udp4 192.168.2.253:53 *:* unbound unbound 93283 9 tcp4 192.168.2.253:53 *:* unbound unbound 93283 15 udp4 192.168.3.253:53 *:* unbound unbound 93283 16 tcp4 192.168.3.253:53 *:* unbound unbound 93283 19 udp4 192.168.4.253:53 *:* unbound unbound 93283 20 tcp4 192.168.4.253:53 *:* unbound unbound 93283 21 udp4 192.168.6.253:53 *:* unbound unbound 93283 22 tcp4 192.168.6.253:53 *:* unbound unbound 93283 25 udp4 192.168.7.253:53 *:* unbound unbound 93283 26 tcp4 192.168.7.253:53 *:* unbound unbound 93283 27 udp4 127.0.0.1:53 *:* unbound unbound 93283 28 tcp4 127.0.0.1:53 *:* unbound unbound 93283 31 tcp4 127.0.0.1:953 *:* root openvpn 31208 6 udp4 24.13.snipped:4142 *:* root openvpn 18443 6 udp4 24.13.snipped:1194 *:* root openvpn 14412 6 tcp4 24.13.snipped:443 *:* root syslogd 49062 7 udp4 192.168.9.253:514 *:* root ntpd 44109 21 udp4 *:123 *:* root ntpd 44109 23 udp4 192.168.9.253:123 *:* root ntpd 44109 26 udp4 192.168.2.253:123 *:* root ntpd 44109 29 udp4 192.168.3.253:123 *:* root ntpd 44109 31 udp4 127.0.0.1:123 *:* root ntpd 44109 34 udp4 192.168.4.253:123 *:* root ntpd 44109 36 udp4 192.168.5.253:123 *:* root ntpd 44109 38 udp4 192.168.6.253:123 *:* root ntpd 44109 41 udp4 192.168.7.253:123 *:* root nginx 40900 6 tcp4 *:443 *:* root nginx 40900 8 tcp4 *:80 *:* root nginx 40737 6 tcp4 *:443 *:* root nginx 40737 8 tcp4 *:80 *:* root nginx 40531 6 tcp4 *:443 *:* root nginx 40531 8 tcp4 *:80 *:* root xinetd 28003 0 udp4 127.0.0.1:6969 *:* root sshd 13927 5 tcp4 *:22 *:* root php-fpm 264 5 udp4 *:* *:* [2.3.2-RELEASE][root@pfsense.local.lan]/root: -
KOM - See attached configs, I do use a Virtual IP that redirects to an assigned IP, No VLAN's
Johnpoz- No port forwards to port 19006. I use a few rules to direct email traffic to the correct IP
As far as the port 19006 hits, saw more this morning, so I setup a TCP port monitor to capture what process is causing it. But it looks like PFsense is generating the packets by looking at the sockstat
Here are the Firewall rules and sockstat
I noticed the extended Internet daemon port in the sockstat list. What does this mean?
-
Your rules are a bit of a mess. Rules are applied to traffic entering an interface. You can delete almost all of your LAN/OPT1 rules and replace them with a single Allow Any rule on each. Generally, you don't specify a Source since the network the traffic is coming from is the source. For example, on your LAN rules you don't need to specify Source as LAN Net since no other traffic is going to be coming into the LAN interface other than LAN Net traffic. Those 2 Allow All rules at the bottom of your WAN rules needs to go, pronto.
Clean your rules up and this might help eliminate any weirdness going on.
-
Yeah with KOM here those rules are complete mess..
Your lan rule is any any at the top, for udp/tcp why is it called allow email?? What email runs on udp?
Anyhow - all the rules below that are just pointless.
Rules are evaluated top down, first rule wins, rest are not even looked at. As the packets enter the interface.
Those rules on your wan are BAD!!!
What do you have in your xinetd conf?
cat /var/etc/xinetd.conf
What packages do you have installed other than pfblocker?
-
Thanks for taking the time to help with these rules.
As for the LAN rules, see change below. I simplified it to any-any
As for the WAN rules, I have trimmed them down to the ones needed for the NAT port forwarding, see change below.
So in actuality, I should have only the WAN direct ports and have all the other interfaces pass any to any. I have no need for any restrictions on any of my internal networks. The only blocking I care about is from the WAN. But I do know that you also have to use the rules to direct traffic, as in the WAN rules below.
Don't I need a rule to allow internet traffic to my LAN. It does seem to work without one.
-
Not sure why you are not using protocol any on your LANX rules if you really want no restrictions between LAN interfaces.
-
"I do know that you also have to use the rules to direct traffic"
Huh? Sure if you want to do policy routing out a specific gateway or vpn connection, etc. But lan to opt etc.. Or just out the default gateway no there is no need to "direct" anything.
If you really want no restrictions than that rule should be any not tcp/udp. So you won't be able to ping stuff with that setup. Even though you would be able to hit http..
So what is the content of your xinetd.conf ??
cat /var/etc/xinetd.confYou clearly had something listening on that 19006 port..
-
Ehm, no. Directly connected networks are known to the system by their routing table entries that do not need a gateway entry in the table. Gateways are only needed for "foreign" destinations, i.e. networks that are not directly connected to the system. The best example is of course the default gateway which is the 0.0.0.0/0 entry (often marked as "default" as it is in pfSense also) in the routing table, it's not a directly connected network so in order to reach it a gateway has to be configured. Like so in my pfSense system (public IPs censored):
$ netstat -nr -f inet Routing tables Internet: Destination Gateway Flags Netif Expire default 88.195.aaa.1 UGS em1 10.0.0.0/8 127.0.0.1 UGS lo0 10.71.14.0/24 link#2 U em0 10.71.14.1 link#2 UHS lo0 88.195.aaa.0/19 link#3 U em1 88.195.bbb.ccc link#3 UHS lo0 127.0.0.1 link#7 UH lo0 172.16.0.0/12 127.0.0.1 UGS lo0 192.168.0.0/16 127.0.0.1 UGS lo0 192.168.1.0/24 link#3 U em1 192.168.1.200 link#3 UHS lo0Here the 88.195.aaa.0/19 is a directly connected network (the WAN network), so is my LAN network of 10.71.14.0/24. The system knows how to reach hosts on those networks without a need to send the traffic to a gateway by issuing an ARP query on the connected network to figure out which MAC address the traffic should be sent to on the ethernet level.
The default gateway, the one that is needed to reach the "world out there, the internet" is the first line that says "default 88.195.aaa.1 UGS em1". This says that in order to connect to any IP address/network that does not match an entry in the routing table of this system forward the traffic to address 88.195.aaa.1 and not very surprisingly the routing table also has instructions on how to reach that address, the "88.195.aaa.0/19 link#3 U em1" line.
