I believe that I have a similar issue with the IPsec tunnel. My setup is as follow: main office Pfsense with Dual WAN. They are configured in a Failover group (Tier1 and 2 ). I have static public IP addresses for both of the WANs. Branch office: Pfsense with one WAN. It has a static public IP address. I configured one tunnel in the main office that points towards the branch office from the WAN failover group. On the branch office, I set up 2 tunnels one point towards the main WAN in the main office and the other points towards the secondary WAN. When the main WAN in the main office goes offline, The tunnel will be recreated with the secondary WAN. But when The main WAN comes back online there will be 2 active tunnels from the main and secondary WAN to the branch office. I don't know if this is an issue with my configuration since there is one tunnel in the main firewall and 2 tunnels in the other firewall, or it is only a limited configuration.

@SergeCaron This is the result of a configuration error. Mine, of course! The "Disable Gateway Monitoring Action" option was checked on the Tier 1 Gateway on Box #1. Clearing this option, everything is working as expected on both boxes. Regards,

@SergeCaron (Sheepish grin) I figured out the "cannot uninstall cleanly" caution in Patch Manager. I installed the patch and Patch Manager happily reports it can be uninstalled cleanly. Unfortunately, I can no longer reproduce the disapearing Gateway issue: even if I force a complete disconnect of Tier 1, the Gateway Group does not switch to Tier 2. So, I will close this issue for now.

@jimp Thank you! Works perfectly as you described. Regards,

@plusbil merhaba Denedim ama bu şekilde de erişim sağlanmadı.

1- Vá em System -> Routing 2- Clique para editar o Gateway 3- Altere o campo "Data Payload" de 0 para 1 4- Salve e aplique a modificação 5- Reinicie o dpinger Em um caso parecido, comentaram sobre estarem usando apenas um DNS da emrpesa no 1º link, então quando saía pelo segundo dava erro, então o recomendado deve ser usar os dois DNS, um de cada empresa. Esse não é o meu cenário, por isso não sei a vericidade, mas já vi as pessoas comentando isso e deixei essa solução salva no pc para quando precisar rsrs... Mas já me confirmaram que funcionou, mas cada cenário é cada um, espero que resolva o seu também.

Additional noteworthy observations. There was one strange thing about GIF configuration on pfSense 2.4.3 (and before?). I had to disable Outer Source Filtering on gif0 for the traffic to flow — otherwise even gateway monitoring pings were discarded upon reception: that is, if I remember correctly, ping replies were received on parent interface but rejected at GIF level. Those ping replies had proper source and destination addresses for both IPv4 and IPv6 and came in via proper interface. Of course, the IPv6 network for GIF tunnel itself was not the same as for overlaid network — but that is the case for all tunnels of all brokers. In particular, gif2 to the same broker was functioning well with Outer Source Filtering enabled by default, as well as gif1 to another broker. Right before upgrading from 2.4.3 to 2.4.4, I noticed that gif2 also needs disabling Outer Source Filtering. I had no idea on why this happened and how long ago — just switched the offending setting, and the tunnel became operational for about a couple of hours until the update took place. Same as earlier, however, gif1 to another broker was functioning with Outer Source Filtering enabled by default, and used proper parent interface even after upgrading to pfSense 2.4.4. Now that pfSense 2.4.4 is installed, I tried switching Outer Source Filtering back on and then off again — just in case — but observed no effect. That was expected indeed, as the primary issue is not with ingress filtering on local side: outgoing traffic is filtered by remote end because of improper source addresses caused by improper parent interface being used. I also tried Disable Gateway Monitoring for both gateways corresponding to gif0 and gif2. That allowed the traffic to flow out unconditionally, but only showed that any kind of traffic — not just ICMP pings — chose wrong parent interface. I once again tried changing default gateway settings, and the outcome was equally negligible. That is, sometimes I saw small bursts of legitimate traffic pass out and then in (such as my NTP server making a request and receiving a reply), but it is hard to correlate to settings change as those bursts stop soon. The other times I see legitimate inbound traffic entering proper parent interface, but somehow filtered on local side — such as incoming NTP and DNS requests with no reply from my home server [because pfSense filtered those requests out]. :puzzled:

The biggest factor there is how much of that traffic will be over OpenVPN. If the majority of it is and you want to get anywhere near 2Gbps you're going to need the fastest CPU you can get hold of. Each OpenVPN process is single threaded so less cores at higher speeds wins here if you have only a few tunnels. Steve