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

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

It looks like bug 7719 which is fixed in 2.4.0 looks like it finally solves Dynamic DNS. It looks like it was an issue with gateway groups.

https://redmine.pfsense.org/issues/7719

I will be testing as soon as 2.4.0 is released and I'll report my findings!

@johnpoz:

In single mode your not pointing towards a gateway…  Or the only gateway you can to go is where your trying to go..

If you were load balancing, and it tried to go out the wan2 wan when your trying to talk to wan1 then not going to work is it ;)

Perfect, thank you. Appreciate the help!

More than happy to throw my advice at you, if there was an actual drawing of your network with enough details so wouldn't be guessing.  For example you mention hsrp - no where previous did that come up..

So your 3560 is actually a stack?  Are you going to run a lag to this stack so you have 1 physical connection to each switch in the stack.  Is there some other switch between pfsense and that?  Are you going to run pfsense in a carp setup?

If you would draw out your current network with enough details, then could make suggestions on what I would change, etc..

"so i could have 192.168.7.0/24 and X.X.X.48/29 on the lan side "

Not sure where your coming up with the 192.168.7 but sure you could use that on our local lan side along with your x.x.x.48/29 just on on the same network.. So 192.168.7 could be your lan, and .48/29 could be on an opt or a vlan..

First, it's time to upgrade your pfSense! 2.2.6 is pretty old, and one of the best things to come in 2.3+ was that apinger (gateway monitoring daemon) was replaced by dpinger – which is infinitely more reliable. Anyone who's been using pfSense for more than a couple of years will remember with much angst the nightmare of wrestling with apinger.

Once you've done that, I highly suggest you read https://doc.pfsense.org/index.php/Multi-WAN#Optional_Tweaks and experiment with the latency & loss thresholds.

The messages about IPSEC/OpenVPN/Dyndns are not important and do not indicate any problem. They are just basically debug messages from code paths that, in your case, are not being hit.

Good luck. If you need more specific help feel free to come back and ask.

Not quite enough info there to help you… can you post a screenshot of the rules on your LAN interface?

Rules are processed in order from top to bottom, so make sure you put any policy-based routing rules ABOVE your last "default" rule otherwise it will never get hit...

Generally, make sure you leave "source port" blank - 99% of the time source ports are random and you should only be concerned w/ Dest. port.

Did you change anything on the Firewall > NAT > Outbound page? (you should leave that on 'Automatic' until you understand it fully)

"can you explain from where the gateway 192.168.9.253 and 192.168.2.253 comes from"

As I told you already - those were my wan_dhcp gateways in the downstream pf1 and 2 I setup.. That is just my internet in my setup to mimic yours.  Here is a drawing..

"Both firewall communicate each other but can not access Internet."

Who can not access internet, can your 2 networks talk to each other? 192.168.0 and 192.168.10?  Did you mess with outbound nat?  When you create your downstream route it should automatic create your outbound nat for you.

Your going to have to post your setup if you want me to spot what your doing wrong.  How is it showing online when shows NO interface or connection just "NONE"  How does your wan have a 0.0ms response time??

setupsimyoursetup.png
setupsimyoursetup.png_thumb