TCP:PA FA and FPA in logs
-
Hi,
I am seeing lots of blocked tcp:pa fa and fpa traffic on my openvpn interface. It is configured to route all client traffic through the OpenVPN.
Any ideas why I'm getting this and what I can do to remove them?
-
@paddy
That's out of state traffic blocks.I typically see them if/when i have had my laptop in sleep for some time and open it again.
The laptop tried to (re)use the old TCP connection , but the firewall has timed the TCP connection state out , due to inactivity. And is "barfing" in the log, nothing to worry about.
The lappy will just do a new TCP connect , and everyone is happy.
Edit:
These seems to go the other way, from inet towards your local device.
Top ones are github ... Did you have a valid connection to them ?/Bingo
-
At a loss to why you think you needed to hide some 10.x.x.x address.
Those are on your vpn interface and in the outbound direction? Those little black arrowheads are outbound I thought - but why is the rule saying its the default deny in an outbound direction?
So details of your setup and how your using the vpnserver interface (the s1) etc.. would be helpful.
-
@johnpoz said in TCP:PA FA and FPA in logs:
At a loss to why you think you needed to hide some 10.x.x.x address.
Those are on your vpn interface and in the outbound direction? Those little black arrowheads are outbound I thought - but why is the rule saying its the default deny in an outbound direction?
So details of your setup and how your using the vpnserver interface (the s1) etc.. would be helpful.
Just force of habit - I know they are non routable on the internet.
I don't know what the arrow head means but the source are external and the destination are IP's assigned to our OpenVPN clients.
The pfSense is hosted at AWS. Straight forward setup. LAN and WAN interfaces. The OpenVPN is running on the WAN interface.
All workers traffic is routed through the OpenVPN so even their no work related browsing is via the pfSense
-
@paddy said in TCP:PA FA and FPA in logs:
the arrow head means
The arrow head means outbound
https://docs.netgate.com/pfsense/en/latest/monitoring/logs/firewall.html
What rules do you have in floating - not possible to see that little black arrow unless you create rules in the floating tab, interface rules are only evaluated inbound, not outbound.. Only way to get an outbound block is in the floating tab..
-
No floating rules defined.
-
@paddy well then I have no idea what is going on there.. I am not aware of any other way for outbound rules to be evaluated.. And to be honest something odd even if a floating rule since it says the default deny rule in outbound direction?
Lets see if @Derelict or @stephenw10 want to chime in with some wisdom.. Since I'm just drawing a blank to what could cause that..
-
Probably no different than any other asymmetric situation. Inbound on one interface with the reply traffic going out another with no state.
-
@derelict huh? Just on first cup of coffee, but in what scenario would outbound traffic be evaluated by rule in outbound direction without a floating rule to do that? I thought only floating rules did outbound evaluation? There is default deny for outbound?
-
@johnpoz routing into an interface without reply-to and the reply traffic following the routing table. It's obviously something. Look at the states for the interesting traffic:
pfctl -vvvss | grep -A4 _something_interesting_
Get the rule number then look at the rule set to see what rule allowed the SYN in and created the inbound state.
Either the ovpnc1 interface didn't see the TCP handshake or the state has been expired/killed.
-
@paddy said in TCP:PA FA and FPA in logs:
what I can do to remove them?
configure the same as me and this will no longer be displayed ... You also do not have to worry I see this every time and everything works fine
-
Thanks guys for taking the time to explain and showing how to hide them.
-
@derelict said in TCP:PA FA and FPA in logs:
Either the ovpnc1 interface didn't see the TCP handshake or the state has been expired/killed.
Yeah I get that - but there is an outbound default deny?
Well guess there is ;)
[21.05.2-RELEASE][admin@sg4860.local.lan]/root: pfctl -sr | grep "Default deny rule IPv4" block drop in inet all label "Default deny rule IPv4" block drop out inet all label "Default deny rule IPv4"
Ok that makes more sense now.. Thanks @Derelict
-
@johnpoz I am going to submit a redmine to put "inbound/outbound" in those rule labels.