@odhiambo said in Alias Public IP: not the right way since you say that "pfSense knows the 197.232.xx.64/30 subnet is on OPT1". I was assuming this was a second public static IP. If they route it to your first public IP, then 97.232.xx.65 would go on OPT1 and the server plugs into OPT1. (or whatever interface, that isn't LAN) If they are not routing the new subnet as the above linked doc page describes then I guess you'd need to set it up on pfSense WAN as you did and use 1:1 NAT to send it to your server on LAN.

@viragomann and @lawrencesystems https://www.youtube.com/watch?v=tHfAWY_jYbQ Thank you!

@pwood999 said in Low Throughput on GB LAN - 250 Users: speedtest.net Boa noite amigo. quando eu crio o grupo, e coloco todos os usuarios (250) para sair atraves desse grupo, todos reclamam de lentidao. Existe alguma configuracao que eu precise fazer para aumentar a velocidade? agora por exemplo, 21:57 pm todos navegando com NETFLIX etc... e o maximo de THROUGHPUT que tenho na LAN e algo em torno de 200MB. Socorro pelo amor de Deus.[image: 1645837168177-pf.jpg]

Hi @Elrick75 , I have the same problem! Did you fix that? Whatever I tried I can get a connection to the OpenVPN on the Synology.

@yellowbook I would hope that you do not have any devices on this lan (10.x.x.x) network your using as transit. If so you would run into asymmetrical routing problems. Networks that connect routers should not have any devices/hosts on them - if you do without doing host routing on each devices, or natting of the downstream networks you can run into asymmetrical traffic flow problems.

@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.