Traffic restriction resulting in hung sessions

techietubby

I have a PFSense firewall appliance with a LAN address of 10.1.0.100 and a VIP of 10.2.0.100 on the LAGG0 interface. We are in the process of a network migration from 10.1 to 10.2 therefore some Linux hosts have addresses on both subnets, and a D/G of 10.1.0.100, and others have already been migrated to the new subnet.
Those that have been migrated (including DNS) operate exclusively on 10.2. and use the VIP address without issue, however where a server has its primary address and D/G on 10.1.x, and a VIP of 10.2.x hang after 20 seconds when opening sessions to another host that has been migrated to 10.2.
I can see that the traffic is being routed across the LAGG0 interface and there doesn't seem to be any error message and so cannot find the cause of the hang. Does anyone have any ideas as to why a session would only hang after it has been established for 20 seconds or more?

stephenw10

You have created asymmetric routes between multihomed hosts and hosts only using the new subnet. Traffic from the migrated devices must go via pfSense and be routed. Traffic the other way can be sent directly. Thus pfSense only sees half the TCP conversation and starts blocking it.
You can add a fudge rule to pass it but it would be better to not have asymmetric traffic.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html

techietubby

@stephenw10 Many thanks for taking the time to reply and to assist me.

I tried activating the option but it didn't help.

techietubby

@stephenw10 I check our firewall and it is very old:

2.5.1-RELEASE (amd64)
built on Mon Apr 12 07:50:14 EDT 2021
FreeBSD 12.2-STABLE

Is there any idiot's guide showing how I can safely manually add a firewall rule?

stephenw10

You'll need to use the manual firewall rule option with sloppy states and TCP flags set in the advanced rules section like:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html#manual-fix

You may need to add that as an floating rule with direction any and source/destination values that match traffic both ways between the old and new subnets to be sure.

But it should be pretty clear from the firewall logs what traffic is actually being blocked.