Simple Cross-Interface traffic not egressing to second interface

DobberDoo

I have 4 interfaces total. The issue I'm having is from client devices on interface 'KIDS' connecting to server device on 'HOME' with Teamspeak 3 app which uses 9987/udp. Glad to provide any other pics/evidence you guys request....hopefully got most of the tier 1 stuff covered here. I work almost exclusively with Palo Alto stuff these days so I'm guessing that I'm missing some cross-interface route that just 'magically' works in my dayjob.

Client Win10Pro: 10.4.0.50:dynamic on 'KIDS' network where pfSense owns gateway 10.4.0.1
Server Ubuntu22: 10.1.0.225:9987on 'HOME' network where pfSense owns gateway 10.1.0.1

Rules are in the pic but effectively:
Action Proto Source SPort Dest DPort Gateway
ALLOW IPv4 * 10.4.0.0/24 * 10.1.0.225 * *

Testing Notes:
Worth noting that I'm able to RDP from HOME to KIDS without issue given a similar but separate rule on the HOME policy page.
I've disabled both Ubuntu FireWall and Windows Firewall.
I've reset pfSense State table and rebooted the firewall completely.
Packet Capture on firewall shows traffic arriving on KIDS, but not egressing on HOME.
tcpdump on server shows no ingress traffic from 10.4.0.0/24 network.

Having trouble uploading the rule screenshot. I'll work on that.

DobberDoo

@dobberdoo

Konstanti

@dobberdoo

Hi
Most likely , the problem is that rule number 2 uses PBR ( the WAN_DHCP gateway is forcibly assigned)
All traffic that passes to the KIDS interface goes through the WAN_DHCP gateway and does not reach the Home network

So rules 3 and 4 don 't work (Сolumn States is 0)

It is necessary to reverse the rules 2 and 4

Rule 3 in your case is superfluous on the Kids interface

Gblenn

@DobberDoo I'm guessing your kids want to talk to their friends on TeamSpeak as well. If not today, it will happen tomorrow...
Why not set up a dns account with some provider, if you don't have that already. Ports 9987 UDP and 10011, 30033 TCP need to be open towards the TS3 Server.
Then they simply bookmark your dyndns instead of IP in the TS3 client, accessing it via WAN as everyone else. No need for any special rules between your separate networks.

But in relation to your scenario I'm with Konstantini. Although when isolating a network I'd probably use block rules instead of policy routing. One rule per network you want to block them from. Source, Port and Gateway all set to * and destination is HOME, SECURE, PIAOVPN and OpenVPN respectively, for each of the block rules. The final rule in the list is then a KIDS allow all rule instead.
Finally, to give them access to the TS server, you move your last rule up above all the block rules. Or, you follow my suggestion above and don't use that rule at all. They can then only access TS via WAN.

DobberDoo

SUPER stupid thing to miss. I'm sorry for wasting your guys' time! It was indeed rule order bombing out the traffic. FYI I do already have dyndns setup with my domain so connectivity from external sources will be immediately functional...I still likely to keep internal traffic off the WAN interface though. Just a personal pref. Thanks all and have a great day!