Rule not matching

[hillisdr]

I have two rules that seem to be not working.
There are more rules, but here are the rules that I think should be matching, but aren't:

Rules on interface 0008__VLAN_8_OFFICE_OLD (10.10.8.1/24)

Action	States	Protocol	Source	Sport	Dest	Dport	GW	Queue
Pass	0/0 B	IPv4 TCP	*	*	*	445	*	none
Pass	0/0 B	IPv4 TCP/UDP	*	*	*	8006	*	none

But despite these rules, the following types of entries keep showing in the log file with this as the block message:

The rule that triggered this action is:
@9(1000000103) block drop in log inet all label "Default deny rule IPv4"

Action 	Time 		Interface 		Source 		Destination 	Protocol
Block	Nov 17 21:40:35	0008__VLAN_8_OFFICE_OLD	10.10.8.30:5456	10.10.5.2:445	TCP:A
Block	Nov 17 21:40:36	0008__VLAN_8_OFFICE_OLD	10.10.8.30:5456	10.10.5.2:445	TCP:A
Block 	Nov 17 21:44:22 0008__VLAN_8_OFFICE_OLD 10.10.8.30:5510 10.10.2.20:8006 TCP:PA
Block	Nov 17 21:44:23 0008__VLAN_8_OFFICE_OLD 10.10.8.30:5510 10.10.2.20:8006 TCP:PA

I don't know if I'm misunderstanding something, but it seems to me that the two rules should be applying to these packets and passing them before the default block rule.

[viragomann]

@hillisdr
Obviously you have an asymmetric routing issue. The shown blocks are not SYN packets. So the appropirate SYN packet may have taken another way and hence pfSense has no state for that connection.

There are more infos about your network needed to solve this.

[johnpoz]

^Exactly if you say anything other than TCP:S for the protocol it screams asymmetrical or out of state..

https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

Keep in mind that correct solution is remove the asymmetrical traffic flow..

Its not always asymmetrical, could be states have been cleared, or mask mismatch.. For example if that 10.10.8.30 box had a mask of /24, and your 10.10.5.2 had a mask of /16 and these boxes were on the same L2 network.. While 10.10.5 would send directly to your 10.10.8 box, 10.10.8 would think 10.10.5 is different network and send the return traffic or the A to pfsense saying hey trying to talk to 10.10.5

But you don't show any SYN,ACK (SA) there so not sure where in the handshake you are, etc. Some more details of your setup might help us help you find out why your seeing that.. But yes it normally screams asymmetrical as the problem.

[hillisdr]

Below is a diagram that shows my network layout. I didn't diagram it, but there's also a Proxmox server configured similarly to the FreeNAS server. It has IPs of:
10.10.2.20/24
10.10.3.20/24
10.10.5.20/24
10.10.8.20/24

[hillisdr]

And with your prodding, I think I just figured out the problem. Both the Proxmox and FreeNAS servers probably shouldn't have vlan8 interfaces if vlan8 traffic is getting to them via vlan5.

I deleted the 10.10.8.20 and 10.10.8.2 interfaces and I think the problem is fixed.

Thanks for your help!

[johnpoz]

If all your routing is done at pfsense - nothing is jumping out at me that looks asymmetrical.

Could the states have been reset? States can be rest on loss of wan, etc. If you have it set to do that..

[hillisdr]

Yes, all routing should be done at pfSense.

I had intended connections from hosts in 10.10.8.0/24 (vlan 8) be routed to servers in 10.10.5.0/24 (vlan 5) or 10.10.2.0/24 (vlan 2) via the pfSense router. But two main servers had interfaces in vlan 8, so I'm assuming return traffic was coming back that way, instead of being routed through vlan 5 or 8 the way they came in.

After removing the server interfaces in vlan 8, return traffic must flow back the way it came in, and everything is working again.

[johnpoz]

@hillisdr said in Rule not matching:

After removing the server interfaces in vlan 8

You had multihomed devices... Oh well yeah, that is always and forever problematic.. Almost never a good idea ever.. Unless the other networks are just SANs or something and are not routeable