@bossaops thanks for the input. I actually did read up (and not just a little :) ) Got it all working.

@luckman212 i tried your patch but it doesnt seem to be correct, any ideas ? /usr/bin/patch --directory=/ -f -p2 -i /var/patches/6214fbf0c578a.patch --check --reverse --ignore-whitespace Hmm... Looks like a unified diff to me... The text leading up to this was: |From ad2dd2c1debaf2281eaed685ad8464c027c3b0b1 Mon Sep 17 00:00:00 2001 |From: luckman212 |Date: Tue, 18 Jan 2022 16:36:58 -0500 |Subject: [PATCH] squash | |--- | src/etc/inc/gwlb.inc | 54 +++++++++++-------- | .../include/www/system_advanced_misc.inc | 1 + | src/usr/local/www/system_advanced_misc.php | 9 ++++ | src/usr/local/www/system_gateways_edit.php | 12 +++++ | 4 files changed, 54 insertions(+), 22 deletions(-) | |diff --git a/src/etc/inc/gwlb.inc b/src/etc/inc/gwlb.inc |index 31dde0ee4ad..2b471571944 100644 |--- a/src/etc/inc/gwlb.inc +++ b/src/etc/inc/gwlb.inc Patching file etc/inc/gwlb.inc using Plan A... Hunk #1 failed at 239. Hunk #2 failed at 282. Hunk #3 failed at 2078. 3 out of 3 hunks failed while patching etc/inc/gwlb.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/pfSense/include/www/system_advanced_misc.inc b/src/usr/local/pfSense/include/www/system_advanced_misc.inc |index 6cb826693cb..aa8c24d1c37 100644 |--- a/src/usr/local/pfSense/include/www/system_advanced_misc.inc +++ b/src/usr/local/pfSense/include/www/system_advanced_misc.inc Patching file usr/local/pfSense/include/www/system_advanced_misc.inc using Plan A... Hunk #1 failed at 56. 1 out of 1 hunks failed while patching usr/local/pfSense/include/www/system_advanced_misc.inc Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/system_advanced_misc.php b/src/usr/local/www/system_advanced_misc.php |index 9806aac040e..4f676b58feb 100644 |--- a/src/usr/local/www/system_advanced_misc.php +++ b/src/usr/local/www/system_advanced_misc.php Patching file usr/local/www/system_advanced_misc.php using Plan A... Hunk #1 failed at 304. 1 out of 1 hunks failed while patching usr/local/www/system_advanced_misc.php Hmm... The next patch looks like a unified diff to me... The text leading up to this was: |diff --git a/src/usr/local/www/system_gateways_edit.php b/src/usr/local/www/system_gateways_edit.php |index 96b80171790..57afa7ce7f7 100644 |--- a/src/usr/local/www/system_gateways_edit.php +++ b/src/usr/local/www/system_gateways_edit.php Patching file usr/local/www/system_gateways_edit.php using Plan A... Hunk #1 failed at 72. Hunk #2 failed at 223. 2 out of 2 hunks failed while patching usr/local/www/system_gateways_edit.php done

@viragomann I have 2 WAN links, in a gateway group, I use that group in a firewall rule to provide failover. What I've found is that even OTHER policy based routing rules in the firewall which match better in both scope, and are higher on the list do not preempt the WAN policy route. My question is, "am I mistaken, is there some way to preempt a policy based route besides remove it?" . More than happy to map it out if you'd like..

@danjeman Hey thing is, I am in the Homeoffice and I do not have physical access to the devices. All I see is, after the update, I can not connect to the WAN2 Gateway anymore.

@wallace329 Easiest way to achieve what you're looking for is to create a specific rule on the source interface in question (so your LAN, for example) with the gateway set to either WAN1, WAN2 or a failover group. (that's in the advanced section of the rule when you set it up) Best practice (I find anyway) is to set the Source with an Alias group, then when you wish to force certain hosts over a specific gateway or a failover group then just drop their IP into the Alias group and all will be well (as long as that's above the general allow all rule)

@silence domain? in pfsense ? I don't understand, can you explain me better?

@jimp said in How to enlarge the default number of Rows (Routes) displayed ?: https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/diag_routes.php#L32 Works like a charm, thank you!

@demux Yes, it's the same use case. You need an IP within the modems private subnet which you're natting the source packets to to communicate with the modem. Since the interface has already an IPv4 from the DHCP, you need to add the additional IP as a virtual one.

@rsherga To get your network working just setup pfsense natting. NO routing nothing on your soho router. To it pfsense is just another client, you could put as many clients behind pfsense as you want, and to your soho router its all just coming from some IP it handed to pfsense wan. Just like your isp sees all your stuff as the router wan IP.. You can then get stuff working via port forward. Off the top your port forwarding wouldn't of worked unless you also turned off the default block rfc1918 rule on pfsense wan, because all your stuff on soho network is rfc1918 and would of been blocked from any port forwards your setup anyway.,

@loststatetable Ok common problem with printers that I see is they have not gateway set.. If you can not talk to it from vlan5 pc.. Validate the printer has a gateway, that points back to pfsense. As long as your vlan 5 rules allow access to printer IP or that network, or any any, etc. then what rules are on the printer network would not come into play. Can you post up the rules of this vlan 5.. But 2 directly connected networks/vlans would automatically pfsense would route between these network. Unless you were forcing traffic out a gateway via policy routing? If you could post your vlan 5 rules we could see. But if you sniff on the printer network interface, while you say try and ping the printer IP from the vlan 5 PC you could validate that pfsense is sending the traffic to the printer.

@serbus Thanks John, those are really useful posts and I now have some things to experiment with. M..

@cool_corona What I wrote above is a wrong statement, This is not true => You are right it looks like some built-in "kill state" procedure somewhere in background. No proof = not true. I can not indicate in the code where the flush would be executed. Coincidence with something else... but still not a PRD so don't care.

The only explanation I can give is that in those three rules I force the traffic to use one of the three gateway groups, while in the rule for accessing the DMZ I use the default gateway. But I still can't explain why. The default gateway is set to "Automatic" and without the Load Balancing and Failover configuration it would be set towards the router. Traffic to the DMZ should not go over the WAN. If someone more experienced than me can explain it to me I would be grateful.