Port 443 traffic being blocked by default block rule -- but I can't find this rule

[kevdog]

Sorry to waste someone's time.

I have the following block rule showing up in my firewall log:

Briefly it looks like traffic from my laptop (10.0.40.128 - VLAN 40) is being blocked to an internal https server located on a 10.0.1.11:443 (untagged VLAN or VLAN1).

The logs specify the Default deny rule IPv4 (1000000103) is being used on VLAN40MANAGEMENT interface.

Looking at the rules for this interface however, I don't see any rule that would show this:

In fact - shouldn't my first rule actually cover this scenario??:

Is something going on the background here with some hidden rule I'm not seeing?

[viragomann]

@kevdog said in Port 443 traffic being blocked by default block rule -- but I can't find this rule:

Briefly it looks like traffic from my laptop (10.0.40.128 - VLAN 40) is being blocked to an internal https server located on a 10.0.1.11:443 (untagged VLAN or VLAN1).

Seems that pfSense has already closed this connection, while the client tries to reset it.
See Troubleshooting Blocked Log Entries for Legitimate Connection Packets.

Is this a special web service?

Does the client really have trouble accessing the server?

[kevdog]

I think I actually might have solved the issue (or may it extremely better). I dug around for hours and came up with this link: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html. It seemed to describe my situation rather well and I applied the manual fix listed in the link. I don't seem to have issues. I'm no expert in networking, however I have pfsense virtualized with they xcp-ng hypervisor, and I have another xcp-ng hypervisor on the LAN network creating VMs. Not knowing a lot about routing and such I could see with this setup how there could be some potential routing issues particularly with VMs being assigned multiple networking cards - each on their own VLAN/subnet. Anyway it seems the fix is working for now.

[viragomann]

@kevdog
If you don't have any issues there is no need to allow these packets. In this case it might not be due to asymmetric routing, but rather the connection was already closed due to a timeout.
The client will determine this anyway and establish a new connection if needed.

Allowing out-of-states packets just inserts a vulnerability into your network.

[kevdog]

@viragomann You are correct that I'm opening up a potential security hole, however there wasn't any other way to get around it since I couldn't connect the the server due to blockage at the firewall level. I'm not sure if it's asymmetric routing or not, however the description of the asymmetric routing sure sounded like it. The client (ssh) would just hangup and not re-establish a new connection.

[viragomann]

@kevdog
I see. I got, you didn't have problems on the client accessing the server.

Asymmetric routing could happen due to multi-homed machines in your case. But the log doesn't look like that. You would rather see response packets from the server being blocked.