Same on my pfSense box.

As a workaround you can edit /cf/conf/config.xml using "Diagnostics -> Edit File" and change the order directly in the config.

Hi,

@0daymaster having the same issue, I did a quick & dirty implementation of multiple ping targets for 2.4.4-p3. I can give you the patches if you want. However there is dpinger to pach/recompile aside to support multiple targets, which can be quite tedious if you're not familiar with freebsd and if you need to cross-compile (for arm in my case). With the patch, dpinger will ping each host as often as it was before and will report an average on all hosts. So, if you set 4 hosts, it will generate 4x more pings in the same time, and if one host is down, it will report 25% packet loss.

As a side note, it has been a surprise to see that dpinger is using threads with shared variables without any kind of thread synchronisation. If there is any issue there (and I think there is), using X hosts will multiply by X the likelihood to trigger it.

There is nothing special about it.

They are just addresses.

You should disable NAT for the public addresses in use on the inside.

Well incoming pings work from the outside but now no traffic originating from the inside can get out. When I turn off the firewall it all works. pfctl -d

Do you have rules passing the traffic into that interface from those hosts?

@runDMG Gotcha! Yeah, your issue was different than what Im facing :)
@Cool_Corona Hi! I haven't installed any packages and its a fresh install. I've created a topic with my specific issue here: https://forum.netgate.com/topic/152536/arp-00-11-22-ab-cd-ee-is-using-my-ip-address

Cheers!

Thanks. I will try this.

See if any of the following helps.

https://docs.netgate.com/pfsense/en/latest/book/firewall/methods-of-using-additional-public-ip-addresses.html

https://docs.netgate.com/pfsense/en/latest/book/routing/routing-public-ip-addresses.html#

Interesting - I only know host routes with mac addresses as Gateway if a direct connected route within the same subnet exists, but all your routes within 1.2.3.X have /32 masks. Did you compared the mac addresses with these from a "working" routing table. Does the macs in the routing table matches the entries in the arp cache? At the moment I have no clue whats going on at your end nor what could be the root cause of your issue 😕
I must say I don't have much experience with pfSense 2.4.5, since I was hitting latency issues and instability with BGP routing when I installed it on my OVH VM . But general reachability for the default route was not an issue after reboots, so I didn't look closely into the routing table for that part. Also I rolled it back to 2.4.4_p3 pretty quickly due to the problems I had. All my installations are running on 2.4.4_p3 at the moment.
If you have capacity on your proxmox cluster and another free IP-Addresses, I would suggest you provision another pfSense installation for test purposes and see if situation stays the same when you configure it from scratch.

Sorted out. I think I got my LAN rules wrong.

Do you have the second GW specified in the IP setup of the mackine?? Like using metrics?

Regarding the first problem, setting the mtu and the mss really solved my problem. Thank you.

I just set the MTU to 1400 and the MSS to 1360. How can i easily find out the highest i can get?

@Rico said in Multi WAN Routing Split:

Check out the great Multi WAN hangout by jimp: https://www.netgate.com/resources/videos/multi-wan-on-pfsense-23.html

-Rico

Thanks, exactly what i needed. Was thinking i needed to add the gateway to the WAN rules....doh!

Routes are not to be mixed up with Firewall rules.
Firewall rules are for traffic that comes IN to an interface. pfSense is the "inside" in this point of view. Firewall rules do not apply to outgoing traffic (just forget about floating rules right now, themselves rarely being used)

To be sure that firewall rules are not an issue, put on any (V)LAN type interface a first rule that is a pass-all rule.

Routes : every LAN type network that is not declared as a WAN type can reach other because an (LAN's) network mask matches. If there is no match with an existing local network, then a WAN type network is used to send the traffic out to have the traffic being handled by an upstream router.

In the vast majority of all possible network scenarios, there is no need to manipulate the routing table.

I know, I'm probably not answering your question.
What I want to say is : routing tables is never a problem. They can seem to be a problem if the network structure is fckd up severely.
In that case the network's logical structure needs to be redone. Not the routing table.

Example :

Like you, I'm using the OpenVPN server build into to access my companie's nerwork.

My LAN is 192.168.1.1/24 - all companie's PC's, printers, file servers, backup units, etc are on this LAN.
A second LAN network uses 192.168.2.1/24
My VPN tunnel network is a third local network 192168.3.1/24 (and surely not 192.168.1.1/24 which will conflict with LAN - breaking the routing)
So, when I connect remotely, my PC @home will have a 192.168.3.2 IP.
Traffic going to my OpenVPN server comes into pfSense and can go
192.168.1.0/24 which is local
Anywhere else : the Internet, so it's leaving on the WAN interface.

I been having this Issue for a long time as well, It will not fail back to the primary circuit, i have to go to the secondary circuit and mark getaway as down and force to fail over.