@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