@Tilburg-013 I guess so as the associated bug https://redmine.pfsense.org/issues/15043 has been closed with 24.03 as the target release. You can also see the release overview here: https://redmine.pfsense.org/projects/pfsense/roadmap#pfsense-plus-24.03

SOLVED! on my test rig I tried a state-killing option that had NOT solved the problem on my live box, but on the test rig it worked. The setting is in System/Routing/Gateways, "State Killing on Gateway Failure". After changing that from the default to "Kill states using this gateway when it is down", subsequent failover events created a few arpresolve errors in the log, but within 1 second they stopped, after an entry in the log showing a state killing action: /rc.filter_configure_sync: GW States: Killing states for dynamic down gateway: WAN_DHCP, XX.XX.XX.1 After that worked, I had to figure out why this solved the problem with my test rig but not my live box. Eventually I traced it to a setting in System/Advanced/Miscellaneous in the Gateway Monitoring Section, "Skip rules when gateway is down". In my live box, which has some traffic that needs to be routed only through a VPN, I had enabled the setting "Do not create rules when gateway is down" years ago to make sure, if the VPN was down, that pfSense wouldn't route the traffic through the non-VPN WAN. But as soon as I cleared that check box, my failover arpresolve problem went away. So apparently that setting interacts with the failover in a way that prevents the state-killing action from working properly. Next job is to figure out a different way to kill VPN-bound traffic if the VPN is down... Googling that now.

@authenticx said in Need help with static routing please: The subnet in DR is the same as production thus I have it isolated in a VLAN. if both subnet's are the same, then you can not route between them.

*** Just to add i reconfigured the WAN port with the backup ISP. No issues afterwards***

@IT-CPUC Found a problem with WANs showing a "Pending" status under Gateways when running pfSense version 23.09.1-RELEASE but likely been there for a while. This appears to be caused by the process dpinger. Tied to using a DHCP from the ISP. Does not happen if ISP is using a static IP for the WAN. Occurs if the cable (RJ-45) between the modem and router/firewall is unplugged/replugged or if the modem is power reset. The problem happens with a single WAN and is not related to using a failover configuration. Can stay stuck in Pending state and is hard to get out of. Try, disabling the interface, then be sure the modem is fully online and ready to issue the IP by DHCP, and then reactive the interface. I've also tried releasing the IP and reassigning it under the Interfaces page. If your ISP is Comcast, I also found a bug in their lease time for DHCPs if their default value is changed. The problem I found is when the lease time is changed, the modem will fail at 1/2 the assigned lease time. Logs will show monitoring pings don't respond. Way to fix this was to reissue another DHCP lease time or release the IP and reassign it under the Interfaces page Another problem I found is modems in bridge mode will randomly disconnect because they stop responding to ARPs. Think the phSense default is 1200. Found it was necessary to reduce under 5 mins. I am using 240 for net.link.ether.inet.max_age found under Advanced/System Tunables. So far, this change appears to help stop the disconnects.

Found a problem with WANs showing a "Pending" status under Gateways when running pfSense version 23.09.1-RELEASE. Documented and I filed to bug report this week. This appears to be caused by the process dpinger. Tied to using a DHCP from the ISP. Does not happen if ISP is using a static IP for the WAN. Occurs if the cable (RJ-45) between the modem and router/firewall is unplugged/replugged or if the modem is power reset. The problem happens with a single WAN and is not related to using a failover configuration. Can stay stuck in Pending state and is hard to get out of. Try, disabling the interface, then be sure the modem is fully online and ready to issue the IP by DHCP, and then reactive the interface. I've also tried releasing the IP and reassigning it under the Interfaces page. If your ISP is Comcast, I also found a bug in their lease time for DHCPs if their default value is changed. The problem I found is when the lease time is changed, the modem will fail at 1/2 the assigned lease time. Logs will show monitoring pings don't respond. Way to fix this was to reissue another DHCP lease time or release the IP and reassign it under the Interfaces page Another problem I found is modems in bridge mode will randomly disconnect because they stop responding to ARPs. Think the phSense default is 1200. Found it was necessary to reduce under 5 mins. I am using 240 for net.link.ether.inet.max_age found under Advanced/System Tunables. So far, this change appears to help stop the disconnects.

@zaphanathpaneah said in pFsense cannot ping devices directly connected: for example I want to prevent traffic from one subnet moving to another. I have 4. Here is a simple example of locked down rules. [image: 1709311482612-lockdown.jpg] Devices on this network can not talk to any of my other networks, because all of my other networks are rfc1918 space, and there is a rule that blocks that access.. While rules above it allow what I want.. Ping Pfsense IP, ask pfsense address on this network for dns, I also allow this network to talk to my pihole on another network for dns. I allow it to ask pfsense for ntp. But they can not talk to any other pfsense IP be it for dns or webgui or ssh or anything because of the specific this firewall reject rule. This also prevents them from access pfsense public wan IP for anything.. Because the last rule allows any any, that has not been block above it. The rfc1918 alias contains all the rfc1918 space, so any of my current networks or future networks would all be in rfc1918 space... If I created a network outside rfc1918 space, then that any any rule at the bottom for internet access would end up allowing that traffic.

The Plus Version 23.05.1 presents the same symptoms described in https://redmine.pfsense.org/issues/14763. Please assist if there are any available clues to resolve the issue.

@rk4n3 If you check Status > Gateways what's the status? If it's not shown up as online edit the gateway in System > Routing > Gateways and check "Disable Gateway Monitoring Action". Is the gateway selected in System > Routing > Gateways > Default gateway, or is it Automatic? If it still doesn't work, show your whole routing table, please? Diagnostics > Routes

I found the problem. Appears to be related to this thread. I implemented the fix and both wans have been stable for 48 hours. https://forum.netgate.com/topic/185334/pfsense-wan-gateway-randomly-goes-down

@Matt_Sharpe I'm not aware of an issue in pfsense with this. However, if there is switch or a vswitch (in case one is virtualized) in between both routers, you have possibly to allow MAC changes on these devices.

@viragomann Thanks, I got it working. To clarify it for anyone who may find this in the coming years by Google and be in need of a HOW-TO, the process consists of three steps: Create a ProxyARP pool that covers the intended External IP subnet Add IP Aliases for each of the External IPs from that subnet you want in the outbound pool Add an Outbound NAT with the ProxyARP as its outgoing network

@viragomann - Great, thank you for the clarification :)