TCP:PA FA and FPA in logs

[johnpoz]

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.

[Paddy]

@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

[johnpoz]

@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..

[Paddy]

@johnpoz

No floating rules defined.

[johnpoz]

@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..

[Derelict]

Probably no different than any other asymmetric situation. Inbound on one interface with the reply traffic going out another with no state.

[johnpoz]

@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?

[Derelict]

@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.

[A Former User]

@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

[Paddy]

Thanks guys for taking the time to explain and showing how to hide them.

[johnpoz]

@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

[Derelict]

@johnpoz I am going to submit a redmine to put "inbound/outbound" in those rule labels.