I‘m ashamed to tell this but after setting up the clients, the interfaces, the gateway and the Nat-rule I simply reboot the firewall. Not a valid enterprise option but at home … It always does the trick, even when I have to rectify some errors after the reboot.

Thank you all for the reality check! I am turning up a new firewall and no rules existed except for test rules. Since everyone validated that ICMP is treated the same as TCP/UDP traffic for PF markings (route policies) and the placement of firewall rules matter. I looked at my test rules… It turns out I had an ICMP echoreq rule for all interfaces with a destination of any. This rule was there for diagnostic purposes. Changing the destination to "This Firewall", maintained diagnostic purposes and now the route policies are working as expected! Thank you

Hi, did you solved? Now the version 2.4 is out also but nothing seems changed

Glad to hear - better in bridge mode anyway ;)

Captive Portal https://doc.pfsense.org/index.php/Captive_Portal

never touch a running system. Lots of luck with that.

Note that if the resolver is in forwarding mode and DNSSEC is enabled, things can appear to break randomly if the forwarding servers do not properly support DNSSEC so it is generally best to disable that in forwarding mode. Even the popular ones like google and opendns don't do it right.

and the riverdelta networks was acquired by motorola and cmts is a motorola bsr 64000

Small update… I have run some simulations in my XenServer setup. I have created 2 PFsense firewalls and some internal networks, to mimic my current setup. In this setup I experience the same issue. I am able to ping across the 2 PFsense firewalls just fine, however that's just about the only traffic I am ever going to get through RDP or telnet to 3389 never reaches any of the Windows hosts on either PFsense LANs. I decided to download OPNsense to test the simulation above. The exact same network interfaces are used and the exact same network configuration in OPNsense, as above simulation, has been applied. It works! So something is different in PFsense when it comes to routing/firewall rules/something else compared to OPNsense. I am currently doing some tests to see if OPNsense works in my home-lab and demo-lab.

Hi, After reviewing the ping payload size, and also your recommendations, I still have the same issue. Let me know if any other suggestions come to mind. Thx. Oct 7 15:31:19 dpinger WAN2GW 8.8.4.4: duplicate echo reply received Oct 7 15:31:19 dpinger WAN2GW 8.8.4.4: duplicate echo reply received Oct 7 15:29:46 dpinger WAN2GW 8.8.4.4: Alarm latency 46725667us stddev 0us loss 95% Oct 7 15:28:14 dpinger WAN2GW 8.8.4.4: Alarm latency 15032us stddev 3426us loss 25% Oct 7 15:26:44 dpinger WAN2GW 8.8.4.4: Clear latency 15014us stddev 2740us loss 0% @wm408: Hi Derelict, Typically for the Monitor IP, I choose the ISP gateway or one hop past (as observed with traceroute). But lately for at least testing, I've set the problematic gateway's Monitor IP to a google DNS server also as that's been a popular choice throughout the forums. Thanks for your other tips. I will circle back and review each of your points after I look at the results with the topic I mentioned in an earlier post, re: ping payload size. @Derelict: Well, there you go. dpinger is doing its job. If you have gateway monitoring on WAN (the default setting), the system is automatically keeping track of two pings per second in Status > Monitoring. From there select settings, change the left axis to Quality / WANGW (or the local equivalent). A good place to start with Options: 8 hours, Resolution: 1 minute. Another place to check is in Status > System Logs, Gateways. Any events there with "Alarm" in them are times when the ping monitor had excessive loss or latency. A failure will look something like this: Jan 7 15:05:31 dpinger WANGW 8.8.8.8: Alarm latency 0us stddev 0us loss 100% Lines like this are just the dpinger process starting or reloading and are normal: dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 198.51.0.16 identifier "DSLGW " Sometimes it is beneficial to change your monitoring address to something further out. In that example you can see that I am monitoring a google DNS server there. In general, monitoring the ISP gateway is fine if it reliably responds to pings. Changes to the monitor IP address can be made in System > Routing and editing the appropriate gateway.

Thanks for replying!  All good points ;) I did get a gold subscription and plan to purchase support as soon as I encounter an issue I can't overcome. The documentation in the book is fantastic, I knew nothing about pfsense a couple weeks ago.  Dropping right into a multi-wan HA setup is probably not the smoothest way in, but so far, things are working as documented. Cheers

You didn't say what version of pfSense, but right off the bat I suspect the problem is those Realtek NICs. https://www.gigabyte.com/Motherboard/GA-N3150N-D3V-rev-10#sp [image: 4VpBK7Z.png]

Well u were right obviously. I've managed to make it work after all, doing it he hard way by restoring factory defaults and rebuilding everything from scratch. It must have been something conflicting from the all the changes I did to the configuration by trying to make it work using PPoE on all three DSL modems, which I understand does not play well with load balancing. Thanx, Vassilis

Are you doing the ping from pfSense to outside (e.g. Google)? It's important because the firewall rules (policy routing) don't apply to traffic from firewall. For that situation you should enable the gateway switching (according to  System > Advanced > Miscellaneous) If you're trying the ping from the PC, you must look over the outbound NAT settings, to be sure the traffic from LAN is translated to the secondary WAN IP.

Ntopng